Bitcoin covenant proposals compared: CTV, OP_CAT, APO, CSFS and more

A covenant is a spending condition that limits not just who can spend a coin, but how it can be spent next: where it may go, in what kind of transaction, or under which future conditions. Bitcoin Script can't express that in general today. A family of proposals would add it in different ways, from narrow templates like CTV (BIP 119) to general building blocks like OP_CAT (BIP 347). This guide explains what each one proposes, what it is meant for and the main arguments around it. It doesn't predict which, if any, will activate.

Updated 2026-10-20 · 8 min read

What is a Bitcoin covenant?

Today a Bitcoin script can check signatures, hash preimages and timelocks. It cannot look at the transaction that spends it and say "the money must go to this address" or "the next output must carry the same rules". A covenant is any mechanism that adds that kind of restriction on the spending transaction.

People emulate covenants now with pre-signed transactions: create the transactions in advance, then delete the key so no other spend is possible. BIP 345 lists the drawbacks of that approach for vaults: keys must be generated and securely deleted, amounts and destinations are fixed in advance, reusing an address loses coins, and the pre-signed transactions must be stored forever or the money is lost.

Three terms come up constantly:

• Template covenants fix the next transaction, or most of it, in advance.
• Introspection lets a script read parts of the spending transaction and decide for itself.
• Recursive covenants can require each new output to carry the same, or updated, rules, so a restriction can continue indefinitely.

What covenants could be used for

The proposals cite a common set of applications:

• Vaults. Withdrawals must wait out a delay, during which the owner can send the coins to a pre-chosen recovery path if a key was stolen (BIP 345).
• Congestion control and batching. One small output commits to a tree of many future payments that can be expanded later, when fees are lower (BIP 119).
• Channel factories and shared UTXOs. Many users share one on-chain output while each keeps control of their balance: batched channel opens, Ark, CoinPools (BIP 119, BIP 443).
• LN-Symmetry ("eltoo"). A simpler Lightning channel design where any later state can replace an earlier one (BIP 118, BIP 348).
• Discreet Log Contracts and other second layers. Fewer signatures to exchange and store (BIP 446).
• Delegation and oracles. Spending with a signature over data other than the transaction (BIP 348).

The proposals, one by one

BIP 119: OP_CHECKTEMPLATEVERIFY (CTV)

BIP 119 by Jeremy Rubin redefines OP_NOP4 (0xb3). Given a 32-byte hash, it fails unless the spending transaction matches it. The hash covers the version, locktime, scriptSigs, number of inputs, sequences, number of outputs, all outputs, and the index of the input being spent. Because it upgrades a NOP, it works in legacy script, SegWit v0 and Tapscript.

CTV commits to one exact next transaction, so the design is easy to analyze. On its own it can only commit to a precomputed sequence of transactions, which supporters describe as non-recursive. The BIP flags one hazard: an address with a CTV template expects an exact amount, so sending less freezes the coins and sending more pays the excess as fees.

BIP 118: SIGHASH_ANYPREVOUT (APO)

BIP 118 by Christian Decker and Anthony Towns adds a new public key type in Tapscript whose signatures can leave out the coin being spent (SIGHASH_ANYPREVOUT, 0x40) and optionally the script too (SIGHASH_ANYPREVOUTANYSCRIPT, 0xc0). A signed transaction can then be attached to any output with a compatible script: "dynamic rebinding". That is the original basis for LN-Symmetry. The BIP's security section warns that such signatures can be replayed on other outputs with the same key, so keys must not be reused carelessly. APO is not designed as a covenant, but the ANYPREVOUTANYSCRIPT mode can emulate CTV-like templates.

BIP 347: OP_CAT

BIP 347 by Ethan Heilman and Armin Sabouri brings back OP_CAT, which joins two stack items, as Tapscript opcode OP_SUCCESS126 (0x7e, the original value). OP_CAT was disabled in 2010 along with 15 other opcodes; the BIP notes the memory concern that likely motivated this is bounded today by Tapscript's 520-byte element limit, which also caps OP_CAT's output. Listed uses include tree signatures, Lamport signatures, vaults, emulating CHECKSIGFROMSTACK, and BitVM improvements. OP_CAT is a general tool rather than a covenant opcode; combined with Schnorr signature tricks it can build covenants, including recursive ones, which is exactly why it draws both support and caution.

BIP 348: OP_CHECKSIGFROMSTACK (CSFS)

BIP 348 by Brandon Black and Jeremy Rubin redefines OP_SUCCESS204 (0xcc) to verify a BIP 340 signature over any message on the stack, not just the spending transaction. Alone it enables delegation and oracle-signed conditions. Combined with CTV, the BIP shows OP_CHECKTEMPLATEVERIFY <pubkey> OP_CHECKSIGFROMSTACK doing the job of an APO signature for LN-Symmetry, at 8 vbytes more.

BIP 349: OP_INTERNALKEY and BIP 442: OP_PAIRCOMMIT

Two small helpers. BIP 349 (Brandon Black, Jeremy Rubin) makes OP_SUCCESS203 (0xcb) push the Taproot internal key, saving 8 vbytes when a script needs it. BIP 442 (moonsettler, Brandon Black) makes OP_SUCCESS205 (0xcd) hash two stack items, with their lengths, into one commitment. The BIP presents it as a safer alternative to OP_CAT for commitments, since naive concatenation can be ambiguous (0x0102 || 0x03 equals 0x01 || 0x0203).

LNHANCE is the name for the bundle CTV + CSFS + INTERNALKEY + PAIRCOMMIT, which BIP 348 calls "the most efficient and direct way currently designed to implement Lightning Symmetry".

BIP 346: OP_TXHASH

BIP 346 by Steven Roose and Brandon Black redefines OP_SUCCESS189 (0xbd) to push a hash of whichever transaction fields a "TxFieldSelector" picks. With a CSFS-style opcode it can reproduce every existing sighash mode, the APO modes and many new combinations. It is general-purpose introspection, more flexible and more complex than CTV.

BIP 345: OP_VAULT and BIP 443: OP_CHECKCONTRACTVERIFY

BIP 345 by James O'Beirne and Greg Sanders proposed two specialized opcodes, OP_VAULT and OP_VAULT_RECOVER (OP_SUCCESS187 and OP_SUCCESS188), used with CTV for vaults with batched, partial withdrawals. Its header lists BIP 443 as its replacement.

BIP 443 by Salvatore Ingala proposes OP_CHECKCONTRACTVERIFY (OP_CCV) on OP_SUCCESS187 (0xbb). It lets an output carry committed data inside its Taproot key, and lets a script check the internal key, script tree and data of inputs or outputs, with amount rules ("default", "deduct", "ignore"). With a vector commitment opcode, the BIP says this can build "arbitrary state machines", including the recursive covenants a sidechain or rollup would need. Fees have to come from outside, for example through an anchor output.

BIP 446: OP_TEMPLATEHASH and BIP 448

BIP 446 by Gregory Sanders, Antoine Poinsot and Steven Roose makes OP_SUCCESS206 (0xce) push a hash of the spending transaction, reusing the precomputed parts of the BIP 341 signature hash. The authors say it was inspired by CTV but differs on purpose: Tapscript only, no commitment to scriptSigs, and it pushes the hash instead of only checking it, which makes it cheaper to combine with CSFS. BIP 448 by the same authors proposes deploying TEMPLATEHASH, CSFS and INTERNALKEY together as "Taproot-native (Re)bindable Transactions" and acknowledges its similarity to LNHANCE.

BIP 440 and BIP 441: varops budget and restored script

The broadest approach comes from Rusty Russell and Julian Moik. BIP 440 defines a "varops budget": each transaction gets its weight times 10,000 units, and opcodes spend budget according to the size of the data they touch, generalizing Tapscript's sigops budget. BIP 441 uses it to define a new tapleaf version, 0xc2, that re-enables the opcodes disabled in 2010 (OP_CAT included), raises the stack element limit from 520 bytes to 4,000,000, and allows arbitrary-length numbers. Related: BIP 449 by Jeremy Rubin proposes OP_TWEAKADD for Taproot-style key tweaks inside script.

Comparison table

Most proposals use Tapscript's OP_SUCCESSx upgrade hooks from BIP 342, so they would not change legacy or SegWit v0 scripts and would be soft forks. Two head-to-head comparisons go further: BIP 118 vs BIP 119 and BIP 119 vs BIP 347.

Arguments for and against

These debates are open, and reasonable people land in different places.

Narrow versus general. Narrow opcodes (CTV, TEMPLATEHASH, OP_VAULT) are easier to review, and their possible uses are easier to predict. Critics say they may not cover future needs, so more soft forks would follow, and that specialized opcodes risk becoming redundant (BIP 119 itself discusses this). General tools (OP_CAT, TXHASH, BIP 441) could serve many uses with one upgrade; critics say their consequences are harder to foresee and review.

Recursion. Recursive covenants could let restrictions follow coins through every future transaction. Some worry about scenarios like coins that may only move to approved addresses. Others answer that recipients can refuse coins with conditions they don't accept, and that similar control is already possible with multisig custody.

MEV and mining incentives. Some developers worry that very expressive covenants could enable on-chain protocols where whoever orders transactions can extract value, which might favor large miners. Others consider this speculative or limited for Bitcoin.

Validation cost. New opcodes must not make blocks slow to verify. Proposals handle this with size limits (OP_CAT's 520 bytes), caching (CTV), or an explicit cost model (BIP 440).

Demand and evidence. Supporters point to working prototypes for vaults, LN-Symmetry and shared-UTXO schemes. Skeptics ask for clearer evidence of demand before changing consensus; BIP 448's rationale, for instance, favors a minimal set because broader capabilities "have not been demonstrated to enable new important use cases".

How proposals like these could be activated is covered in the soft forks guide; all of them are listed on the smart contracts topic page.