OP_CAT vs OP_CTV: Bitcoin Covenant Proposals Compared

OP_CAT vs OP_CTV Overview

OP_CAT (BIP-347) and OP_CTV (BIP-119) are the two most discussed covenant proposals for Bitcoin. Both would be activated as soft forks, and both aim to expand Bitcoin's programmability beyond simple key-based spending conditions. But they differ fundamentally in scope, risk profile, and what they enable.

OP_CAT is a general-purpose primitive that concatenates two values on the script stack. Combined with existing opcodes, it enables arbitrary computation in tapscript, including recursive covenants and on-chain proof verification. OP_CTV is a purpose-built opcode that commits a UTXO to a specific, predetermined transaction template: compact, narrow, and deliberately non-recursive.

The following table summarizes the key differences. For a broader view of all covenant proposals including OP_VAULT, OP_TXHASH, and LNHANCE, see the full covenant proposals comparison.

How OP_CAT Works

OP_CAT pops the top two values off the script stack, concatenates them, and pushes the result back. The concatenated output cannot exceed 520 bytes (the tapscript stack element size limit). If it does, the script fails immediately.

OP_CAT was part of Bitcoin's original scripting system. Satoshi Nakamoto disabled it in 2010 (around Bitcoin Core version 0.3.8) because combining it with OP_DUP could cause exponential growth in stack element sizes, enabling denial-of-service attacks. BIP-347 re-proposes OP_CAT with the 520-byte cap and restricts it to tapscript only, mitigating the original attack vector.

On its own, OP_CAT simply joins two byte strings. Its power comes from composition: combined with SHA256, EQUAL, and other existing opcodes, OP_CAT can reconstruct and verify transaction data within script. This enables covenants, on-chain STARK proof verification, and token protocols. StarkWare verified the first STARK proof on Bitcoin signet using OP_CAT in July 2024 and created a $1 million research fund dedicated to OP_CAT applications.

How OP_CTV Works

OP_CHECKTEMPLATEVERIFY (CTV) adds a single opcode that commits a UTXO to being spent into a specific, predetermined transaction. The commitment hash covers the transaction version, locktime, input count, sequence numbers, output count, outputs, and the spending input's position. If the spending transaction does not match the committed template exactly, the script fails.

CTV is deliberately non-recursive. A CTV-locked output commits to a future transaction, but that transaction cannot itself create perpetual forward restrictions using CTV alone. Advocates consider this constraint a key safety property: it limits the opcode's blast radius and makes its behavior easier to reason about formally.

Jeremy Rubin first proposed CTV in January 2020. A Speedy Trial activation attempt in April 2022 was withdrawn within weeks after prominent developers including Adam Back and Luke Dashjr argued insufficient technical consensus existed. Rubin subsequently stepped back from active Bitcoin Core development. In February 2026, a new activation client was published with BIP 9 deployment parameters: signaling bit 5, a window from March 30, 2026 through March 30, 2027, and a 90% miner threshold. As of mid-2026, no blocks have signaled support.

Capabilities Comparison

The fundamental tradeoff between OP_CAT and OP_CTV is expressiveness versus safety. The following table compares what each opcode enables across specific use cases that matter for Bitcoin's programmability roadmap.

OP_CAT can emulate CTV's functionality when combined with other opcodes, but the resulting scripts are significantly longer and more complex. CTV achieves its supported patterns in a single opcode, making it far more compact for template-based covenants. However, CTV cannot replicate OP_CAT's general computation capabilities, particularly recursive covenants and proof verification.

Security Risk Profile

OP_CTV is widely considered the most conservative covenant proposal. Its single-purpose design limits unintended consequences: a CTV output can only enforce that its UTXO is spent into a specific transaction template. The non-recursive property means CTV cannot create perpetual restrictions on coins, which eliminates an entire category of risks around coins becoming permanently encumbered.

OP_CAT's risk profile is more complex. The opcode itself is trivial: concatenate two byte strings with a 520-byte cap. But its implications are far-reaching. When combined with existing opcodes, OP_CAT enables recursive covenants, meaning coins could be permanently restricted in ways that are difficult to model and audit. Critics argue this introduces unknown unknowns into Bitcoin's security model. Supporters counter that the 520-byte limit and tapscript restriction adequately constrain the attack surface.

For a deeper exploration of how covenants interact with Bitcoin's security model, see our research on the OP_CAT covenant debate and the covenant activation path forward.

Impact on Bitcoin Layer 2s

Both proposals would improve the trust assumptions and efficiency of Bitcoin's layer 2 protocols, but in different ways.

Lightning Network improvements:

• CTV combined with CSFS enables LN-Symmetry (formerly eltoo), eliminating penalty transactions and making watchtower operation cheaper
• CTV enables efficient batch channel opens, reducing on-chain costs for Lightning service providers
• OP_CAT can achieve similar results but requires more complex script constructions

Ark protocol:

• Ark launched on mainnet without covenants, using heavier trust assumptions as a workaround
• Either OP_CAT or CTV would enable non-interactive vTXO issuance, in-round payments with full security, and automatic vTXO reissuance

Rollups and advanced L2s:

• Trustless Bitcoin rollups require recursive covenants for autonomous state management, making OP_CAT the primary enabler
• CTV alone cannot support rollup verification because it lacks the ability to enforce recursive state transitions
• StarkWare's work on Bitcoin scaling depends specifically on OP_CAT

For Spark and similar off-chain protocols, covenants would reduce trust assumptions around state management and enable more efficient coordination between participants. Any covenant activation would benefit the broader Bitcoin L2 ecosystem, though the specific gains depend on which opcode activates. For a comparison of how different L2 approaches handle these tradeoffs today, see the Bitcoin L2 trust model comparison.

Developer and Community Support

Community support for each proposal is fragmented, with no clear consensus winner.

OP_CAT support:

• Andrew Poelstra (Blockstream Director of Research) has publicly endorsed OP_CAT as the strongest path to recursive covenants
• StarkWare created a $1 million research fund for OP_CAT development
• Taproot Wizards raised $30 million in a February 2025 Series A to build an OP_CAT application ecosystem
• ~74,000 transactions on Bitcoin Inquisition signet since May 2024, far exceeding other proposals

OP_CTV support:

• A public letter signed by 66 developers urged Bitcoin Core contributors to prioritize CTV+CSFS review
• Lightning developers favor CTV+CSFS as the path to LN-Symmetry
• A concrete activation client with BIP 9 parameters was published in February 2026
• The 2022 Speedy Trial withdrawal and 0% miner signaling in 2026 indicate weak activation momentum

A growing faction supports bundling CTV with CSFS (OP_CHECKSIGFROMSTACK) as a pragmatic middle ground. The LNHANCE proposal by Brandon Black goes further, packaging CTV, CSFS, OP_INTERNALKEY, and OP_PAIRCOMMIT into a single activation bundle targeting Lightning improvements. In principle, OP_CAT and CTV are not mutually exclusive: both could coexist on Bitcoin. However, competing proposals fighting for the same soft fork slot push any activation further into the future.

Activation Timeline and Outlook

No consensus-layer soft fork has activated on Bitcoin since Taproot in November 2021. The bar for changing Bitcoin's consensus rules has never been higher.

CTV has the most concrete activation timeline: a BIP 9 signaling window running from March 30, 2026 through March 30, 2027, with a 90% miner threshold and earliest possible activation around May 2027 (block 1,001,952). However, this activation client is separate from Bitcoin Core, and 0% miner signaling after months suggests this particular attempt is unlikely to succeed without a significant shift in sentiment.

OP_CAT has no activation parameters, no activation client, and no proposed timeline. Despite broad testing on signet and significant industry investment, the path from BIP finalization to mainnet activation remains undefined.

The ossification debate adds another dimension: some prominent voices argue that protocol stability is Bitcoin's most important property and that any soft fork introduces unacceptable risk. Others argue that without new capabilities, Bitcoin L2s will remain constrained by suboptimal trust models. This tension is unlikely to resolve quickly, making a realistic covenant activation date difficult to predict.

Frequently Asked Questions

What is the difference between OP_CAT and OP_CTV?

OP_CAT (BIP-347) is a general-purpose opcode that concatenates two stack values, enabling arbitrary computation in tapscript when combined with other opcodes. OP_CTV (BIP-119) is a purpose-built opcode that commits a UTXO to a specific predetermined transaction template. OP_CAT is more expressive and enables recursive covenants, rollups, and proof verification. OP_CTV is narrower, safer, and optimized for use cases like congestion control and vaults.

Can OP_CAT and OP_CTV both be activated on Bitcoin?

Yes. The two opcodes are not mutually exclusive and could coexist on Bitcoin. Some developers advocate a phased approach: activating CTV+CSFS first for immediate Lightning and vault improvements, then OP_CAT later for broader programmability. However, competing proposals typically slow the activation process because community attention and review bandwidth are finite.

Why was OP_CAT removed from Bitcoin originally?

Satoshi Nakamoto disabled OP_CAT in 2010 (around Bitcoin Core version 0.3.8) because combining it with OP_DUP could cause exponential growth in stack element sizes, enabling denial-of-service attacks against nodes. BIP-347 reintroduces OP_CAT with a 520-byte output cap and restricts it to tapscript only, which prevents the original attack vector.

What are Bitcoin covenants and why do they matter?

Covenants are restrictions on how Bitcoin can be spent beyond simple key-based authorization. They enable conditions like "this coin must pass through a time-lock before final settlement" or "this coin can only be sent to these specific addresses." Covenants unlock vaults for theft recovery, payment pools for UTXO sharing, congestion control for fee optimization, and better trust models for layer 2 protocols like Lightning, Ark, and Spark.

Which covenant proposal is most likely to activate first?

As of mid-2026, CTV has the most concrete activation parameters (BIP 9 signaling window through March 2027), but 0% miner signaling suggests this specific attempt is unlikely to succeed. OP_CAT has no activation client at all. CTV+CSFS has emerged as a favored bundle among some core developers. No covenant soft fork has achieved the community consensus required for activation, and no consensus-layer change has been made to Bitcoin since Taproot in November 2021.

How would covenants affect Bitcoin layer 2s like Spark?

Covenants would reduce trust assumptions in off-chain protocols by enabling on-chain enforcement of spending conditions. For Lightning, CTV+CSFS enables LN-Symmetry, eliminating penalty transactions. For Ark, covenants enable non-interactive vTXO issuance. For rollup-based L2s, OP_CAT enables trustless state verification. For Spark and similar protocols, any covenant activation would improve the efficiency and security of off-chain state management.

What is the LNHANCE proposal?

LNHANCE is a soft fork bundle proposed by Brandon Black that packages four opcodes: CTV (BIP-119), CSFS (BIP-348), OP_INTERNALKEY, and OP_PAIRCOMMIT. It targets Lightning Network improvements specifically, enabling LN-Symmetry and more efficient channel constructions. LNHANCE does not include OP_CAT, positioning it as a more conservative alternative to general-purpose covenant proposals.

This tool is for informational purposes only and does not constitute financial or technical advice. Proposal statuses, activation parameters, and community positions change frequently. BIP statuses referenced are as of mid-2026. Always verify current proposal status on the Bitcoin BIPs repository and Bitcoin Optech before making decisions based on this information.