Short version: the proposals that would fix the statechain, Ark and Lightning problems (CTV, APO, CSFS) remove trust and add very little power to control anyone. The censorship worry is real, but it applies to recursive covenants, which those proposals were built to avoid. As of October 2026, none of them has activated.
1. The trust problem today
Statechains (e.g. Mercury Layer). A coin sits in a 2-of-2 key shared between the current owner and the statechain operator. To transfer it, the operator changes its key share so that its new share plus the new owner's share still controls the same coin. Then it is supposed to delete the old share.
- If it secretly keeps old shares, the operator plus any previous owner can sign together and take the coin from the current owner.
- The operator can't steal on its own; it needs a past owner to collude.
- Each owner also holds a pre-signed backup transaction with a shorter timelock than the one before. That limits how many times a coin can change hands, and the current owner has to stay online to get theirs confirmed first.
Nothing on-chain proves the deletion happened. You trust the operator's hardware and honesty.
Covenant-less Ark. Ark builds a tree of pre-signed transactions that gives each user an exit path. Without covenants, every branch is signed jointly by the operator and the round's participants, who then delete their temporary keys.
- In a normal round, you are one of the signers of your own branch, so most of the trust is in yourself. The cost is that everyone must be online at the same time to sign.
- Payments between rounds are different: the recipient trusts that the operator and the sender won't collude to double-spend the coin before it is refreshed in a new round.
2. What covenants would fix
A covenant is a rule in an output's script that limits the transaction allowed to spend it. Enforced by consensus, it replaces "we pre-signed this and promise we deleted the key."
- CTV (OP_CHECKTEMPLATEVERIFY, BIP 119): commits an output to one exact spending transaction. Ark trees can be built with no signing ceremony, so users don't need to be online together, and nobody has to delete anything. It also makes non-interactive channel opens, payment pools and simple vaults possible.
- APO (SIGHASH_ANYPREVOUT, BIP 118): lets a signature fit any earlier state of the same contract. This is what enables LN-Symmetry (formerly called eltoo).
- CSFS (OP_CHECKSIGFROMSTACK, BIP 348): checks a signature on arbitrary data. Combined with CTV, it can do most of what APO does, including LN-Symmetry.
- OP_CAT (BIP 347): joins two pieces of data. Combined with Schnorr signature tricks, it gives general transaction introspection, so it can build almost any covenant, including recursive ones.
- OP_VAULT (BIP 345): a purpose-built vault: coins can only leave through a delay, and you can claw them back during that window.
- A newer taproot-only bundle (OP_TEMPLATEHASH + CSFS + INTERNALKEY, BIP 446/448) is being proposed as an alternative to CTV + CSFS.
For statechains, an APO-style signature lets each transfer replace the previous owner's backup transaction instead of racing it with ever-shorter timelocks. That removes the limit on the number of transfers. The operator's key deletion still matters for the cooperative path, but the worst case gets much safer.
Lightning: penalty versus LN-Symmetry. Today, each update to a channel revokes the old state. If your peer broadcasts an old state, you have a window to send a "justice" transaction that takes all the channel's funds. The consequences:
- You or a watchtower must store data for every past state.
- An old backup is dangerous: restoring one and broadcasting it by mistake can cost you everything.
- Channels with more than two parties are very hard to build.
With LN-Symmetry, any newer state can simply override an older one on-chain. A cheater gains nothing and loses only fees. You store only the latest state, honest mistakes aren't punished, and multi-party channels and channel factories become practical. The trade-off is that cheating is no longer punished, and the dispute delays are somewhat longer.
3. "We already have this with pre-signed transactions"
This is mostly true for CTV and APO, and not true for OP_CAT-style designs.
- CTV is close to a pre-signed transaction whose key was provably deleted. Pre-signing already does the same thing, but with three costs: everyone must be present, you can't prove the key is gone, and every outcome must be signed in advance. CTV removes those costs without giving scripts new power, which is why it's described as low risk.
- OP_CAT, and broad introspection opcodes in general, go further. They can enforce rules on amounts and destinations that weren't known in advance, and they can pass a rule on to the next output (recursion). Pre-signing can't do that.
4. Fungibility and censorship
This is the strongest version of the critics' case, so it deserves a careful answer.
- No covenant can be put on coins you already hold. A covenant lives in the script of the address the coins are sent to, and the receiver chooses that address. If someone asks you to accept "covenant-locked" coins, you can refuse, just as you can refuse coins sitting in someone else's multisig.
- Non-recursive covenants (CTV, APO) end after one spend. Once the coin leaves the covenant, it's ordinary bitcoin again. These can't create a permanent class of restricted coins.
- Recursive covenants could. In principle, someone could create coins that can only ever move to whitelisted addresses, forever. That's the scenario Greg Maxwell described in 2013 as "an amusingly bad idea", and it's a fair worry about an unrestricted design like OP_CAT.
- Could a government do this today without covenants? Mostly, yes. It could require 2-of-2 multisig with a state-controlled co-signer that refuses non-compliant payments. The difference is cost and durability: a co-signer must stay online and can be shut down or worked around, while a recursive covenant is enforced by every node forever. That makes it cheaper to impose and harder to escape.
- The Liquid sidechain has had CAT and introspection opcodes since 2021, and nothing like "compliance coins" has appeared there. Real-world pressure comes through custodians and exchanges, which don't need new opcodes to apply it.
Saying money shouldn't carry programmed rules is a values position, not a technical mistake. But Bitcoin already has programmed spending rules: multisig, timelocks and hashlocks. Lightning depends on them. The real question is which new rules to add and whether they can chain forever.
5. Other risks
- Consensus risk: every soft fork adds code that can never be removed, and a bug becomes permanent. Narrow opcodes like CTV have little attack surface; general ones like OP_CAT have much more.
- MEV and mining centralization: very expressive covenants make DeFi-style contracts (pools, bridges, auctions) possible on-chain. That creates value miners can extract by reordering transactions, which favors large, sophisticated miners. This is the most serious argument against general introspection, and it barely applies to CTV.
- Block space: more contracts means more on-chain demand. That's good for the security budget, but it adds fee pressure.
- Governance: the 2017 block-size fight and the 2021 Taproot activation left the community wary. There's a sizable "ossify now" camp that would rather add nothing.
6. Status and outlook (October 2026)
- None has activated on mainnet. CTV, APO, OP_CAT and CSFS all run on the Bitcoin Inquisition test network.
- CTV + CSFS is the front-runner among developers. A widely circulated 2025 letter from application and protocol developers asked Bitcoin Core to review and prioritize the pair.
- An independent CTV activation client with a signaling window running to March 2027 is reported to have drawn almost no miner support. Miners follow Core and rough consensus, not standalone clients.
- OP_CAT's specification is complete, but no activation is planned.
- Blockstream's CEO, Adam Back, recently endorsed a covenant package as a possible "last soft fork".
By 2030? It's plausible but not likely by default. Taproot took about four years from formal proposal to activation. Activation by 2030 would need, roughly by 2027–28: agreement on one minimal bundle, a merged and reviewed Bitcoin Core implementation, and an activation method nobody calls a power grab (Speedy Trial worked for Taproot). The competing CTV and TEMPLATEHASH bundles are currently splitting the attention that would need to come together.
Verdict
A net gain for Bitcoin as money, if it's the narrow version. CTV + CSFS, or the equivalent TEMPLATEHASH bundle, would:
- remove the key-deletion trust from Ark and statechains,
- replace Lightning's penalty model with LN-Symmetry,
- make vaults practical for ordinary savers,
all without recursion and without new possibilities for extracting MEV. Those benefits mainly help people keep custody of their own coins, which is the main defense against the censorship critics are worried about.
General introspection (OP_CAT plus the related opcodes) is where the critics' concerns about recursive restrictions, MEV and attack surface become real. That decision should come later, if at all, after the narrow version has proven itself.
So the critic and the covenant supporter are both partly right. Bitcoin should get the narrow covenants and leave the broad ones until the narrow ones have proven themselves.
---
Sources: BIP 119 (CTV) · BIP 118 (APO) · BIP 347 (OP_CAT) · BIP 348 (CSFS) · Covenant proposals compared (Spark) · The ossification debate (Spark) · AMINA Bank on the 2026 fork landscape · Adam Back on covenants (Crypto Briefing)
