Covenants: Restricting How Coins Move

Today, a Bitcoin output asks one question: “do you have the right to spend me?” — a signature, a hash preimage, a timelock. Once you satisfy it, you can send the coins anywhere. A covenant changes the question to: “do you have the right to spend me, and does your spend send the coins somewhere I approve of?” In other words, a covenant lets a coin constrain the shape of the next transaction, not just who authorizes it.

Status: covenants are a family of PROPOSALS

With narrow, contested exceptions, general covenants are not part of Bitcoin consensus today. The specific opcodes below (CTV, APO, and others) are proposed and would require a soft fork to activate. None should be described as a deployed Bitcoin feature. This page explains why people want them and why the debate is hard.

What a covenant actually constrains

Normal spending authorizes whether coins move. A covenant additionally constrains where and how.

NORMAL output:    "valid signature?  → spend to ANY destination"
COVENANT output:  "valid signature?  AND next tx matches a TEMPLATE?  → spend"
                   e.g. "you may only send these coins to address X, or back to this vault"

That small addition is surprisingly powerful, because it lets a coin enforce rules on its own future even when the spender would prefer otherwise.

Why anyone wants them: the use-cases

• Vaults. The headline use-case. A vault forces withdrawals through a two-step, time-delayed path: a spend can only go to a “staging” output, which then needs a waiting period before the funds can leave — during which the rightful owner can trigger a claw-back to a recovery key. If a thief steals your keys, the covenant means they still can’t sweep the coins instantly; you get a window to react. This is meaningfully better custody than “whoever has the key wins.”
• Congestion control. Commit now to a single transaction that promises to pay many recipients later, settling the fan-out when fees are low. An exchange could acknowledge thousands of withdrawals with one on-chain commitment and expand them afterward.
• Secure custody and shared protocols. Covenants make many layer-2 and pooling constructions cheaper and more robust — non-interactive channel funding, payment pools, and similar — by letting an output dictate the structure of what comes next without every party staying online to re-sign.

The unifying theme: covenants let you pre-commit to good behavior in a way the protocol enforces, which is exactly the kind of thing that helps mutually distrusting parties cooperate.

The leading proposals (all proposed)

OP_CHECKTEMPLATEVERIFY (CTV, BIP 119)   SIGHASH_ANYPREVOUT (APO, BIP 118)
"the spending tx must EXACTLY match      "let a signature NOT commit to which
 this committed template (outputs,        specific input it spends, so it can be
 amounts, etc.)"                          re-bound to a different prior output"

→ a narrow, non-recursive covenant       → enables eltoo-style channel updates
  primitive; simple to reason about         (simpler Lightning), and covenant-like
                                            patterns

• OP_CHECKTEMPLATEVERIFY (CTV / BIP 119) — proposed. The minimalist approach: an output commits to a hash of the exact next transaction’s template. The only valid spend is one that matches. Deliberately limited (you can only point to a fixed future transaction), which proponents argue makes it safe and easy to audit.
• SIGHASH_ANYPREVOUT (APO / BIP 118) — proposed. A new signature-hash mode that lets a signature not commit to the specific output being spent, so it can be re-bound to a different prior. Its flagship motivation is eltoo, a simpler Lightning channel-update mechanism that drops the harsh penalty model. APO enables covenant-like behavior as a side effect.

Other proposals exist (OP_VAULT, OP_CAT re-enablement, and more); the field is active and no single design has consensus.

The debate: recursion and risk

Why hasn’t Bitcoin just added covenants? Because the power that makes them useful is the same power people fear.

• Recursion. A recursive covenant is one whose constraints can require that the next output also carry a covenant, and so on — potentially forever. Critics worry this could create coins that are permanently encumbered, enabling, in the extreme, censorable or “tainted” money, or protocol-level restrictions no one can escape. (Note: simple designs like CTV are non-recursive; the recursion concern applies most to more general primitives.)
• Fungibility. If some coins carry rules others don’t, are all bitcoins still interchangeable? Encumbered coins might be valued differently, eroding fungibility.
• Irreversibility and scope. A soft fork is effectively permanent. Adding a powerful, general primitive that turns out to have unforeseen uses (good or bad) is a one-way door — hence intense caution.

Genuine, unresolved disagreement

This is not settled. Reasonable, expert people disagree about whether to add covenants, which proposal is safest, and how much expressiveness is wise. Be skeptical of anyone who presents covenants as obviously good or obviously dangerous. As of this writing they remain proposed, debated, and unactivated.

The thread

How does this help untrusting strangers agree on one ledger? Covenants extend Bitcoin’s core trick — let the protocol, not a person, enforce the deal — from “who may spend” to “how the coin may move next.” Done well, that lets strangers build vaults and pooled protocols where misbehavior is structurally impossible, deepening trustlessness. Done carelessly, it risks coins that carry permanent baggage and a ledger whose units are no longer cleanly interchangeable. The reason the debate is slow is that Bitcoin treats changes to what the shared ledger even permits with the seriousness they deserve.

Check your understanding

1. In one sentence, how does a covenant change the question an output asks compared with a normal output?
2. Explain the vault use-case: how does a time-delayed, claw-back-able withdrawal protect you even if a thief has your key?
3. Contrast CTV and APO: what does each actually do, and what is each primarily motivated by?
4. What is a recursive covenant, and why does recursion drive the strongest objections? Which proposals are non-recursive?
5. Why is the covenant debate unusually cautious — what makes adding such a primitive a “one-way door”?