Bitcoin Vaults: How Time-Locked Recovery Protects Against Theft

Bitcoin vaults are a class of custody constructions that introduce a mandatory delay between initiating a withdrawal and receiving funds. During this window, the legitimate owner (or an automated watchtower) can detect unauthorized spending attempts and claw back the coins to a secure recovery address. The concept transforms Bitcoin self-custody from a binary model (either you have the key or you don't) into a layered security system where stealing a private key is no longer sufficient to steal funds.

This article covers how vaults work at a technical level, the major implementation approaches (pre-signed transactions, CTV, OP_VAULT, and OP_CAT), their trust assumptions, and practical applications from exchange cold storage to inheritance planning.

How Bitcoin Vaults Work

A vault enforces a spending policy where coins cannot move directly from storage to their final destination. Instead, a withdrawal follows a multi-step process:

1. The spender broadcasts an unvault (trigger) transaction, moving coins to a staging output with a timelock.
2. During the delay period (typically 24 hours to several days), anyone monitoring the chain can see that coins are being moved.
3. If the withdrawal is legitimate, the owner waits for the timelock to expire and broadcasts the final withdrawal transaction.
4. If the withdrawal is unauthorized, the owner (or a watchtower) broadcasts a recovery transaction that sweeps the coins to a pre-committed cold recovery address before the timelock expires.

This pattern is conceptually similar to a bank wire with a cancellation window, but enforced at the protocol level without trusting any intermediary. The critical insight: an attacker who compromises your hot signing key still cannot steal funds, because the recovery path uses a separate key stored in deeper cold storage.

Why vaults matter now: The February 2025 Bybit hack resulted in $1.5 billion stolen from a multisig cold storage setup. Attackers compromised a signing UI to trick operators into approving a malicious transaction. A vault with a time-delayed withdrawal would have given Bybit a window to detect and reverse the unauthorized spend before funds were lost.

Pre-Signed Transaction Vaults

The earliest practical vault implementation requires no consensus changes to Bitcoin. Bryan Bishop (kanzure) released a working prototype in 2020, building on covenant concepts first formalized by Möser, Eyal, and Sirer in 2016. The architecture was further detailed in the paper “Custody Protocols Using Bitcoin Vaults” (2020).

The Delete-the-Key Trick

The core mechanism uses ephemeral keys: generate a temporary private key, use it to pre-sign a complete set of vault transactions (the unvault, the timelocked withdrawal, and the clawback), then securely delete the key. Once deleted, the only valid spending paths for those coins are the ones that were pre-signed.

This creates a covenant without requiring any new Script opcodes. The covenant is enforced by the absence of the key rather than by consensus rules. Pre-signed transactions define a set of constrained outputs using standard OP_CHECKSEQUENCEVERIFY relative timelocks for the delay period.

UTXO Sharding

Bishop's prototype splits vault funds across multiple UTXOs with different relative timelocks. If an attacker triggers an unvault, only a fraction of the total balance is at risk at any given moment. The owner has multiple sequential windows to detect the attack and initiate clawback for the remaining shards.

Trust Assumptions

Pre-signed vaults rely on three assumptions: the ephemeral key was genuinely destroyed (not backed up or leaked), a watchtower is online to detect unauthorized unvaults, and the owner retains access to the recovery key. The fundamental weakness is that key deletion cannot be cryptographically proven. You must trust the process, not the math.

Additionally, all transaction parameters (including fees) must be decided at vault creation time. If network fee conditions change dramatically, pre-signed transactions may become uneconomical or too slow to confirm in time.

CTV-Based Vaults (BIP-119)

OP_CHECKTEMPLATEVERIFY (CTV), proposed by Jeremy Rubin in BIP-119, is a covenant opcode that constrains how coins can be spent by committing to a hash of the spending transaction's structure: version, locktime, outputs, input count, and sequences. If the spending transaction doesn't match the template, it's invalid.

How CTV Vaults Work

A CTV vault locks coins into an output whose script contains a CTV hash committing to a specific unvault transaction. That unvault output itself contains two spending paths: a timelocked withdrawal (committed via another CTV hash to exact destination outputs) and a recovery path to a pre-specified cold address. The entire transaction tree is deterministic and precomputed at vault creation time.

The key advantage over pre-signed vaults: no ephemeral key handling. Covenant enforcement happens at the consensus level. There is no key to delete, no key deletion to trust, and no key backup that could leak. The vault's security properties are verifiable by anyone inspecting the Script.

CTV Vault Limitations

CTV vaults must pre-decide denominations and fee rates at creation time. There is no support for partial withdrawals: spending any amount requires destroying and recreating the entire vault. Each UTXO requires a separate trigger transaction (no batching). And a subtle but dangerous footgun: sending coins to a CTV vault address more than once permanently locks the duplicate deposit, since the pre-committed transaction template only accounts for the original UTXO.

CTV vaults are also vulnerable to fee pinning: an attacker can chain 25 low-fee descendant transactions off the unvault output, hitting Bitcoin Core's descendant limit and blocking CPFP fee bumping. The attack cost is estimated at less than 0.05% of the vault balance.

CTV activation status (2026): BIP-119 has concrete activation parameters proposed for the first time: a signaling start of March 30, 2026, a timeout of March 30, 2027, and a 90% miner threshold. Whether activation proceeds remains under active community debate.

OP_VAULT: Purpose-Built Vault Opcodes (BIP-345)

BIP-345, authored by James O'Beirne and Greg Sanders, proposed two dedicated Taproot opcodes designed specifically for vaults: OP_VAULT and OP_VAULT_RECOVER.

Technical Architecture

OP_VAULT works within the Taproot script tree. A vault output contains at least two tapleaves: one with OP_VAULT (the trigger path) and one with OP_VAULT_RECOVER (the recovery path). When the trigger is spent, OP_VAULT replaces its own tapleaf with a new script containing a relative timelock (via CSV) and output constraints (via CTV). All other tapleaves, including the recovery leaf, are preserved unchanged.

The vault lifecycle uses four transaction types: a vault transaction (initial deposit), a trigger transaction (initiates withdrawal with delay), a withdrawal transaction (completes after timelock), and a recovery transaction (clawback at any time via OP_VAULT_RECOVER).

Advantages Over CTV Vaults

OP_VAULT supports partial withdrawals, trigger batching (multiple vault UTXOs can be combined into a single timelocked output), and authorized recovery (requiring a signature to initiate recovery, which prevents griefing attacks). The withdrawal destination is specified at trigger time, not at vault creation, providing flexibility that CTV vaults lack. Fees can also be set dynamically at trigger time rather than being locked in at creation.

Current Status

BIP-345 was withdrawn by its author in May 2025 in favor of BIP-443 (OP_CHECKCONTRACTVERIFY), a more general-purpose covenant opcode proposed by Salvatore Ingala that can accomplish vault functionality along with many other contract types. The on-chain cost of a full OP_VAULT lifecycle was approximately 567 vBytes across three transactions.

OP_CAT Vaults (BIP-347)

OP_CAT is a simple opcode that concatenates two stack values. Originally part of Bitcoin's scripting language but disabled early on, re-enabling it within Tapscript (as proposed in BIP-347) would provide a general-purpose primitive sufficient to construct covenants, including vaults.

How OP_CAT Enables Vaults

OP_CAT enables transaction introspection through a cryptographic technique observed by Andrew Poelstra: by setting the public key and nonce commitment in a Schnorr signature to the generator point, the signature's s-value becomes a function of the transaction's SigMsg. By passing SigMsg components as witness data and using OP_CAT to reconstruct the message on the stack, the script can verify that the spending transaction matches expected constraints. This builds covenant enforcement from a single concatenation primitive.

The Taproot Wizards team demonstrated this approach with Purrfect Vault, a working demo on a custom signet that implements the full vault lifecycle using OP_CAT: deposit, timelocked unvault, recovery clawback, and legitimate withdrawal.

OP_CAT Trade-offs

OP_CAT vault scripts are significantly more complex and larger than purpose-built opcodes. When combined with OP_CHECKSIGFROMSTACK (BIP-348), the full lifecycle costs approximately 553 vBytes. A critical weakness: the recovery leaf in current OP_CAT vault designs uses a simple OP_CHECKSIG with SIGHASH_DEFAULT and no output introspection. If the cold recovery key is compromised, the attacker can steal all funds immediately with no delay or clawback opportunity.

Comparing Vault Approaches

Each vault construction makes different trade-offs between security, flexibility, complexity, and consensus requirements. The following table compares the four major approaches across key dimensions.

Practical Applications for Bitcoin Vaults

Exchange Cold Storage

Exchanges managing large reserves face a fundamental dilemma: keys must be accessible enough for operations but secure enough to resist sophisticated attackers. Vaults resolve this by allowing the hot wallet signing key to initiate withdrawals while requiring a separate, deeply secured recovery key to reverse unauthorized ones. Even if an attacker fully compromises the signing infrastructure (as happened in the Bybit breach), the time delay provides a detection and response window.

OP_VAULT's authorized recovery model is particularly suited for exchanges: requiring a signature to initiate recovery blocks griefing attacks where an adversary repeatedly triggers recovery to disrupt operations.

Inheritance Planning

Vaults and timelock-based wallets enable trustless Bitcoin inheritance without relying on lawyers or custodians. Liana Wallet, built on Miniscript, implements this pattern today without any consensus changes: a primary spending path is always accessible, while one or more recovery paths (held by heirs or professional key agents) become active only after a configurable period of wallet inactivity. The owner simply needs to move funds periodically to reset the timelock, proving they are still alive and in control.

High-Net-Worth Individual Custody

For individuals holding significant Bitcoin, vaults add a layer of protection beyond standard multisig setups. CTV vaults are recommended for individual holders due to their simplicity: the entire transaction tree is deterministic and precomputed, meaning the user can audit every possible outcome at creation time. There are no dynamic parameters or authorization keys to manage.

Corporate Treasury

Companies holding Bitcoin in treasury can use vaults to enforce multi-layered authorization. A typical corporate setup might combine multisig for routine spending with a vault wrapper that adds a time delay to large withdrawals. This gives the board or security team a window to review and potentially block unauthorized large transfers, similar to wire transfer approval workflows in traditional banking.

Recommended Vault Design by Use Case

Limitations and Open Challenges

UTXO Management Overhead

Vaults inherently create more UTXOs than standard custody setups. Each vault is a separate UTXO (or set of sharded UTXOs) that must be managed independently. Consolidation during high-fee periods becomes expensive, and the pre-signed vault model compounds this by splitting funds across many small UTXOs with staggered timelocks.

Fee Environment Sensitivity

Pre-signed and CTV vaults lock in fee rates at creation time. If network fees spike dramatically after vault creation, the recovery transaction may not confirm quickly enough to beat the timelock expiry. This is a fundamental tension: longer timelocks provide more response time but also more time for an attacker to use fee manipulation (such as flooding the mempool) to delay the recovery transaction.

Watchtower Requirements

All vault designs require a monitoring service (a watchtower) that watches the blockchain for unauthorized unvault transactions and automatically broadcasts recovery transactions. If the watchtower goes offline during an attack, the timelock expires and the attacker succeeds. This creates a liveness dependency similar to Lightning Network watchtowers, though with significantly longer response windows (hours or days rather than minutes).

Covenant Soft Fork Dependency

The most capable vault designs (CTV, OP_VAULT, CCV) all require soft fork activation. As of mid-2026, no covenant opcode has been activated on Bitcoin mainnet. CTV (BIP-119) has proposed activation parameters, but the process remains contentious. The only vault constructions usable on mainnet today are pre-signed transaction vaults and Miniscript-based timelock recovery (as implemented by Liana Wallet). Full covenant support is needed for the most robust vault functionality.

Splitting and Watchtower Exhaustion Attacks

OP_VAULT and CCV vaults are vulnerable to a splitting attack: an attacker who has the trigger key can split a vault into thousands of small UTXOs and trigger them all simultaneously. The watchtower must then pay on-chain recovery fees for each individual UTXO. At approximately 122 to 246 vBytes per recovery, an attacker can force the watchtower to spend significant fees, potentially exceeding the value being protected. Fee environment matters: at high fees (above 100 sat/vB), CTV vaults are actually safer because they lack the splitting mechanism, despite their other limitations.

Vaults in a Layered Security Model

Vault designs complement Layer 2 solutions by enabling a tiered custody architecture. Users can keep long-term savings in on-chain vaults (with multi-day recovery windows and deep cold storage keys) while using a Layer 2 like Spark for day-to-day spending. This mirrors how traditional finance separates savings accounts from checking accounts: different security profiles for different time horizons.

On-chain vaults provide the highest level of security for funds that don't need to move frequently. When users need liquidity, they can withdraw from the vault (with the appropriate delay) and deposit into a Spark wallet for instant, low-cost transfers. For developers building on this layered model, the Spark SDK provides self-custodial wallet infrastructure that pairs naturally with on-chain vault setups.

The combination addresses a real behavioral problem: users who keep all funds in hot wallets for convenience are maximally exposed to key compromise. Users who lock everything in cold storage sacrifice usability. A vault-plus-L2 architecture lets users maintain strong security for savings while retaining instant access to spending funds. For a deeper look at how custody architectures compare, including multisig, MPC, and self-custodial models, see our custody solutions comparison.

What Comes Next for Bitcoin Vaults

The vault landscape is converging. BIP-345 (OP_VAULT) has been withdrawn in favor of the more general BIP-443 (OP_CHECKCONTRACTVERIFY), which can implement vault logic along with other contract types. CTV (BIP-119) has proposed activation parameters for the first time. The LNHANCE bundle (CTV + CSFS + OP_INTERNALKEY) targets both vault and Lightning Network improvements in a single soft fork.

Meanwhile, production-ready tools like Liana Wallet demonstrate that useful vault-like security is achievable today using Miniscript and existing timelocks. Covenants are already live on Blockstream's Liquid sidechain, providing a testing ground for vault designs that will eventually reach mainnet. For those interested in the broader covenant debate, our coverage of OP_CAT and covenants explores the community dynamics and technical arguments in detail.

Whether through a dedicated opcode or a general-purpose covenant primitive, Bitcoin vaults represent a fundamental improvement in custody security. The question is no longer whether vaults are useful, but which covenant mechanism will be activated first to bring them to mainnet.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.