Covenant (Bitcoin)

A covenant is a spending condition that constrains how bitcoin may be spent in the future, rather than only who may authorize the spend. Today, a standard Bitcoin script asks a single question: does the spender hold the right key or preimage? A covenant adds a second class of question: does the transaction that spends this output send the coins to a permitted destination, in a permitted amount, with a permitted structure? Covenants are not active on Bitcoin's base layer; they are a family of proposed and experimental soft-fork ideas under ongoing community review, and this entry describes the research landscape, not a shipped feature.

What covenants would enable

The flagship application is the vault: a covenant-encumbered UTXO that can only be spent to a staging address, from which funds must wait out a delay before moving anywhere else — and during that delay, a recovery key can claw everything back to deep cold storage. A thief who steals your keys still cannot bypass the timelock, and you get an alarm and an undo button that self-custody currently lacks. Beyond vaults, covenant proposals enable congestion-control payment trees (commit to many payouts in one transaction now, unroll them when fees are low), payment pools where many users share a single UTXO, and more flexible Layer 2 constructions that reduce the interactivity Lightning-style protocols require. For sovereign users, the theme is consistent: covenants would let the chain itself enforce safety rails that today require trusted co-signers or constant vigilance.

Why they are debated

The trade-off is expressiveness versus restraint. A tightly scoped covenant applies to one forward hop only: this coin must next move to that template, and afterward is free. A broad one can re-impose its own rules on every coin that descends from it — a recursive covenant — raising uncomfortable questions: could coins be permanently encumbered, could an authority mandate covenant-wrapped "compliant" coins, does fungibility survive? Proponents respond that opt-in restrictions on your own coins are just contracts, that useful recursion is hard to achieve accidentally, and that the dangerous scenarios require coercion that could be applied with or without covenants. Reasonable engineers disagree about where to draw the line, which is a large part of why no single proposal has reached consensus — and by Bitcoin's conservative standards, that caution is working as intended.

How they are built

Most designs introduce transaction introspection: a way for a script to inspect fields of the spending transaction — outputs, amounts, scripts — and reject spends that do not match a committed template. Proposals differ mainly in how much they expose and how composable they are. OP_CHECKTEMPLATEVERIFY (BIP119) sits at the minimal end, committing to a hash of the spending transaction's essential fields; other designs pair introspection opcodes with Schnorr-based signature tricks to get similar effects with different trust and flexibility profiles. Interestingly, some covenant-like behavior is already achievable today through presigned transactions and deliberately destroyed keys — covenant opcodes would make those constructions trustless instead of trust-minimized, removing the need to trust that a key was really deleted or that a signing ceremony was really honest.

Proposals are evaluated on safety, simplicity, and review maturity rather than feature count, and activation requires the same broad consensus as any soft fork. D-Central's read: covenants are the most consequential open design question on Bitcoin's roadmap for self-custody, worth following closely and predicting cautiously. Whatever ships — if anything ships — will have survived years of adversarial review, and for a system securing this much value, that slow grind is a feature, not a failure. These notes reflect our reading of the current research; they are not predictions about activation.