Bitcoin Covenant Proposals Compared: CTV, APO, OP_CAT

Bitcoin Covenant Proposals Overview

A covenant is a script condition that restricts how a Bitcoin UTXO can be spent, not just who can spend it or when. Standard Bitcoin Script verifies authorization (a valid signature) and timing (timelocks), but covenants add a third dimension: constraining the destination, amounts, or structure of the spending transaction itself. The technical term is transaction introspection: the ability for Script to examine properties of the transaction in which it executes.

Multiple covenant proposals have been formalized as BIPs, each with different design philosophies ranging from narrow and purpose-built to general and composable. As of mid-2026, none have been activated on Bitcoin mainnet. The following table summarizes each major proposal.

CTV: OP_CHECKTEMPLATEVERIFY (BIP 119)

CTV takes a 32-byte hash from the stack and verifies that the spending transaction matches a committed template. The hash commits to the transaction version, locktime, scriptSigs hash, number of inputs, sequences hash, number of outputs, outputs hash, and the index of the input being spent. It is non-recursive by design: it commits to a specific, predetermined transaction structure and cannot create perpetually restricted coins.

CTV enables congestion control (batching many payments into a single on-chain transaction that fans out later), simple vaults, non-interactive payment channels, and timeout trees for efficient bulk channel closures. For a deeper look at how these use cases work, see our Bitcoin covenants explainer.

An activation client with formal parameters was released in early 2026, specifying a start time of March 30, 2026, a timeout of March 30, 2027, and a 90% miner signaling threshold (1,815 of 2,016 blocks). As of late May 2026, miner signaling stands at 0%: no blocks have signaled support across any tracked difficulty period. The BIP has gathered endorsements from 66 developers, but the activation attempt faces opposition from those who argue that Speedy Trial is inappropriate for proposals without overwhelming consensus.

A competing proposal, BIP 446 (OP_TEMPLATEHASH), authored by Greg Sanders, Antoine Poinsot, and Steven Roose, entered Draft status in March 2026 as a "fully specified drop-in replacement" for CTV with a cleaner Taproot-native implementation.

APO: SIGHASH_ANYPREVOUT (BIP 118)

APO introduces two new sighash flags for tapscript: SIGHASH_ANYPREVOUT and SIGHASH_ANYPREVOUTANYSCRIPT. When signing with these flags, the signature does not commit to the outpoint of the UTXO being spent. This means the same signature can be reused with any UTXO protected by a similar script and the same public keys.

APO was designed specifically to enable eltoo (now called LN-Symmetry), a more efficient Lightning channel state update mechanism. LN-Symmetry eliminates penalty transactions, making all channel states equally valid. This allows lightweight and nearly free watchtowers and safer channel management.

BIP 118 has been enabled on Bitcoin Inquisition's signet since late 2022 but has seen limited testing activity (approximately 1,000 transactions). APO has been partially superseded in developer attention by the CTV+CSFS combination and by the BIP 446/448 bundle, both of which can also enable LN-Symmetry without changing Bitcoin's signature model.

OP_VAULT (BIP 345)

BIP 345 proposed two new tapscript opcodes, OP_VAULT and OP_VAULT_RECOVER, designed for vault covenants. The mechanism works in conjunction with CTV (BIP 119): a user locks funds into a vault with a Taproot output containing vault scripts. To spend, the user triggers an unvaulting process that enforces a configurable delay period. During the delay, the user or a watchtower can detect unauthorized withdrawal attempts and sweep funds to a pre-specified recovery path.

The security model provides two paths: a "hot" spending path with a mandatory delay, and a "cold" recovery path accessible at any time before finalization. An attacker who compromises the hot key has only the delay period before the owner can claw back funds via the cold key. For more on vault designs, see our Bitcoin custody solutions comparison.

BIP 345 was formally withdrawn in May 2025, superseded by BIP 443 (OP_CHECKCONTRACTVERIFY), authored by Salvatore Ingala. BIP 443 is a more general-purpose opcode that can construct vaults but also enables broader use cases including state-carrying UTXOs.

OP_CAT (BIP 347)

OP_CAT takes the top two elements on the stack and concatenates them. It was part of Bitcoin's original codebase but was disabled in 2010 (Bitcoin 0.3.10) due to denial-of-service concerns: unbounded concatenation could produce exponentially large stack elements. BIP 347 addresses this with a 520-byte stack element size limit.

OP_CAT is not itself a covenant opcode, but combined with Schnorr signature properties it enables covenant emulation through an indirect technique. Using the elliptic curve generator point as a public key, a Schnorr signature effectively equals the transaction's sighash. Individual transaction fields are provided as witness data and concatenated on the stack to reconstruct the sighash, where each field can be verified against predetermined values. Unlike CTV, this approach can enable recursive covenants: coins that remain perpetually restricted. For a detailed analysis of the OP_CAT debate, see our OP_CAT covenant debate article.

The BIP 347 specification reached "Complete" status on March 1, 2026 (the BIP document is finalized, but this does not imply activation consensus). OP_CAT has seen significant testing on Bitcoin Inquisition's signet with approximately 74,000 transactions, far exceeding CTV (16 transactions) and APO (approximately 1,000). Taproot Wizards raised $30 million in a February 2025 Series A specifically to build an ecosystem of applications using OP_CAT.

TXHASH: OP_TXHASH (BIP 346)

TXHASH proposes two opcodes: OP_TXHASH pushes a hash of selected transaction fields onto the stack, and OP_CHECKTXHASHVERIFY verifies a hash against those fields. The key innovation is the TxFieldSelector: a variable-length byte sequence where individual bits specify which transaction fields are included in the hash. This allows granular, selective commitment to specific parts of the transaction rather than the entire template.

TXHASH is a strict generalization of CTV. The default TxFieldSelector mode is semantically identical to CTV without costing additional bytes. But TXHASH also enables capabilities CTV cannot: equality checking of input and output values, in-band fee adjustment without anchor outputs, and custom signature commitment patterns when combined with CSFS (OP_CHECKSIGFROMSTACK, BIP 348).

A reference implementation and test vectors exist, and a Bitcoin Core PR (#29050) is open. The proposal has been somewhat overshadowed by the momentum around CTV+CSFS and by the BIP 446/448 bundle, which Steven Roose himself co-authored.

LNHANCE and the CTV+CSFS Bundle

LNHANCE is a combination proposal by Brandon Black that bundles three opcodes: CTV (BIP 119) for transaction template commitment, CSFS ( OP_CHECKSIGFROMSTACKVERIFY, BIP 348) for verifying signatures against arbitrary stack messages rather than the transaction itself, and OP_INTERNALKEY for copying the Taproot internal key onto the stack.

Together, these opcodes enable LN-Symmetry (cleaner Lightning channel updates without penalties), timeout trees, simplified PTLCs as a replacement for HTLCs, unidirectional non-interactive channels, vaults, and trustless coin pools. CTV+CSFS (without the IKEY component) has emerged as the frontrunner combination among core developers for a potential soft fork.

A competing bundle, BIP 448 (authored by Greg Sanders, Antoine Poinsot, and Steven Roose), entered Draft status in March 2026. It packages OP_TEMPLATEHASH (BIP 446) + CSFS + IKEY into a single proposal titled "Taproot-native (Re)bindable Transactions," offering a cleaner implementation at the cost of lacking BitVM compatibility.

Capability Comparison

The following table compares what each proposal enables across the most discussed covenant use cases.

Impact on Layer 2 Protocols

Covenant activation would meaningfully improve several Layer 2 protocols. The Bitcoin Layer 2 landscape currently includes multiple approaches with different covenant dependencies.

Ark would benefit significantly from covenants. A simple covenant like CTV or APO would reduce the complexity of Ark's round process and make receiving non-interactive. Without covenants, Ark requires pre-signed transaction trees and more user interactivity. Both teams working on Ark implementations have opted to build covenant-less versions deployable on Bitcoin today, planning to upgrade when covenants activate.

The Lightning Network would gain LN-Symmetry (via CTV+CSFS or APO), eliminating penalty transactions and enabling cheaper watchtowers. Timeout trees would allow efficient channel factories, and PTLCs could replace HTLCs for improved privacy.

Spark uses a statechain-based architecture with FROST threshold signatures to transfer UTXO ownership without requiring covenant opcodes. Its design is functional on Bitcoin today, though broader covenant-enabled ecosystem improvements could benefit the protocol indirectly. For a detailed comparison of Layer 2 approaches, see our Layer 2 comparison tool.

Activation Status and Timeline

No covenant proposal has been merged into Bitcoin Core or activated on mainnet. The Bitcoin development community has moved past the binary "covenants yes vs. no" debate of 2022 to 2024. The conversation is now about which primitives to activate and in what combination.

CTV has the most concrete activation parameters: a signaling window that opened March 30, 2026 with a timeout of March 30, 2027. However, with 0% miner signaling as of late May 2026, activation through this attempt appears unlikely unless sentiment shifts substantially.

OP_CAT (BIP 347) has the most developer testing activity on signet (74,000+ transactions) and the most external investment (Taproot Wizards' $30 million Series A), but its ability to enable recursive covenants makes it more contentious than non-recursive alternatives.

The emergence of BIP 446/448 as a competitor to CTV+CSFS in March 2026 adds another variable. Multiple credible proposals competing for the same soft fork slot could delay activation further, as the community must converge on a single path. For historical context on how Bitcoin soft forks have been activated, see our Bitcoin soft fork history reference.

Frequently Asked Questions

What are Bitcoin covenants?

Bitcoin covenants are script conditions that restrict how a UTXO can be spent, not just who can spend it. Standard Bitcoin transactions verify a valid signature and optional timelocks. Covenants add the ability to constrain the destination addresses, output amounts, or transaction structure of the spending transaction. This enables use cases like vaults (enforcing a time delay before funds can move), congestion control (batching many payments into a single transaction), and payment pools (shared UTXOs that multiple parties can exit independently).

Has any Bitcoin covenant proposal been activated?

No. As of mid-2026, no covenant proposal has been activated on Bitcoin mainnet. CTV (BIP 119) has a live activation client with a signaling window that opened March 30, 2026, but miner signaling is at 0%. OP_CAT (BIP 347) has a finalized specification but no activation attempt. All proposals can be tested on Bitcoin Inquisition's signet.

What is the difference between CTV and OP_CAT?

CTV (BIP 119) commits to a fixed transaction template: the spending transaction must exactly match a predetermined structure. It is narrow, non-recursive, and purpose-built for use cases like congestion control and simple vaults. OP_CAT (BIP 347) concatenates stack elements, enabling indirect transaction introspection through Schnorr signature properties. It is more general-purpose and can enable recursive covenants (perpetually restricted coins). CTV is considered lower-risk because its capabilities are strictly bounded, while OP_CAT's broader expressiveness introduces both more flexibility and more uncertainty about long-term effects on Bitcoin.

Why do Lightning developers want covenants?

Covenants would enable LN-Symmetry (formerly eltoo), a channel update mechanism that eliminates penalty transactions and makes all channel states equally valid. This simplifies watchtower design, reduces on-chain footprint during force closes, and makes channel management safer. Covenants also enable timeout trees for efficient channel factories and PTLCs for improved payment privacy. The CTV+CSFS combination or APO (BIP 118) alone can enable LN-Symmetry.

What is LNHANCE?

LNHANCE is a combination proposal by Brandon Black that bundles CTV (BIP 119), CSFS (BIP 348), and OP_INTERNALKEY into a single soft fork. Together these opcodes enable LN-Symmetry, timeout trees, PTLCs, vaults, and non-interactive channels. CTV+CSFS (the first two components) has emerged as the most popular combination among core developers, though a competing bundle (BIP 446/448) offers a similar feature set with a different implementation approach.

Are recursive covenants dangerous for Bitcoin?

This is actively debated. Recursive covenants (enabled by OP_CAT but not by CTV or APO) allow coins to be perpetually restricted: a spending condition that persists across every future transaction. Supporters argue this enables powerful constructs like on-chain state machines and complex smart contracts. Critics worry about unintended consequences: coins that become permanently encumbered, increased chain analysis surface, or complex interactions that are difficult to reason about. Non-recursive proposals like CTV avoid this debate entirely by committing only to immediate spending conditions.

Does Ark Protocol need covenants?

Ark works without covenants today but would be significantly improved by them. A simple covenant like CTV or APO would reduce the complexity of Ark's round process and make receiving non-interactive. Without covenants, Ark requires pre-signed transaction trees and more user coordination. Both major Ark implementations have launched covenant-less versions on mainnet, planning to upgrade when covenants are activated.

This tool is for informational purposes only and does not constitute financial advice. BIP statuses and activation data reflect publicly available information as of late May 2026. The Bitcoin development process is ongoing: proposal statuses, miner signaling, and community consensus can change. Always verify current information on bips.dev and Bitcoin Optech before making technical decisions.