OP_VAULT

OP_VAULT is a proposed covenant opcode described in BIP 345, authored by James O'Beirne with Greg Sanders. It is designed specifically to implement vaults: a self-custody pattern that adds a mandatory delay and a recovery path to any attempt to spend coins. OP_VAULT is a proposed soft fork and is not active on Bitcoin; it belongs to the covenant research family under community review, and it is typically discussed alongside a template-commitment primitive such as OP_CHECKTEMPLATEVERIFY, which BIP 345 leans on for its final-withdrawal step. Nothing here is available on mainnet today, and D-Central does not predict whether or when it activates.

How an OP_VAULT flow works

Coins held in a vault cannot be sent directly to an arbitrary destination. A withdrawal instead begins with a trigger transaction that moves the coins into an intermediate, publicly visible state and — critically — specifies the intended final destination at trigger time. Then a timelock window opens. During that window, the funds can be swept at any moment to a pre-committed recovery path — typically a deep cold-storage script under the owner's control — by anyone able to satisfy the (optionally gated) recovery condition. Only after the delay elapses can the withdrawal complete to the declared destination. The security model is refreshingly honest about compromise: if an attacker steals your hot key and triggers a withdrawal, you see the theft attempt on-chain before it settles, and you have the whole timelock window to fire the recovery and route everything to cold storage. Watchtower-style monitoring turns this from manual vigilance into an automated tripwire.

Why a dedicated opcode

Vaults can be approximated today with pre-signed transactions, and more cleanly with CTV alone — but both approaches force awkward constraints: fixed denominations decided in advance, fees locked in before fee markets are known, hazards around address reuse, and in the pre-signed case the operational burden of provably deleting ephemeral keys. OP_VAULT is designed to remove those limits: flexible amounts, partial withdrawals ("revaulting" the remainder), fees decided at spend time, and the ability to batch operations across multiple vaulted coins — at the cost of adding a specialized opcode to consensus, which is precisely the trade-off the review process weighs.

What you can do today

Since OP_VAULT ships nothing you can use now, the practical takeaways are directional. Today's closest approximations are multisig with geographically separated keys — which forces an attacker to compromise multiple locations rather than giving you a reaction window — and pre-signed vault constructions offered by some open-source tooling, which work but inherit the rigidity described above. Watching the covenant debate is worthwhile precisely because it decides whether reactive custody becomes a native primitive: the difference between building a vault out of duct tape and having the protocol understand what a vault is.

Why it matters even as a proposal

The problem OP_VAULT targets is arguably the hardest one in self-custody: a single key compromise today is usually game over, and even multisig only raises the number of keys that must be stolen — it offers no undo once a valid spend broadcasts. Vaults change the shape of the game from "never make a mistake" to "notice and react within a window," which is a far more humane security model for individuals guarding their own wealth without a corporate security team. That is why vault research persists across many designs: reactive security is the missing primitive. OP_VAULT builds on the general notion of a Bitcoin vault and sits within the broader covenant design space; this entry summarizes an open proposal, not a shipped feature.