Covenant

Every script on the chain answers one question: is this spend authorized? A covenant would let the script ask a second question about the transaction spending it, and the proposals to allow that (BIP-119, BIP-118, BIP-345, BIP-347) have all sat unactivated for years. Nothing you hold today is affected, but the vault and inheritance products people keep asking for are waiting on this.

How it works

Status: no covenant opcode is active on Bitcoin mainnet. Every design below is a proposal, and none has activation parameters merged into Bitcoin Core.

The missing capability has a precise name: introspection. When a node runs a script, the script can look at signatures, hashes, timelocks and the stack, but it cannot read the outputs of the transaction that is spending the coin. That single blind spot is why bitcoin can express "two of these three people must agree" and cannot express "this money may only move to that address".

Proposals close the gap in two different ways, and the difference between them is the heart of the argument.

The template approach commits to a hash of the whole spending transaction in advance. OP_CHECKTEMPLATEVERIFY works this way: the output holds a 32-byte hash, and the spend fails unless the transaction hashes to the same value. It is narrow, it is cheap to verify, and because the commitment cannot describe another commitment, the restriction cannot repeat itself indefinitely.

The introspection approach gives script the parts and lets it do arithmetic. Combining OP_CAT with a signature check, or adding OP_CHECKSIGFROMSTACK, lets a script rebuild the transaction's signature hash from pieces on the stack and verify it, at which point the script can require anything it likes about the outputs. This is general, and it is recursive: a covenant can insist the next output carries the same covenant.

Recursion is the objection that has slowed everything down. Coins locked into a self-perpetuating rule could in principle stay encumbered forever, which raises questions about fungibility and about issuers who might mandate the rule. The counterargument is that a group of people can already fake a covenant by pre-signing the only allowed spend and destroying the key, so the capability exists in practice and consensus enforcement mainly removes the need to trust that the key really was destroyed.

Where you see it

Covenants are already deployed on chains that copy bitcoin's script engine, which is the cheapest way to see what they do.

Liquid, the Elements based sidechain, runs a tapscript with introspection opcodes that read the spending transaction's outputs directly, and its federation uses them for its peg. Anyone can also test the proposed bitcoin opcodes on custom signets before deciding whether they would like them on mainnet.

On mainnet, the substitute is a pre-signed transaction with a deleted key. A vault provider generates the deposit key, signs the only withdrawal it will ever allow, then destroys the key so no other spend can be created. That is a covenant enforced by a promise instead of by the network, and the promise is exactly what a real covenant opcode would make unnecessary. Worth knowing if a service sells you a vault: ask which of the two it is.

Covenant vs escrow contract

A covenant restricts the destination; an escrow contract restricts the signers. They solve different halves of the same worry and only one of them is available.

An escrow contract is ordinary multisig with a third party in the quorum, usually two-of-three, and it works on bitcoin now: a marketplace holds a key, and the buyer and seller can settle without it or call it in to break a dispute. What escrow cannot do is constrain the outcome. The moment a spending quorum forms, the coins can go anywhere, including to the arbiter. A covenant would fix the destination in advance and take the arbiter's discretion out of the design entirely.