Bitcoin Vault is a custody construction with separate withdrawal stages. Starting a withdrawal opens a period in which the construction’s rules allow funds to move to a safe recovery path. It is not the name of a single activated opcode or just another term for a hardware wallet.
In an ordinary single-signature wallet, a thief holding the key can create a direct payment. A vault aims to constrain that immediate escape: an operational key starts the process but should not alone bypass the delay and recovery path. The key question is which combinations of keys can pay directly and which must use an intermediate state. A vault label or an app-delayed transfer alone does not establish blockchain enforcement. [BIP 345 — OP_VAULT]
The model distinguishes a deposited UTXO, a confirmed unvault intermediate output and a completed payment. If an intermediate output confirmed at block H requires 144 blocks for the ordinary withdrawal branch, that branch can become usable no earlier than H+144, subject to the other conditions. The recovery branch should permit earlier intervention. This is neither exactly 24 hours nor an automatic payment reversal: an effective intervention must beat the final confirmed spend. [BIP 345 — OP_VAULT] [BIP 112 — CHECKSEQUENCEVERIFY]
Some constructions use current rules and presigned transactions. They constrain alternative spends by requiring one-time signing keys to be securely deleted, or requiring additional independent parties to authorize an alternative. The network does not itself prove key deletion. A retained secret copy may bypass the intended path. Presigned transactions also form part of recovery: a seed alone may not recreate signatures made by a key that has been removed. [BIP 345 — OP_VAULT] [Revault — Transaction specification]
The Revault specification distinguishes stakeholders, managers and cosigning servers. Its deposit output uses N-of-N stakeholder keys; the unvault output permits the stakeholder path or the managers-and-cosigners path after X blocks. Cancel returns the unvault output to the deposit policy, while emergency goes to an Emergency Deep Vault. A stakeholder-signed bypass also exists. This model therefore does not guarantee a delay if all stakeholder keys are compromised and does not describe every vault. [Revault — Transaction specification]
At the 8 September 2026 review, BIP 345 is Closed and lists BIP 443 as its Proposed-Replacement. It originally combined OP_VAULT and OP_VAULT_RECOVER with OP_CHECKTEMPLATEVERIFY. BIP 443 proposes the more general OP_CHECKCONTRACTVERIFY, or OP_CCV, and is Draft; its activation mechanism is undecided. BIP 119 is also Draft. A BIP number, test implementation or published vault example does not by itself establish activation of those rules on Bitcoin mainnet. [BIP 345 — OP_VAULT] [BIP 443 — OP_CHECKCONTRACTVERIFY] [BIP 119 — CHECKTEMPLATEVERIFY]
A monitor must recognize an unexpected withdrawal, not merely see a transaction. Responding requires a valid recovery transaction, reachable network and sufficient fees. Mempool submission is not confirmation; congestion, pinning or an unsuitable fee-bumping strategy can waste the window. Revault specifies CPFP and, for some recovery transactions, ALL | ANYONECANPAY to add fee-paying inputs. Its historical rates are not recommendations for today’s fee. [BIP 345 — OP_VAULT] [Revault — Transaction specification]
Redirecting funds to a recovery script only helps if the rightful owner can later satisfy its conditions. Unavailable keys, missing configuration or lost presigned transactions may replace theft with permanent self-lockout. A recovery branch that is too easy to trigger can also enable harassment through repeatedly cancelled withdrawals. Distinguish permission to trigger the protective move from permission to spend from its destination, and verify both roles. [BIP 345 — OP_VAULT] [Revault — Transaction specification]
Verification should enumerate every withdrawal and bypass path, consensus assumption, required backup and response time. A separate test setup should cover ordinary withdrawal, an early attempt, unexpected unvault, monitor failure and unavailable fee funds. Results must distinguish a valid signature, mempool acceptance and confirmation. A successful demonstration of one scenario does not prove every branch secure; these models are not instructions to fund an experimental script with real money. [BIP 345 — OP_VAULT] [Revault — Transaction specification]
For the clearest picture, read this entry together with Bitcoin covenants, OP_CHECKTEMPLATEVERIFY, Timelock, Multisig, Bitcoin Inheritance Plan, Self-custody. The reverse links also lead from Bitcoin covenants, OP_CHECKTEMPLATEVERIFY, Dead Man’s Switch.