Taproot Vaults
Taproot vaults are the most advanced wallet type in Sigvault. They use Bitcoin’s Taproot upgrade to define multiple spending conditions — each with its own set of signers, thresholds, and optional time locks. This enables sophisticated custody arrangements like inheritance planning, institutional governance, and disaster recovery.
When to Use a Taproot Vault
Section titled “When to Use a Taproot Vault”Taproot vaults are designed for:
- Inheritance planning — Automatic access for heirs after a time period
- Disaster recovery — Backup keys that activate after the primary signer becomes unavailable
- Institutional custody — Different authorization paths for different urgency levels
- Tiered access — Immediate access for the owner, delayed access for recovery parties
How Taproot Works
Section titled “How Taproot Works”Bitcoin’s Taproot technology allows multiple spending scripts to coexist in a single address:
- Key path — The primary spending condition. When used, the transaction looks like an ordinary single-signature payment on-chain, preserving privacy
- Script paths — Alternative spending conditions hidden in a Merkle tree. Only the condition being used is revealed at spending time
This means a vault with complex recovery policies looks identical to a simple wallet from the outside until a script path is actually used.
Spending Conditions
Section titled “Spending Conditions”Each vault defines one or more spending conditions. A spending condition specifies:
- Threshold — How many signatures are required (e.g., 1-of-1, 2-of-3)
- Signers — Which devices or keys can sign for this condition
- Time lock — Optional delay in blocks before the condition becomes spendable (0 = immediate)
The primary condition (usually the owner’s key) has no time lock and is used as the Taproot key path. Recovery conditions are placed in the script tree and activate only after their time lock expires.
For a deeper dive, see Spending Conditions.
Example: Inheritance Vault
Section titled “Example: Inheritance Vault”A typical inheritance vault might have three spending conditions:
| Condition | Threshold | Signers | Time Lock |
|---|---|---|---|
| Owner (primary) | 1-of-1 | Owner’s hardware wallet | None (immediate) |
| Family Recovery | 2-of-3 | Spouse + Lawyer + Bank | 144 blocks (~1 day) |
| Emergency Recovery | 3-of-4 | Extended family members | 52,560 blocks (~1 year) |
- The owner can spend at any time with their hardware wallet
- If the owner is unavailable for more than a day, the family can recover funds with 2-of-3 agreement
- As a last resort, the extended recovery group can access funds after one year
Creating a Taproot Vault
Section titled “Creating a Taproot Vault”- Register devices for all participants
- Navigate to Wallets and select Create Wallet
- Choose the Inheritance Vault template or configure a custom vault
- Define spending conditions:
- Set the primary spending condition (key path, no time lock)
- Add recovery conditions with thresholds and time locks
- Assign devices to each condition
- Review the policy summary and confirm
Transaction Flow
Section titled “Transaction Flow”When spending from a taproot vault:
- Select which spending condition to use
- Sigvault builds a PSBT targeting the chosen spending path
- If the condition has a time lock, the transaction is only valid after the lock expires
- Collect the required signatures from the devices assigned to that condition
- The transaction is finalized with the appropriate Taproot witness (key path or script path proof)
- Broadcast to the network
Custody Models
Section titled “Custody Models”Like multisig wallets, taproot vaults support custodial, non-custodial, and collaborative configurations. A common pattern is:
- Primary path: User’s hardware wallet (non-custodial)
- Recovery path: Mix of user devices and a system-managed backup key (collaborative)
This gives the user full control for day-to-day use while providing a safety net for recovery scenarios.
Device Compatibility
Section titled “Device Compatibility”Not all hardware wallets fully support taproot vaults. The primary keypath signer must be a device that can handle taproot outputs with script trees.
| Device | Keypath Signer | Script Path Signer | Notes |
|---|---|---|---|
| BitBox02 | Yes | Yes | Full taproot support |
| Ledger | Yes | Yes | Requires Bitcoin app v2.1.0+ |
| Coldcard | Yes | Yes | Requires firmware v6.2.1+ |
| Trezor | No | No | Cannot sign taproot with script trees |
| Jade | No | No | Only supports BIP86 single-key taproot |
Considerations
Section titled “Considerations”- Complexity — More conditions mean more coordination and careful planning
- Time lock management — Understand that recovery conditions can be used by anyone who holds the required keys once the time lock expires
- Regular spending — Keep the primary path active to prevent premature recovery activation
- On-chain privacy — Key path spending reveals nothing about the vault’s policies
- Descriptor backup — Save the wallet descriptor alongside device seed phrases for full recovery