You've just received a bitcoin payment and you want to lock it so it can only ever move to one specific next address, regardless of who holds the keys. You open a script editor. You start typing. Somewhere around line three, you hit the wall that has occupied protocol researchers for the better part of a decade: Bitcoin's scripting language was deliberately designed to be ignorant of its own transaction context. A coin doesn't know where it's going. Covenants fix that. What they disagree on is how, and buried in that disagreement are two genuinely different theories about what Bitcoin should trust.
What covenants are actually arguing about
A covenant is any mechanism that constrains how a UTXO can be spent in the future, beyond the usual signature check. The three most-discussed live proposals are OP_CHECKTEMPLATEVERIFY (CTV), OP_CHECKSIGFROMSTACK (CSFS), and MATT (Merkleize All The Things). Each one draws the line between "allowed" and "forbidden" in a different place, and those lines encode assumptions about miners, about recursion, and about who you're actually worried about.
CTV, proposed in BIP 119, is the most constrained. It commits to a hash of specific output fields: amounts, scriptPubKeys, sequence numbers, the number of inputs. A script using CTV essentially says the only valid spending transaction is the one whose template hash matches this value, precomputed and baked in at coin creation. There is no recursion by default, because the template is fixed. Want to build a chain of vaults? You chain CTV hashes manually, hop by hop, writing out each step at creation time. Think of it less like programming and more like printing a boarding pass: every stop on the itinerary is stamped before the journey begins.
That rigidity is a feature, not a bug, from the perspective of miner trust. Because CTV's constraint is purely introspective (does this transaction's template hash match?), miners have nothing extra to evaluate. They run the hash check. It either passes or it doesn't. There is no way for a miner to influence the outcome by choosing what data to include in a block. CTV's security assumption is essentially identical to the one Bitcoin already relies on, which is precisely the point its advocates press hardest.
CSFS is more expressive. It lets you place an arbitrary message on the stack and verify a signature against it, which means you can require that a spending transaction include a signature over its own fields. Combined with OP_CAT (the concatenation opcode re-enabled on some sidechains and itself a separate, ongoing debate), CSFS can replicate CTV's behavior and go further. The critical difference: CSFS makes it possible to construct recursive covenants, ones that re-commit to themselves in every output indefinitely. A coin could theoretically require every future owner to satisfy the same spending condition, forever.
That is where miner honesty enters more seriously. A recursive covenant restricting which addresses funds can ever reach is, in principle, a tool for blacklisting. The concern isn't that CSFS itself introduces new miner power. It's that the expressive surface area is large enough that social and legal pressure on miners to evaluate covenant compliance grows with it. The mechanism is neutral. The environment it operates inside is not, and pretending otherwise is the kind of category error that tends to age poorly.
A worked scenario
Consider two developers, Priya and Tobias, both building a vault product. Priya uses CTV: she writes out a five-step withdrawal sequence at coin creation, each step hash-committed to the next. If she constructs the chain correctly, verification is essentially audit-free at spend time. Tobias uses CSFS with recursive re-commitment so the vault policy can update dynamically. His vault is more flexible. But every spending transaction now requires miners and verifying nodes to evaluate whether the recursive condition is satisfied. Same end-user goal, same business problem. Very different trust surfaces.
MAT takes a different approach entirely. Rather than constraining transaction fields directly, it proposes that coins commit to a Merkle tree of computational state, with spending allowed to update that state according to verified rules. It is closer to a miniature virtual machine embedded in Bitcoin's UTXO model. The recursion is explicit and bounded by the state machine's design rather than open-ended. This is the most expressive of the three by a wide margin, and it makes the strongest assumptions: that you can specify the state machine correctly at creation time, and that miners will faithfully execute it.
So ask yourself this: when you are building financial infrastructure meant to survive a decade, how much do you want to bet on miner diligence?
The honest caveat, and it matters: none of these proposals have been activated on Bitcoin mainnet, and the technical details of each continue to be refined in public forums and BIP discussions. Arguments about recursion enabling blacklisting describe attack surfaces, not demonstrated exploits. Protocol designers who favor CTV often say they are not opposed to expressiveness in principle, only to expressiveness that arrives before the community has reached consensus on its risks. That is a defensible position, even if critics read it as indefinite delay dressed up as caution.
What the whole debate ultimately reveals is that Bitcoin's conservatism is not accidental. Every new opcode is a new assumption about what miners will and won't do with it. CTV bets that miners stay dumb and fast. CSFS and MATT bet that they stay honest and careful. Those are different bets. The Bitcoin community has historically preferred the former, and given the stakes involved, that preference deserves more credit than it usually gets in discussions dominated by developers eager to build.