Covenants

Anna keeps savings in Bitcoin. A wallet is an application or device for receiving and sending bitcoin. The balance displayed by her wallet consists of unspent outputs from earlier transactions, called UTXOs. Each output records an amount and the conditions for spending it. Those conditions are written in a short program called Bitcoin Script. A digital signature provides proof of authorization for a payment using a private key, a secret numerical value, without revealing that key. Multisig can require several signatures, while a Timelock adds a waiting condition. A covenant can also restrict the structure of the next transaction, such as the outputs the funds must move to. Even a thief with the right key would have to satisfy that rule. However, every available spending path matters: if another branch allows the restriction to be bypassed, it cannot be relied upon. [1] [5] [9] [11]

Imagine Anna places her savings in a vault with a delay. Here, a vault means an arrangement of spending rules, not a special device. Her everyday key could initiate a withdrawal, but the funds would first move into a waiting output. Only after the delay could they continue to the intended recipient. If a thief initiated the withdrawal, Anna could use a recovery path prepared in advance to move the funds under safer conditions during the waiting period. She must notice the withdrawal and get the recovery transaction confirmed in a block in time. A block groups transactions into a batch added to the shared history. This does not reverse a completed payment or rescue funds automatically without intervention. The exact options depend on the vault’s design. [6] [10]

An app’s promise to delay a withdrawal may be no more than its operator’s promise. A rule in a Bitcoin script, by contrast, is checked by nodes: programs that verify transactions against the network’s shared rules. With an appropriate covenant construction, they must reject a transfer that violates the restriction. One proposed tool is OP_CHECKTEMPLATEVERIFY, or CTV, described in BIP119; a BIP is a document proposing something for Bitcoin. CTV would compare a hash of selected data in the transaction being checked with a fingerprint recorded in advance. Think of a hash here as a short checkable fingerprint of data. Changing a prescribed recipient or amount would change that fingerprint, so a transfer that does not match the template would fail the check. Merely calling something a “vault” in an app does not provide this enforcement. [2]

CTV binds a transaction to a template prepared in advance, including its outputs. It is not the only approach being studied. BIP443 proposes OP_CHECKCONTRACTVERIFY for outputs carrying a verifiable commitment to particular data. Here, a commitment means that a different value cannot later be substituted without the check detecting the mismatch. The data can describe a contract’s state, such as the current allocation of shared funds. The next output can then carry an updated state if the prescribed rules are met. CTV and this proposal are therefore not two names for the same thing. For each design, ask what must be fixed in advance, what may change later, and which other tools the complete construction needs. [2] [7]

A recursive construction can require the next output to carry a restriction again. The rule can thus continue across several transactions, for example as a contract’s state evolves. This does not mean an endless loop while checking one script. Russell O’Connor and Marta Piekarska described such constructions in their 2017 paper; whether repetition is possible depends on the particular proposal. [3]

Some restrictions can be arranged with presigned transactions, timelocks and key management. Such a setup may require reliable key deletion, retention of all transactions or further cooperation. Multisig relying on another signer to refuse an unsuitable payment introduces a different trust assumption. A similar user experience does not imply identical enforcement or recovery options. [5] [6]

Beyond vaults, researchers study shared UTXOs and preparations for payments whose settlement is spread over time. The aim can be less ongoing cooperation or better use of block space. This does not imply unlimited transactions or guaranteed low fees. A design must also explain an individual participant’s exit, unavailable peers and fee payment during congestion. [2] [7]

As of 17 October 2026, BIP119 and BIP443 have Draft status, meaning proposals still in development. The older BIP345, OP_VAULT, is Closed and lists BIP443 as its proposed replacement. Closing that document does not mean vault research has ended. Likewise, assigning a BIP number does not mean the network has adopted the change. A test network or demonstration wallet can show a feature while the rules of Bitcoin’s main network, mainnet, remain unchanged. When a service offers a covenant vault, check which network and rules it actually uses. [6] [8]

An overly narrow template or a mistake in amounts, scripts or fee handling can prevent the intended spend. New operations also expand what implementations must validate safely. Consensus changes therefore need evaluation against their precise specification and failure behavior. A covenant does not itself give someone else the right to retroactively change the conditions of your existing UTXOs. [4] [8]

For a particular solution, ask who can initiate withdrawal or recovery, how long the response window lasts and whether somebody must continuously monitor the chain. Check backups, fees, exit options and the network where it actually works. Covenants could extend your control over money; seeing the word in a product description does not establish that control. [3] [6]