OP_CTV: Bitcoin's Most Debated Covenant Proposal and What It Enables

Bitcoin Script can enforce who spends a coin, but it cannot enforce how that coin gets spent afterward. Once funds leave your control, you have no say over the shape of the next transaction. OP_CHECKTEMPLATEVERIFY, defined in BIP 119, would change that. It lets a transaction output commit to the exact template of the transaction that spends it: the number of outputs, their values, their locking scripts, and more. This single primitive unlocks covenants on Bitcoin without recursive computation, and it has been at the center of one of the most heated technical debates in Bitcoin's history.

What Problem Does CTV Solve?

Today, Bitcoin Script answers one question: who is authorized to spend this output? It can require a signature, a hash preimage, a timelock, or combinations of these. But it cannot answer: what must the spending transaction look like? This limitation is fundamental to how Bitcoin Script works. Opcodes operate on stack data, not on transaction fields. There is no way to inspect the outputs of the spending transaction and enforce constraints on them.

This gap matters because many useful constructions require restricting future spending paths. Vaults that enforce a time-delayed withdrawal. Payment pools where multiple users share a UTXO with pre-agreed exit paths. Congestion control trees that batch hundreds of payouts into a single on-chain transaction. All of these need some form of covenant: a rule that constrains not just who can spend, but what form the spending transaction must take.

How OP_CTV Works

CTV replaces the existing no-op opcode OP_NOP4 (0xb3) with new functionality via a soft fork. When executed, it pops a 32-byte hash from the stack and compares it to a freshly computed hash of the spending transaction's template. If the hashes match, the script succeeds. If they don't, the transaction is invalid.

The key insight is what goes into that hash. CTV defines a "StandardTemplateHash" that commits to eight specific fields of the spending transaction.

The Template Hash Fields

The StandardTemplateHash is a SHA-256 digest of the following fields, serialized in order:

1. Transaction version (4 bytes)
2. Locktime (4 bytes)
3. ScriptSigs hash (SHA-256 of all concatenated scriptSigs, if any non-empty scriptSigs exist)
4. Input count (4 bytes)
5. Sequences hash (SHA-256 of all input sequence numbers)
6. Output count (4 bytes)
7. Outputs hash (SHA-256 of all serialized outputs, committing to both values and locking scripts)
8. Input index (4 bytes): which input in the spending transaction is being validated

Why input index matters: Including the input index prevents a subtle attack. Without it, if two inputs in the same transaction both use CTV with different templates, an attacker could swap which input satisfies which template. The input index pins each CTV check to a specific position in the transaction, preventing this "half-spend" problem.

Notice what CTV does not commit to: the input txids and vouts (the specific UTXOs being spent). This is deliberate. It means you can create a CTV-locked output without knowing exactly which UTXO will fund the spending transaction, as long as the spending transaction matches the committed template in every other respect.

Non-Recursive by Design

CTV covenants are non-recursive. A CTV output can commit to a spending transaction whose outputs themselves contain CTV conditions, but the chain of commitments is finite and fully determined at creation time. You cannot create an output that says "all future transactions spending these coins must include this rule forever." The spending tree is a directed acyclic graph with a known, bounded depth. This is a core design choice that limits CTV's power but also limits its risk.

Congestion Control: A Step-by-Step Example

The most intuitive CTV use case is congestion control, sometimes called "payment tree" or "batched payout." Imagine an exchange needs to process 1,000 withdrawals during a period of high fee pressure. Without CTV, the exchange has two options: pay high fees now for 1,000 individual transactions, or make users wait until fees drop.

How It Works With CTV

1. The exchange constructs a tree of pre-computed transactions. At the root is a single transaction with one output locked by CTV.
2. That CTV output commits to a transaction template with, say, 10 outputs. Each of those 10 outputs either pays a recipient directly or is itself a CTV-locked output committing to another batch of 10.
3. The exchange broadcasts only the root transaction on-chain, paying a single fee for one transaction.
4. Each recipient can expand their branch of the tree whenever they choose, paying fees only at that point. If fees are high, they can wait. If fees are low, they expand immediately.
5. Because CTV commits to the exact outputs, no one can alter the payout amounts or redirect funds. The exchange cannot change its mind after broadcasting the root.

The result: 1,000 payments committed with a single on-chain transaction. Recipients claim funds at their own pace, paying fees when conditions suit them. The exchange's obligation is cryptographically locked the moment the root transaction confirms.

Efficiency gain: In a binary tree structure, a congestion control tree for 1,024 recipients requires only one on-chain transaction to commit. Each recipient then needs at most 10 on-chain transactions (log₂ 1024) to fully expand their path, but can defer these until fees are acceptable.

Vaults Without Key Management Complexity

Vaults are the second major use case. A vault is a spending policy that enforces a two-step withdrawal: first, announce the intent to withdraw (the "unvaulting" transaction), then wait for a timelock to expire before the funds can actually move. During the waiting period, the owner can trigger a recovery path that sends funds to a secure cold storage address.

Today, vaults are possible using pre-signed transactions, but they require careful key management. The keys used to pre-sign the vault transactions must be securely stored (or deleted) for the lifetime of the vault. If those keys are compromised, the vault's security is broken.

With CTV, the vault logic is encoded directly in the Script. The unvaulting transaction's template is committed to at creation time, and no private keys need to be preserved. The covenant enforces the spending path, not a set of pre-signed transactions. This makes vaults operationally simpler and removes an entire class of key management risk.

Payment Pools and Channel Factories

CTV also enables more efficient shared UTXO constructions. In a payment pool, multiple users share a single on-chain UTXO, with pre-defined exit paths that let any participant withdraw their funds unilaterally. CTV can commit to the tree of exit transactions at pool creation time, ensuring that every participant has a guaranteed withdrawal path without requiring ongoing cooperation from other pool members.

Channel factories extend this concept to Lightning channels. Instead of each channel requiring its own on-chain funding transaction, a factory creates multiple channels from a single UTXO. CTV can pre-commit the factory's expansion into individual channels, reducing the on-chain footprint and setup cost for Layer 2 protocols.

Discreet Log Contract Optimization

Discreet Log Contracts (DLCs) benefit from CTV as well. A standard DLC with many possible outcomes requires both parties to pre-sign thousands of commitment transactions, one per outcome. With CTV, the refund transaction's template can be committed directly in the funding output's script, reducing the number of signing rounds from two to one and simplifying the protocol's interactive setup.

The Political Controversy

CTV's technical merits have been debated for years, but the real controversy has always been about process. BIP 119 was proposed by Jeremy Rubin in January 2020. By early 2022, Rubin believed the proposal was mature enough for activation and announced a Speedy Trial activation with a signaling window from May to August 2022, requiring 90% miner support.

The 2022 Speedy Trial Attempt

The announcement triggered immediate backlash. Critics argued that Speedy Trial was designed as a mechanism to formalize existing consensus, not to discover whether consensus exists. When Taproot used Speedy Trial in 2021, the proposal had years of review and broad developer support behind it. CTV did not.

Adam Back, CEO of Blockstream, warned that attempting to activate a proposal without clear technical consensus risked creating the kind of divisive drama Bitcoin experienced during the block size wars. Matt Corallo, a longtime Bitcoin Core contributor, argued that the community should evaluate all covenant proposals together before committing to any single one, stating that Bitcoin should not add features "just to find out whether we can."

Within weeks, Rubin withdrew the activation attempt. The proposal entered a period of relative dormancy.

Too Narrow vs. Minimal Viable

The core technical disagreement centers on CTV's deliberate minimalism. Rubin's design philosophy was to create the smallest possible covenant primitive that would be safe to deploy: a "minimal viable covenant." The reasoning was pragmatic: a narrower proposal has a smaller attack surface, is easier to review, and is more likely to achieve consensus.

Critics counter that CTV is too narrow precisely because its minimalism means Bitcoin may need additional soft forks to unlock the full range of covenant applications. Each soft fork requires enormous consensus-building effort. If CTV solves only 70-80% of what developers need, the argument goes, Bitcoin would be better served by a more comprehensive proposal that solves 95% in a single activation. Others worry that activating CTV first could reduce motivation to pursue more powerful alternatives.

CTV Compared to Other Covenant Proposals

CTV is not the only covenant proposal under discussion. Several alternatives offer different tradeoffs between power, complexity, and risk. Understanding the landscape requires comparing them directly.

OP_CAT: The Maximalist Alternative

OP_CAT (BIP 347) takes the opposite approach from CTV. Rather than committing to a full transaction template, OP_CAT re-enables stack element concatenation in Tapscript, which was disabled early in Bitcoin's history. On its own, CAT just joins two byte strings. But combined with Schnorr signature verification and careful scripting, it enables transaction introspection: scripts can reconstruct and verify parts of the spending transaction, effectively enabling recursive covenants.

The power of OP_CAT is also its risk. Recursive covenants could theoretically enable address whitelisting or blacklisting enforced at the protocol level, which some developers view as a fundamental threat to Bitcoin's fungibility. CTV's non-recursive design avoids this concern entirely.

OP_VAULT: Single-Purpose Precision

OP_VAULT (BIP 345), proposed by James O'Beirne, is even narrower than CTV. It provides exactly one feature: secure vault operations with a timelock-and-recovery spending policy. It doesn't enable congestion control, payment pools, or channel factories. The argument for OP_VAULT is that vaults are the highest-value covenant use case and deserve a purpose-built opcode. The argument against is that spending a soft fork on a single use case is wasteful when CTV covers vaults and more.

TXHASH and CSFS: The Modular Approach

TXHASH combined with OP_CHECKSIGFROMSTACK (CSFS) offers a more flexible alternative. TXHASH would let scripts select exactly which transaction fields to hash (rather than CTV's all-or-nothing template), while CSFS enables verifying a signature against arbitrary data on the stack. Together they can replicate what both CTV and SIGHASH_ANYPREVOUT do, with finer granularity. The tradeoff is additional complexity and a larger review surface.

Capability Comparison Across Use Cases

Different covenant proposals cover different use cases. This table shows which proposals enable which applications.

CTV covers the most commonly cited use cases but falls short on applications that require flexible transaction introspection or recursive spending conditions. OP_CAT and TXHASH + CSFS are more capable but carry higher review burden and, in the case of OP_CAT, more open questions about unintended consequences.

LNHANCE: A Pragmatic Bundle

A more recent development is LNHANCE, a proposal to bundle CTV (BIP 119) with OP_CHECKSIGFROMSTACK (CSFS) and OP_INTERNALKEY into a single soft fork. Rather than framing the activation around abstract covenant capabilities, LNHANCE targets concrete Lightning Network improvements:

• LN-Symmetry: a cleaner channel state mechanism that eliminates toxic justice transactions
• Timeout trees for efficient bulk channel closures
• Simplified PTLC scripts
• Unidirectional non-interactive channels
• Improved vault constructions
• Trustless coin pools

The strategic logic is that Lightning improvements have broader community support than abstract covenant debates. By packaging CTV with CSFS and framing the activation around scaling benefits, LNHANCE may achieve the consensus that standalone CTV could not.

Current Status and Activation Outlook

As of mid-2026, CTV has not been activated. The proposal remains in draft status, though it has seen renewed interest after years of dormancy following the 2022 Speedy Trial withdrawal.

Concrete activation parameters have been circulated: a proposed start time of March 30, 2026, a timeout of March 30, 2027, a minimum activation height in May 2027, and a 90% miner signaling threshold over 2,016-block periods. These parameters represent a framework for discussion rather than achieved consensus, but they mark a significant shift from the post-2022 period where CTV activation seemed indefinitely stalled.

The broader covenant conversation has also evolved. Bitcoin Core developers appear to be converging on a smaller set of proposals, with CTV and CSFS (in the LNHANCE bundle) and OP_CAT (BIP 347) receiving the most serious attention. The question is no longer whether Bitcoin needs covenants but which covenant primitive to activate first.

The activation problem: Bitcoin's consensus process is deliberately slow. Taproot took roughly four years from initial proposal to activation. SegWit took even longer and required a user-activated soft fork threat to resolve a miner signaling standoff. Any covenant proposal faces this same gauntlet. Technical readiness is necessary but not sufficient: political consensus among developers, miners, and economic nodes must also align.

What CTV Would Mean for Layer 2 Protocols

CTV's most significant long-term impact would be on Layer 2 scaling. Congestion control trees would let Layer 2 operators batch user entries and exits far more efficiently than current on-chain constructions allow. Channel factories could create dozens of Lightning channels from a single UTXO. Payment pools would let multiple users share on-chain footprint while retaining unilateral exit guarantees.

For protocols like Spark, which already enable instant off-chain Bitcoin transfers, CTV would not change the core protocol design. Spark's statechain-based architecture operates independently of covenant opcodes. However, CTV would benefit the broader Bitcoin L2 ecosystem by reducing on-chain costs for entry and exit transactions, improving the efficiency of shared UTXO constructions, and enabling new designs for payment pools that complement existing Layer 2 approaches.

The channel factory use case is particularly relevant. Today, opening a Lightning channel requires a dedicated on-chain transaction. With CTV, a factory could pre-commit the expansion of a single UTXO into many channels, amortizing on-chain costs across all participants. Combined with splicing, this could dramatically reduce the cost of maintaining Lightning infrastructure.

Technical Risks and Open Questions

Template Rigidity

CTV commits to an exact transaction template. If any detail of the spending transaction changes (a different fee, an additional output, a modified value), the template hash no longer matches and the spend fails. This rigidity is what makes CTV safe but also makes it inflexible. Fee-bumping a CTV-locked transaction requires pre-planning: either build multiple templates at different fee levels, use child-pays-for-parent on the outputs, or incorporate an anchor output for fee adjustment.

Interaction With Future Soft Forks

If CTV is activated and a future soft fork changes transaction serialization or adds new fields, existing CTV templates could break. BIP 119 addresses this partially by using the transaction version field in the template hash, but the interaction between covenant opcodes and future consensus changes remains an area of active research.

Mempool and Relay Considerations

CTV transactions create chains of dependent, pre-committed transactions. Bitcoin's current mempool and relay policies have limits on transaction chains (ancestor and descendant limits). Deep CTV trees could hit these limits, requiring policy changes or creative transaction structuring to work in practice. The ongoing cluster mempool work in Bitcoin Core may alleviate some of these constraints.

The Road Ahead

OP_CTV represents a design philosophy as much as a technical proposal: the idea that Bitcoin should evolve through small, safe, well-understood changes rather than ambitious leaps. Whether that philosophy prevails over the broader-scope approach of OP_CAT or the modular flexibility of TXHASH + CSFS remains to be seen. What is clear is that the covenant conversation has moved past "whether" to "which and when."

For developers building on Bitcoin today, the practical advice is to design systems that work without covenants but can benefit from them. Understanding the covenant landscape and the tradeoffs between proposals is essential for anyone building infrastructure that will need to adapt when activation eventually happens.

For a deeper look at Bitcoin's programmability constraints and how proposals like CTV fit into the broader picture, see our research on Bitcoin Script programmability and the OP_CAT covenant debate. Developers interested in building on Bitcoin Layer 2 protocols today can explore the Spark SDK documentation for self-custodial Bitcoin and stablecoin integration.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.