Home › Glossary › Vault

Vault

Also called: vaults, Bitcoin vault, OP_VAULT, covenant vault, reactive security.

A vault holds bitcoin so that withdrawals must wait out a delay, during which the owner can send the coins to a safe recovery address instead.

A vault is a custody setup that adds a waiting period to withdrawals. Spending happens in two steps: first a withdrawal is triggered on-chain, then, only after a delay such as a day, the coins can move to their final destination. During the delay the owner can claw them back to a pre-chosen recovery path, typically a key kept in very secure cold storage. If a thief steals the everyday key, the owner sees the trigger and sweeps the coins to safety before the theft completes.

How vaults can be built

  • Today, with pre-signed transactions. The trigger, withdrawal and recovery transactions are signed in advance with a key that is then deleted. This works under current rules, but as BIP 345 describes, it requires secure key deletion, fixed amounts and careful backup of the pre-signed transactions.
  • With covenant opcodes. A covenant lets the script itself enforce the trigger, delay and recovery structure. BIP 345 (OP_VAULT and OP_VAULT_RECOVER, by James O'Beirne and Greg Sanders) was designed for this, used together with BIP 119 CHECKTEMPLATEVERIFY, whose references include simple CTV vault designs. BIP 347 notes that OP_CAT is enough to build vaults, and BIP 443 (OP_CHECKCONTRACTVERIFY) offers a general building block whose motivation includes the same two-step withdrawal. Template opcodes such as BIP 446 can likewise fix the withdrawal transaction in advance.

Building blocks

Vaults rely on relative timelocks (OP_CHECKSEQUENCEVERIFY, BIP 112) for the delay, and on fee bumping, such as anchor outputs, so the recovery transaction confirms quickly when it matters.

BIP 345 also notes a side benefit: a long, provable delay makes coercion (the "$5 wrench attack") less useful. See the covenants guide for how the vault proposals compare.

BIPs that define Vault

  • BIP 345: OP_VAULT: Closed. Proposes two new script instructions that let users lock coins in a 'vault': any withdrawal must first wait out a delay, during which the owner can redirect the coins to a pre-chosen safe recovery…
  • BIP 119 (OP_CHECKTEMPLATEVERIFY): CHECKTEMPLATEVERIFY: Draft. Proposes CHECKTEMPLATEVERIFY, a script instruction that restricts coins so they can only be spent in a transaction matching a predetermined template. This 'covenant' could enable vaults that protect…
  • BIP 443: OP_CHECKCONTRACTVERIFY: Draft. Proposes OP_CHECKCONTRACTVERIFY, an instruction that lets coins carry embedded data and restrict where they can be sent next and with what data. This lets users build multi-step contracts, such as…
  • BIP 347: OP_CAT in Tapscript: Complete. Brings back OP_CAT, an instruction that joins two pieces of data together, which was disabled in Bitcoin's early days over security concerns. Re-enabled only inside Taproot scripts, this simple…
  • BIP 446: OP_TEMPLATEHASH: Draft. Proposes OP_TEMPLATEHASH, a Taproot script instruction that produces a fingerprint of the transaction spending a coin. Scripts can use it to require that coins be spent only in a specific pre-agreed…

Related terms

  • Covenant: A covenant is a script rule that restricts where coins can be sent next, not just who can spend them; several Bitcoin proposals would enable them.
  • Timelock: A timelock is a rule that stops bitcoin from being spent until a set block height or time, or until the coin has aged a set amount since it confirmed.
  • OP_CHECKSEQUENCEVERIFY (CSV): OP_CHECKSEQUENCEVERIFY (CSV, BIP 112) is an opcode that blocks spending an output until it has aged a set number of blocks or time since it confirmed.
  • Anchor output: An anchor output is a small extra output on a pre-signed transaction that can be spent by a CPFP child to add fees when the transaction is broadcast.

Learn more

Guides