Picture yourself three hours deep into a Bitcoin-dev mailing list thread, coffee gone cold, and you realize the two developers you've been reading are not disagreeing about the same thing. One is worried about miner extractability. The other is worried about recursive lock-in. A third voice, buried in a reply chain, is worried about key-holder trust. All three are arguing about safety. None of them are arguing about the same safety. The proposals themselves sit on genuinely different security foundations, and collapsing that distinction produces more heat than light.
So let's separate them.
What a covenant actually constrains
A Bitcoin covenant is a script condition that restricts not just who can spend an output, but how it can be spent: which outputs the spending transaction must create, what amounts those outputs must carry, sometimes even the shape of the entire transaction graph. The security question is always the same variant of the same thing. What has to be true, and who has to be trusted, for that constraint to hold?
`OP_CHECKTEMPLATEVERIFY` (BIP 119, proposed by Jeremy Rubin) is the minimalist answer. CTV commits a spending transaction to a single 32-byte hash of a template: output count, output scripts, output values, sequence numbers, and input count, all hashed together and checked at spend time. Nothing else. The constraint lives entirely in the UTXO itself, requires no signature, and involves no external party. A miner cannot selectively bypass it, because the rule is consensus-enforced. A counterparty cannot renegotiate it after the fact. The covenant cannot extend itself to a third output without the construction of an entirely new, separately authored UTXO chain.
That last property is the one that matters most. CTV covenants are non-recursive by construction. The hash commits to a fixed template, and once that template's outputs are spent, the covenant is gone unless the creator explicitly pre-committed another CTV output in the chain. No keys. No oracles. No external state. The security assumption is narrow by design: trust that the consensus rule is correctly specified and that miners enforce it.
Contrast that with the closest sibling proposals, and the differences become structural, not cosmetic.
`SIGHASH_ANYPREVOUT` (APO, BIP 118), designed for the Lightning Network's eltoo update mechanism, allows a signature to be detached from a specific previous output and rebound to any compatible one. The trust model shifts entirely. APO-based channels require participants to hold and protect signing keys across the channel's lifetime. If a key leaks, an old state can be re-signed against a new input. CTV carries no such attack surface, because there are no keys involved in enforcing the covenant itself. That is not a small difference.
`OP_CHECKSIGFROMSTACK` (CSFS) takes a different angle. It lets a script verify an arbitrary signature over arbitrary data placed on the stack, enabling constructions where an external oracle or a designated key-holder signs a message that the script then validates. The trust model expands accordingly: you are now trusting whoever holds that signing key. CSFS covenants can be powerful and flexible, but the security of the covenant is bounded by the security of the key. Lose the key, and an attacker can satisfy the covenant condition with a forged authorization.
Then there is `OP_CAT`, the simple concatenation opcode whose proposed reactivation has attracted attention disproportionate to its apparent simplicity. On its own, OP_CAT creates no covenants. Combined with CSFS, or with Schnorr signature introspection techniques (the CAT+CHECKSIG construction that Matt Corallo and others have analyzed in some depth), it enables recursive covenants: outputs that can enforce rules on their own descendants, indefinitely. This is where the security debate becomes genuinely thorny, and where I think the critics have the stronger case.
Recursion means a covenant can propagate. Think of it as a deed restriction that runs with the land in perpetuity rather than expiring at the first resale. Proponents point to powerful smart contract possibilities. The critics' concern is more specific: recursive covenants can create situations where coins become permanently constrained, potentially in ways the original owner did not anticipate, or in ways that allow a third party (a protocol, a DAO, or a government with access to a key-holder) to enforce spending rules across an entire UTXO lineage. The fungibility concern is not speculative. A bitcoin carrying a permanent covenant is not quite the same instrument as one without, and any honest treatment of the proposal has to confront that.
CTV avoids this entire class of problem by design. You can chain CTV covenants manually, pre-committing a sequence of templates before broadcast, but each link must be authored deliberately at creation time. There is no mechanism for a CTV covenant to spawn new covenant conditions at runtime. The chain is finite because finitude is baked into the hash.
Here is a worked scenario that makes the distinction concrete. Alice locks 2 BTC into a custody vault. With CTV, she pre-commits a fixed withdrawal template: one output to her cold wallet, a 24-hour delay enforced by sequence numbers. The covenant enforces exactly that template, full stop. With a CSFS-based vault, the withdrawal path requires a signature from a hardware security module she controls. Same goal on paper. But if that HSM is compromised, the covenant's enforcement guarantee collapses entirely to the strength of her key management. The threat surface is not the same. Treating them as equivalent, because both get labeled "vault," is a category error.
Are all these proposals worth the friction of a consensus change? That is a separate debate, and a legitimate one on which reasonable people differ. But which threat model you are actually evaluating depends entirely on which proposal you are reading. The proposals do not share a security foundation, and the sooner that is treated as the starting premise rather than a footnote, the more productive the conversation becomes.