OP_VAULT (Proposed)

What Is OP_VAULT?

OP_VAULT was a proposed Bitcoin soft fork (BIP-345) that introduced two new tapscript opcodes specifically designed for building vault contracts. A vault is a custody mechanism where coins are locked under spending rules that enforce a time delay on withdrawals, giving the owner a window to detect and reverse unauthorized transactions. Think of it like a bank vault with a time-lock door: even if someone gets the combination, the delay gives security personnel time to intervene.

Authored by James O'Beirne and Greg Sanders, the proposal aimed to solve a longstanding challenge in Bitcoin self-custody: how to protect funds against key compromise without relying on trusted third parties. Before OP_VAULT, vault constructions required either pre-signed transactions with risky key deletion, or general-purpose covenant opcodes that lacked vault-specific optimizations. OP_VAULT offered a dedicated, efficient solution built directly into the consensus layer.

While BIP-345 was ultimately withdrawn in favor of the more general BIP-443 (OP_CHECKCONTRACTVERIFY), its design established the benchmark for what Bitcoin vaults should achieve and directly influenced subsequent covenant proposals.

How It Works

OP_VAULT operates within Bitcoin's Taproot framework. Vault coins are encumbered in a Taproot output containing a taptree with at least two spending paths: a trigger leaf (containing OP_VAULT) and a recovery leaf (containing OP_VAULT_RECOVER). The vault lifecycle follows four distinct phases.

Phase 1: Vault Creation

Coins are sent to a Taproot address whose taptree encodes the vault rules. The taptree structure typically looks like this:

tr(<internal-pubkey>,
  leaves = {
    recover: <recovery-sPK-hash> OP_VAULT_RECOVER
    trigger: <trigger-auth-pubkey> OP_CHECKSIGVERIFY
             <spend-delay> 2 <leaf-update-script> OP_VAULT
  }
)

The trigger leaf requires a signature from the trigger authorization key and invokes OP_VAULT with a configurable spend delay. The recovery leaf specifies a pre-committed recovery destination (typically a cold storage address). The internal key is usually derived from the recovery wallet.

Phase 2: Trigger Transaction

To begin a withdrawal, the trigger key holder broadcasts a transaction that spends the vault UTXO via the trigger leaf. OP_VAULT enforces several constraints on this transaction:

• The trigger tapleaf is replaced with a new timelocked script containing OP_CHECKSEQUENCEVERIFY and OP_CHECKTEMPLATEVERIFY (CTV), which locks in the withdrawal destinations
• All sibling tapleaves in the taptree remain unchanged, preserving the recovery path
• An optional revault output can return a portion of the value to the original vault script, enabling partial withdrawals

The trigger transaction is visible on-chain, which is the critical property that enables monitoring. A watchtower or automated monitoring system can detect this trigger and alert the vault owner.

Phase 3: Withdrawal (After Delay)

Once the relative timelock (the spend delay) in the triggered output expires, the funds can be spent to the final destinations committed via CTV. The CTV hash ensures the exact outputs, amounts, and destinations match what was specified at trigger time.

Phase 4: Recovery (At Any Time)

At any point before the withdrawal transaction confirms, the recovery path can be invoked using OP_VAULT_RECOVER. This sweeps all funds to the pre-specified recovery address. Because the recovery leaf persists in the taptree even after triggering, the claw-back option remains available throughout the entire delay period.

OP_VAULT introduced the concept of "authorized recovery," requiring a signature from a recovery authorization key to invoke the recovery path. This prevents griefing attacks where a third party could repeatedly force funds into cold storage, making the vault unusable.

The Security Model

The vault uses a tiered key management hierarchy with distinct security levels:

If an attacker compromises only the trigger key, they can initiate a withdrawal, but the delay period provides time to detect the unauthorized trigger and invoke recovery. Compromising the trigger key alone is insufficient to steal funds.

Advantages Over Existing Vault Approaches

Before OP_VAULT, two primary vault constructions existed, both with significant limitations.

Pre-Signed Transaction Vaults

These vaults require no consensus changes but suffer from severe constraints:

• Withdrawal amounts and fees must be decided at vault creation time
• The signing keys must be securely deleted after setup: if deletion fails, the vault's security is void
• Each deposit requires a fresh vault setup; address reuse can cause loss of funds
• No partial withdrawals or batching of operations

CTV-Only Vaults

Vaults built solely with OP_CHECKTEMPLATEVERIFY (BIP-119) improve on pre-signed transactions but still require pre-committing the entire transaction tree at vault creation. This means no partial withdrawals, fixed amounts and destinations, and vulnerability to fee pinning attacks where adversaries chain low-fee transactions to block recovery.

OP_VAULT Improvements

OP_VAULT addressed these limitations with several key innovations:

• Dynamic withdrawal targets chosen at trigger time, not at vault creation
• Partial withdrawals through revaulting: withdraw some funds and return the rest to the vault
• Batching of trigger, withdrawal, and recovery operations across multiple vault UTXOs
• Safe address reuse with no risk of fund loss from recursive deposits
• No key deletion required at any stage
• Authorized recovery to prevent griefing attacks

Use Cases

High-Value Bitcoin Custody

The primary use case for OP_VAULT was protecting large Bitcoin holdings against key theft. Institutions and individuals holding significant Bitcoin in self-custody face a fundamental tension: keys must be accessible enough for legitimate spending but secure enough to resist theft. Vaults resolve this by making key compromise recoverable rather than catastrophic. For a deeper comparison of custody approaches, see the Bitcoin custody solutions comparison.

Inheritance Planning

Vaults enable dead-man's-switch constructions: heirs hold a trigger key and can initiate a withdrawal, but the original owner's monitoring system detects and reverses unauthorized attempts while they're alive. If the owner becomes incapacitated, the withdrawal proceeds after the delay without requiring third-party involvement.

Organizational Treasury Management

Companies or DAOs can use vaults to enforce withdrawal review periods. A finance team member triggers a withdrawal, but management has a window to review and recover if the transaction is unauthorized or incorrect. This creates an on-chain approval workflow enforced by consensus rules.

Exchange Cold Storage

Exchanges storing customer funds can use vaults to add a recovery window to their hot wallet operations. Even if an attacker compromises the hot wallet infrastructure, the delay provides time for security teams to detect the breach and sweep funds to recovery.

Why It Matters

OP_VAULT represented a significant step forward in Bitcoin's programmability story. While Bitcoin Script has historically been deliberately limited compared to general-purpose smart contract platforms, the vault use case demonstrated that targeted consensus changes could dramatically improve custody security without introducing broad programmability risks. For more on Bitcoin's scripting capabilities, see the Bitcoin Script programmability research article.

The proposal also advanced the broader covenant discussion in Bitcoin development. By providing a concrete, well-analyzed use case with a working implementation, OP_VAULT gave the community a benchmark against which to evaluate competing covenant proposals. Its successor, BIP-443 (OP_CHECKCONTRACTVERIFY), directly inherits key design elements including amount preservation checks and deferred cross-input verification.

Layer 2 protocols like Spark also benefit from Bitcoin's evolving covenant landscape. More expressive on-chain spending conditions can enable more efficient channel constructions, improved exit mechanisms, and stronger security guarantees for off-chain protocols built on top of Bitcoin.

Current Status

BIP-345 was formally withdrawn by James O'Beirne in May 2025. In his withdrawal announcement, O'Beirne stated that OP_VAULT "has been essentially replaced" by Salvatore Ingala's OP_CHECKCONTRACTVERIFY (BIP-443), describing it as "a more general version of the VAULT design" with a smaller implementation footprint and full functional parity for vault use cases.

BIP-443 replaces the same opcode slot (OP_SUCCESS187) that OP_VAULT used and offers greater generality: it can replace multiple tapleaves rather than just one, and supports state-carrying UTXO models beyond vaults. However, its recovery model differs: BIP-443 uses keyless recovery (anyone can trigger recovery), while OP_VAULT's authorized recovery required a specific key.

OP_VAULT was never activated on Bitcoin mainnet. A draft implementation existed for Bitcoin Inquisition (a signet-based testing fork), and the proposal depended on concurrent deployment of OP_CHECKTEMPLATEVERIFY (BIP-119), which also remains unactivated as of 2026.

Risks and Considerations

Complexity of Key Management

OP_VAULT required managing three distinct keys at different security levels. Misconfiguring the key hierarchy, losing the recovery key, or failing to secure the trigger key could undermine the vault's security model. The three-key requirement added operational complexity compared to simpler two-key CTV vault designs.

Monitoring Requirements

The vault's security depends on detecting unauthorized trigger transactions during the delay period. This requires a reliable watchtower or monitoring infrastructure. If the monitoring system fails during the delay window, an attacker who compromised the trigger key could complete the withdrawal undetected.

Consensus Change Risk

Any soft fork to Bitcoin carries inherent risk. OP_VAULT would have introduced new validation logic into the consensus layer, and bugs in this logic could have created vulnerabilities affecting all Bitcoin users. The Bitcoin development community applies a high bar to consensus changes, which contributed to the lengthy review process.

Superseded Design

With BIP-345 withdrawn, implementations targeting OP_VAULT specifically would need to migrate to BIP-443 or another covenant mechanism. The shift from purpose-built to general-purpose covenant opcodes reflects a broader trend in Bitcoin development: favoring composable primitives over specialized opcodes.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.