Bitcoin Vault

A Bitcoin vault is a custody construction that adds a mandatory delay and a recovery path to the spending of coins, so that a theft attempt can be detected and reversed before it settles. Rather than a single key moving funds instantly and irreversibly, a vault requires a withdrawal to first be triggered, after which an enforced time delay elapses before the coins can actually leave. During that window, the rightful owner can invoke a separate recovery key to claw the funds back to safety — even if the primary spending keys have been fully compromised. It converts Bitcoin custody's harshest property, "a stolen key means instant loss," into a system with an alarm and an undo button.

Trigger, delay, and clawback

A typical vault flow has three stages. An unvaulting (trigger) transaction announces a withdrawal on-chain and starts the clock. A script-enforced delay period follows — hours or days, chosen by the owner — during which the pending spend is visible to anyone watching but cannot complete. Then either the withdrawal completes normally to its intended destination, or the owner (or an automated watchtower monitoring on their behalf) broadcasts the clawback, sweeping the coins to a deep recovery path — ideally keys held in cold storage under stricter protection than the everyday keys. Security rests on an asymmetry: the attacker must win during a public, time-boxed window, while the defender pre-arranged their response before the game began.

The model does impose duties. Someone must actually watch the chain during every delay window — the owner, their node, or a watchtower-style service holding the pre-signed clawback — and the delay length is a real trade-off: long enough that a weekend offline does not equal an unwatched theft window, short enough that legitimate withdrawals are not a bureaucratic ordeal. The recovery path itself becomes the crown jewel, and it must be protected accordingly.

The concept even has a centralized shadow: exchange withdrawal delays and allow-lists are vaults built from customer-service policy instead of script. The on-chain version makes the same promise without the custodian — which is, of course, the entire point.

How vaults are built today — and tomorrow

Vaults can be approximated with today's Bitcoin using pre-signed transactions and timelocks: sign the only permitted spending paths in advance, then delete the signing key so no other path can ever be authorized. It works, but it is operationally fragile — key deletion cannot be proven, every possible amount needs its own pre-signed chain, and one lost file can strand funds. Making vaults robust is a flagship motivation for covenant research: proposed opcodes that let an output constrain where it may be spent next. BIP345's OP_VAULT proposes vault-specific covenants with delayed unvaulting and dynamic withdrawal targets, while OP_CHECKTEMPLATEVERIFY can express simpler fixed-template designs; related work explores the same territory through other primitives. Every one of these remains a proposal pending a consensus change — no vault opcode is active on Bitcoin today, and this entry describes research direction, not shipping features.

Why it matters for self-custody

Vaults attack the honest weak point of self-custody: humans. Seed phrases get photographed, wrench attacks happen, and a multisig quorum — excellent as it is — still settles instantly once enough keys sign under duress. A vault adds the one defense money has always wanted: time. A visible delay drains the value of coercion (the attacker must hold their leverage for days, in public) and gives monitoring infrastructure a window to respond. For the sovereign holder, that is the point of the whole research program — making it ever safer for individuals, not custodians, to hold serious value on their own keys. Robust vaults are how self-custody scales from the technically fearless to everyone else.