BIP-345 OP_VAULT: Time-Delayed Recovery Vaults for Bitcoin Self-Custody

Bitcoin self-custody has always carried a tension: you control your keys, but if those keys are compromised, your funds are gone instantly and irreversibly. BIP-345, authored by James O'Beirne with contributions from Greg Sanders, proposed OP_VAULT as a solution: a covenant-based mechanism that introduces time-delayed withdrawals and emergency recovery paths directly into Bitcoin Script. The idea is straightforward: even if an attacker steals your spending key, they cannot immediately drain your funds because every withdrawal must wait through a configurable delay period during which you can claw funds back to a pre-committed recovery address.

Although BIP-345 was formally withdrawn in May 2025 in favor of the more general-purpose BIP-443 (OP_CHECKCONTRACTVERIFY), the vault model it defined remains the clearest articulation of how covenant-based custody could work on Bitcoin. Understanding OP_VAULT is essential context for evaluating every vault and covenant proposal that followed it.

What Problem Do Vaults Solve?

Standard Bitcoin custody presents a binary: either your key can spend immediately, or it cannot spend at all. There is no middle ground where a key can initiate a withdrawal but not finalize it without additional conditions being met. This means a compromised hardware wallet, a stolen seed backup, or a coerced signing session can result in total, irreversible loss.

Multisig mitigates this by distributing signing authority, but it does not introduce a time dimension. A 2-of-3 multisig is still instant: if two keys are compromised simultaneously, the attacker can sweep funds in the same block. Vaults change the game by adding a temporal constraint: funds cannot move to their final destination until a delay period expires, and during that window, a separate recovery key can redirect everything to cold storage.

The vault guarantee: Even with a fully compromised spending key, an attacker cannot steal funds faster than the vault's delay period. As long as the owner detects the unauthorized withdrawal and acts before the delay expires, the funds can be swept to safety using the recovery key.

How OP_VAULT Works: The Two-Step Withdrawal

BIP-345 introduced two new opcodes that work together to enforce vault semantics:

• OP_VAULT: validates the trigger transaction that initiates an unvaulting, enforcing that the output script structure is preserved and the delay period begins
• OP_VAULT_RECOVER: enables the recovery path, sweeping triggered (in-flight) withdrawals back to a pre-committed recovery address at any point before finalization

Step 1: Trigger the Unvaulting

A user who wants to withdraw from the vault broadcasts a trigger transaction. This transaction spends the vault UTXO using the OP_VAULT script path, which enforces several constraints: the output must preserve the same Taproot tree structure (minus the spent leaf), the designated delay period must be encoded in the new output, and the withdrawal destination must match the CTV hash committed in the trigger. The vault UTXO transitions into an intermediate state: funds are locked in a new output that enforces the time delay via OP_CHECKSEQUENCEVERIFY (CSV).

Step 2: Wait the Delay Period

The intermediate output cannot be spent until the configured number of blocks have passed. This delay is the core security mechanism. During this window, the vault owner (or an automated watchtower) monitors the blockchain for unexpected trigger transactions. The delay is configurable per vault, allowing different security profiles: a personal savings vault might use a 144-block delay (roughly one day), while an institutional treasury could enforce 1,008 blocks (roughly one week).

Step 3: Complete or Clawback

If the delay expires without intervention, the withdrawal completes: funds move to the destination committed in the trigger transaction. If the withdrawal was unauthorized, the recovery key holder broadcasts a recovery transaction using OP_VAULT_RECOVER at any point before the delay expires, sweeping funds to the pre-committed recovery address. The recovery path is always available during the delay window, turning vault security into an active intervention model rather than passive defense.

The Emergency Clawback Mechanism

The recovery path is the defining feature that separates vaults from simple timelocked transactions. A standard CSV lock delays a spend but offers no recourse if the spending key is compromised: the attacker simply waits. With OP_VAULT_RECOVER, a separate recovery key can intervene at any point during the delay, redirecting funds to a pre-committed cold storage address.

This creates an asymmetry that favors the legitimate owner. The attacker must compromise the spending key and hope the owner does not notice within the delay window. The owner only needs to detect the unauthorized trigger transaction and broadcast a single recovery transaction. Watchtower services can automate this detection, making the window effectively instant for monitored vaults.

The recovery address itself is committed at vault creation time using a hash, so it cannot be changed after the fact. This prevents an attacker who compromises the spending key from redirecting the recovery path. Even if the spending key and the recovery key are both compromised, the attacker gains nothing beyond what the recovery address allows: funds end up in deep cold storage rather than being stolen.

Key insight: OP_VAULT separates key roles by function. The spending key can trigger withdrawals but cannot finalize them instantly. The recovery key can cancel withdrawals but cannot initiate them. Neither key alone grants full, immediate control: this separation of concerns is what makes vaults fundamentally more secure than single-key or even multisig setups for long-term storage.

OP_VAULT's Dependency on OP_CTV

BIP-345 was designed to work in conjunction with OP_CHECKTEMPLATEVERIFY (CTV, BIP-119). The two opcodes serve complementary roles in the vault construction:

• OP_CTV constrains where funds can go by committing to a specific transaction template (outputs, amounts, destinations)
• OP_VAULT constrains how the vault structure evolves by enforcing that the Taproot tree is preserved correctly during unvaulting, with only the spent leaf replaced

Without CTV (or a similar template-checking opcode like OP_TXHASH), OP_VAULT cannot enforce that the withdrawal destination matches what was committed at trigger time. CTV provides the cryptographic commitment to the transaction shape; OP_VAULT provides the state-transition logic specific to vault lifecycles. This coupling means that activating OP_VAULT on Bitcoin would have required activating CTV first (or simultaneously), which contributed to the proposal's complexity from a consensus perspective.

Vault Script Architecture with Taproot

OP_VAULT was designed to leverage Taproot's script tree structure. A vault UTXO is a Taproot output whose taptree contains multiple script leaves:

• a trigger leaf containing the OP_VAULT opcode, the spending key, and the delay parameter
• a recovery leaf containing OP_VAULT_RECOVER and the recovery key
• optionally, additional spending conditions for specific use cases

When the trigger leaf is spent, OP_VAULT enforces that the resulting output contains the same taptree with the trigger leaf replaced by a finalization leaf (which includes the CSV delay). This tree-surgery mechanism preserves the recovery path in the intermediate output, ensuring the clawback remains available throughout the delay period. The approach avoids pre-computing every possible transaction, instead relying on Script-level enforcement of structural invariants.

Comparison with Existing Vault Approaches

OP_VAULT was not the first vault proposal for Bitcoin. Several approaches existed before BIP-345, each with distinct tradeoffs. Understanding these alternatives clarifies what OP_VAULT aimed to improve.

Pre-Signed Transaction Vaults

The earliest vault design, proposed by Bryan Bishop in 2019, used pre-signed transactions with deleted keys. The process works as follows: generate a temporary key, create and sign all possible vault transactions (trigger, delay, recovery), then securely delete the temporary private key. The remaining pre-signed transactions enforce the vault lifecycle without any Script changes.

The approach works today without any soft fork, but has severe practical limitations. Every deposit requires a fresh key ceremony with secure deletion. Withdrawal amounts must be fixed at vault creation time because the transaction outputs are pre-committed. Fee rates are locked in at signing time, which can result in transactions that are uneconomical or stuck during fee spikes. And if someone sends additional funds to a vault address after the keys are deleted, those funds are permanently lost.

OP_CTV-Only Vaults

With CTV alone, basic vault constructions are possible but less elegant. CTV can commit to a transaction chain that enforces a delay, but it cannot perform the taptree surgery that OP_VAULT enables. This means CTV-only vaults still require pre-computing the full transaction graph and cannot dynamically adjust withdrawal amounts or fee rates after vault creation. OP_VAULT was specifically designed to overcome these limitations by adding vault-specific state-transition logic on top of CTV's template enforcement.

Revault: Multi-Party Vaults

The Revault project, developed by Wizards Sardine, builds multi-party vaults using pre-signed transactions and watchtower enforcement. In Revault, N stakeholders co-own funds via N-of-N multisig, delegating day-to-day spending to designated managers. Emergency transactions allow any single stakeholder to sweep funds to a timelocked recovery address.

Revault works without consensus changes and handles multi-party governance, but inherits the pre-signed transaction limitations: fixed denominations, locked fee rates, and ceremony overhead per deposit. It also introduces a liveness requirement: all N stakeholders must be available to set up new vaults.

Use Cases for Vault-Based Custody

Cold Storage with Active Recovery

The primary use case for vaults is securing long-term Bitcoin holdings. Today, cold storage relies on keeping keys offline and hoping they are never compromised. A vault adds a second layer: even if cold storage keys are somehow extracted (through physical theft, social engineering, or supply chain attacks on hardware wallets), the delay period gives the owner time to detect and respond. Combined with an automated watchtower, this creates a custody model where compromise of a single key does not result in loss.

Inheritance Planning

Bitcoin inheritance is one of the most challenging problems in self-custody. Vaults offer a natural solution: the primary owner uses the spending key for normal access, while the recovery key is held by a trusted family member, attorney, or distributed across a Shamir's Secret Sharing scheme. If the primary owner becomes incapacitated, the recovery key holder can access funds through the vault's normal withdrawal process (trigger, wait, complete). If the recovery key is misused while the owner is alive, the owner simply claws back using the recovery path.

Institutional and Custodial Use

For institutions managing Bitcoin on behalf of clients, vaults provide a compliance-friendly key management model. The operational spending key can be held in a hardware security module (HSM) for daily operations, while the recovery key is kept in a separate jurisdiction or distributed across board members. The delay period provides an audit window: every withdrawal is visible on-chain before finalization, giving compliance teams time to review and intervene if necessary. This maps directly to the kind of approval workflows that regulated custodians already implement off-chain.

Current Status: From OP_VAULT to OP_CHECKCONTRACTVERIFY

James O'Beirne first posted the OP_VAULT proposal to the bitcoin-dev mailing list in January 2023. A draft implementation followed in February 2023 as Bitcoin Core PR #26857, alongside an implementation for Bitcoin Inquisition, the signet fork used for testing proposed soft forks.

In May 2025, O'Beirne formally withdrew BIP-345 in favor of BIP-443 (OP_CHECKCONTRACTVERIFY), authored by Salvatore Ingala. BIP-443 is a more general-purpose covenant opcode that can construct vaults but also enables broader capabilities like state-carrying UTXOs, on-chain state machines, and more composable covenant designs. The transition reflects a community preference for versatile primitives over single-purpose opcodes: rather than adding one opcode for vaults and another for each new covenant pattern, BIP-443 aims to provide a foundation that supports multiple use cases.

The vault security model defined by BIP-345 remains fully achievable under BIP-443. The withdrawal is the same: trigger, delay, complete or recover. What changes is the underlying opcode: OP_CHECKCONTRACTVERIFY replaces both OP_VAULT and OP_VAULT_RECOVER with a single, more general mechanism. For users, the vault experience would be indistinguishable.

Note: Neither BIP-345 nor BIP-443 is active on Bitcoin mainnet. Both proposals require a soft fork to activate, and no covenant soft fork has achieved consensus activation as of August 2026. The covenant debate remains one of the most actively discussed topics in Bitcoin protocol development.

Risks and Limitations

Recovery Key as a Single Point of Failure

The recovery key must be secured with extreme care. If both the spending key and recovery key are compromised, the attacker can trigger a withdrawal and immediately sweep funds to the recovery address (which they control). This risk can be mitigated by making the recovery path a multisig or threshold signature rather than a single key, but the fundamental requirement remains: the recovery key must be at least as secure as the vault itself.

Watchtower Dependency

The vault model assumes the owner (or their watchtower) will detect unauthorized trigger transactions during the delay window. If the owner is offline and has no watchtower running, an attacker with the spending key can wait out the delay and complete the theft. This creates a liveness requirement that does not exist with simple cold storage. The mitigation is straightforward (run a watchtower or use a watchtower service), but it is an additional operational requirement.

Soft Fork Activation Uncertainty

Covenant proposals have been discussed for years without reaching activation. The broader covenant activation debate involves fundamental disagreements about what covenant capabilities Bitcoin should support, whether to activate narrow or general-purpose opcodes, and how to evaluate recursive covenant risks. Until a covenant soft fork is activated, vaults remain a theoretical improvement rather than a deployable feature on mainnet.

Vaults and Layer 2 Payments

Vault-based custody on Bitcoin's base layer creates a natural complement to instant-settlement Layer 2 protocols. The use case is intuitive: keep the majority of holdings in a time-delayed vault for maximum security, while allocating a portion to a Layer 2 like Spark for everyday spending. This mirrors how traditional banking works: a savings account with withdrawal restrictions and a checking account for daily transactions.

For vault architectures that eventually deploy on Bitcoin, the integration with Layer 2 payment rails would enable a complete self-custodial financial stack. Long-term savings sit in vaults with recovery protection. Operational funds move to a Layer 2 where they can be spent instantly with low fees. Periodic rebalancing between the vault and the spending layer replaces the need for a bank.

Developers building on Bitcoin's custody stack can explore the Spark SDK documentation to understand how instant settlement works alongside base-layer security models. For users interested in a self-custodial wallet that supports both Bitcoin and stablecoins on Spark, General Bread provides a Spark-powered mobile experience designed for everyday payments.

Conclusion

BIP-345 OP_VAULT defined a clear, practical model for Bitcoin custody vaults: time-delayed withdrawals with emergency clawback to a pre-committed recovery address. Although the specific opcodes were withdrawn in favor of the more general BIP-443 OP_CHECKCONTRACTVERIFY, the vault security model persists as the most compelling use case for covenants on Bitcoin. For a deeper look at how Bitcoin Script enables these constructions, see our research on Bitcoin Script vaults and the broader OP_CTV proposal.

The path from proposal to activation remains uncertain, but the vault concept has already reshaped how the Bitcoin community thinks about self-custody. The question is no longer whether vaults are useful, but which opcode design best delivers them.

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.