Bitcoin Covenant Activation: Navigating the Path Forward After Years of Debate

Bitcoin covenant activation has been debated for years, yet no covenant opcode has been merged into Bitcoin Core or activated on mainnet. The proposals would fundamentally expand what Bitcoin Script can do: restricting how coins are spent in future transactions, not just who can spend them. That capability unlocks vaults, better Layer 2 exit mechanisms, congestion control, and more expressive discreet log contracts. But agreeing on which opcodes to activate and how to activate them has proven harder than designing them.

As of mid-2026, the landscape includes at least five major proposals, two competing opcode bundles, a failed miner signaling attempt, and a growing institutional voice arguing that Bitcoin's consensus rules should be treated as effectively immutable. This article maps the terrain: what each proposal does, why none has crossed the finish line, and what activation would mean for Bitcoin's future.

What Are Bitcoin Covenants?

A covenant is a spending condition that constrains not just who can spend a coin, but where it can go. Today, Bitcoin Script can enforce conditions like "this coin is spendable by whoever holds private key X" or "this coin is spendable after block height Y." Covenants add a third dimension: "this coin can only be spent into a transaction matching template Z."

This sounds abstract, but the practical implications are significant. With covenants, you can build vaults that require a time delay before withdrawals, giving owners a window to claw back stolen funds. You can create congestion control transactions that commit to a batch of future payments in a single on-chain output. You can construct more efficient payment channels and shared UTXO structures that scale Bitcoin without sacrificing self-custody.

The Major Covenant Proposals

Five proposals have shaped the covenant debate. Each takes a different approach to the same fundamental question: how much additional expressiveness should Bitcoin Script gain?

OP_CTV: CheckTemplateVerify (BIP 119)

Proposed by Jeremy Rubin, OP_CTV is the longest-running and most debated covenant proposal. It works by verifying a hash of the spending transaction's key fields: version, locktime, outputs, input count, and sequence values. If the hash on the stack matches the actual transaction, the spend succeeds. CTV is intentionally minimal: it commits to all fields in a fixed way, offering no flexibility in which fields are constrained.

That minimalism is both its strength and its limitation. Supporters argue CTV is small, well-reviewed, and sufficient for the most important use cases: vaults, congestion control, and non-interactive channel openings. Critics contend that its rigidity means Bitcoin would need additional opcodes soon after, making CTV a stepping stone rather than a destination.

OP_CAT: Concatenation (BIP 347)

Authored by Ethan Heilman and Armin Sabouri, OP_CAT takes the opposite approach. It reintroduces a single, general-purpose opcode that concatenates two stack elements. Satoshi included OP_CAT in Bitcoin's original release, but it was disabled in 2010 due to denial-of-service concerns. The new proposal redefines Tapscript opcode OP_SUCCESS126, with the existing 520-byte stack element size limit mitigating the original DoS vector.

OP_CAT's power comes from composition. By concatenating stack elements and hashing the result, scripts can introspect transaction fields, verify zero-knowledge proofs, and construct arbitrary covenants. On Bitcoin Inquisition's signet, OP_CAT has seen approximately 74,000 test transactions: far more than any other covenant proposal. Developers have used it to build a proof-of-work faucet and verify STARK proofs on-chain.

The BIP 347 document reached "Complete" status on March 1, 2026, meaning the specification is finalized. But document completion does not imply activation consensus: no activation client has been released for OP_CAT.

OP_VAULT (BIP 345, Withdrawn)

James O'Beirne and Greg Sanders designed OP_VAULT specifically for vault construction. It proposed two opcodes: OP_VAULT for time-locked withdrawals and OP_VAULT_RECOVER for immediate recovery to a pre-designated safe address. The design depended on CTV (or a similar template opcode) for defining the withdrawal spending template.

In May 2025, O'Beirne formally withdrew BIP 345, stating it had been superseded by OP_CHECKCONTRACTVERIFY (BIP 443), authored by Salvatore Ingala. BIP 443 is more general: it can construct vaults but also enables state-carrying UTXOs, CoinPools, Timeout Trees, and Ark-style UTXO sharing schemes. The withdrawal signaled a broader trend in the covenant debate: proposals are converging toward more general primitives rather than purpose-built opcodes.

OP_TXHASH (BIP 346)

Steven Roose and Brandon Black proposed OP_TXHASH as a strict superset of CTV. Where CTV hashes all transaction fields in a fixed order, TXHASH introduces a TxFieldSelector: a variable-length byte sequence where individual bits specify which transaction fields are included in the hash. Users can constrain only the outputs, or only the locktime, or any combination.

TXHASH addresses one of CTV's core criticisms: that its fixed template is too rigid for evolving use cases. If TXHASH were activated, CTV's functionality could be replicated exactly. The tradeoff is added complexity in consensus-critical code.

LNHANCE and Competing Bundles

Rather than activating individual opcodes, the LNHANCE bundle proposed by Brandon Black combines three opcodes: CTV (BIP 119), CHECKSIGFROMSTACKVERIFY (BIP 348, or CSFS), and OP_INTERNALKEY (BIP 349). CSFS enables signature verification against arbitrary stack messages rather than the transaction itself. OP_INTERNALKEY pushes the Taproot internal key onto the stack.

Together, these opcodes unlock LN-Symmetry (cleaner Lightning channel state updates without penalty transactions), timeout trees, simplified PTLCs, and non-interactive channel openings. BIP 348 (CSFS) was merged into the BIPs repository in November 2024.

In March 2026, a competing bundle emerged: BIP 446 (OP_TEMPLATEHASH) and BIP 448 (Taproot-native Rebindable Transactions), authored by Greg Sanders, Antoine Poinsot, and Steven Roose. BIP 446 is similar to CTV but designed to be Taproot-native, reusing existing Taproot signature hash structures. BIP 448 packages it with CSFS and INTERNALKEY.

The bundle problem: Three proposals now target overlapping capabilities: CTV+CSFS, the original LNHANCE bundle (CTV+CSFS+IKEY), and BIP 446+448 (TEMPLATEHASH+CSFS+IKEY). Each camp argues its approach is cleaner, but the proliferation of alternatives fragments developer attention and delays consensus.

Comparing the Proposals

Each proposal makes different tradeoffs between simplicity, expressiveness, and review burden.

What Covenant Activation Would Unlock

The practical case for covenants rests on several concrete capabilities that Bitcoin currently lacks.

Vaults for Self-Custody Security

A vault is a covenant-bound output with a time-delayed withdrawal path. When you initiate a withdrawal, the covenant enforces a waiting period (say, 24 hours) before the funds can move to their final destination. During that window, you can sweep everything to a pre-designated recovery address if the withdrawal was unauthorized.

This transforms Bitcoin self-custody from a single point of failure (lose your key, lose your coins) into a system with a built-in safety net. Enterprise custody, inheritance planning, and individual cold storage all benefit. Today, vaults can be approximated with multisig setups and pre-signed transactions, but covenant-based vaults would be simpler, cheaper, and enforceable at the protocol level.

Better Layer 2 Exit Mechanisms

Every Bitcoin Layer 2 protocol needs an escape hatch: a way for users to withdraw funds to L1 without cooperation from other participants. Covenants make these exits more efficient and flexible. Channel factories, where multiple Lightning channels share a single on-chain UTXO, become practical. Timeout trees enable shared UTXO pools where individual users can exit unilaterally without forcing everyone else on-chain.

For protocols like Ark and similar UTXO sharing schemes, covenants reduce the on-chain footprint of exits and eliminate the need for interactive coordination among participants.

Congestion Control

During fee spikes, a single on-chain transaction can commit to a tree of future payments. Recipients know their funds are locked and can claim them later when fees drop. This is particularly valuable for exchanges processing batched withdrawals and for Lightning Service Providers opening channels in bulk.

Discreet Log Contracts

DLCs enable conditional payments based on oracle-attested external data. With covenants, DLC efficiency improves dramatically: non-recursive covenants like CTV could reduce the number of pre-signed transactions from thousands to a handful, making complex multi-outcome contracts practical on Bitcoin.

Why No Proposal Has Activated

The technical designs are mature. Multiple proposals have been reviewed for years, tested on signet, and implemented in working code. The barrier is governance, not engineering.

Competing Proposals Fragment Consensus

When Taproot activated in 2021, it was the only soft fork proposal under serious consideration. The covenant landscape has no such clarity. CTV supporters argue it should go first because it is simplest and most reviewed. LNHANCE advocates argue CTV alone is insufficient without CSFS. OP_CAT proponents want the most general primitive possible. BIP 446+448 supporters argue that a Taproot-native design is cleaner than retrofitting CTV.

Each camp has legitimate technical arguments, but the effect is gridlock. Developers who might rally behind a single proposal instead split their review effort across multiple competing BIPs.

The Speedy Trial Question

Bitcoin's last soft fork, Taproot, activated via Speedy Trial (a variant of BIP 9 signaling): miners had a three-month window to signal readiness at a 90% threshold. Taproot locked in on June 12, 2021, and activated at block 709,632 on November 14, 2021.

But Speedy Trial was designed for proposals with overwhelming pre-existing consensus. Covenants do not have that consensus. Jeremy Rubin attempted a CTV Speedy Trial in April 2022, releasing an activation client. The attempt met immediate opposition from developers who felt it was premature, and Rubin called it off within weeks.

In February 2026, a new CTV activation client appeared with BIP 9 parameters: a 90% miner signaling threshold (1,815 of 2,016 blocks), a signaling window from March 30, 2026 to March 30, 2027, and a minimum activation height around May 2027. As of late May 2026, miner signaling stands at 0%. The attempt appears unlikely to succeed without a dramatic shift in community sentiment.

Institutional Resistance

A new dynamic has emerged in 2026: institutional capital asserting influence over Bitcoin's consensus process. Michael Saylor posted a nine-part statement on July 28, 2026, framing Bitcoin's protocol rules as a "constitution" and arguing that any faction rewriting them without near-unanimous consent commits "economic theft." He grouped covenants alongside BIP-110 and larger-block proposals as threats to Bitcoin's stability.

Whether or not this view prevails, it represents a governance factor that did not exist during Taproot activation: holders of large Bitcoin positions actively opposing base-layer changes as a matter of principle, regardless of technical merit.

Lessons from Taproot Activation

The Taproot activation process itself took over three years of debate about methodology. The core disagreement: LOT=true (a user-activated soft fork where nodes reject non-signaling blocks after a timeout, forcing activation) versus LOT=false (if miners do not signal by the timeout, the attempt simply fails). The community eventually settled on Speedy Trial as a compromise.

For covenants, no method has gathered support. Speedy Trial requires consensus that does not exist. UASF risks a chain split over a change many participants see as unnecessary. And independent activation clients (like the February 2026 CTV client) face legitimacy questions when Bitcoin Core contributors have not endorsed them.

Bitcoin Inquisition: Testing Without Activation

While the activation debate stalls, development continues on Bitcoin Inquisition, a software fork of Bitcoin Core maintained by AJ Towns. Inquisition deploys proposed soft fork opcodes on the default signet, letting developers build and test real applications without risking mainnet.

Several covenant opcodes are live on Inquisition's signet: SIGHASH_ANYPREVOUT (BIP 118), OP_CTV (BIP 119), OP_CAT (BIP 347), and the LNHANCE opcodes (CSFS and INTERNALKEY). The usage data is telling: OP_CAT has seen approximately 74,000 transactions, ANYPREVOUT around 1,000, and CTV just 16. OP_CAT's signet activity includes a proof-of-work faucet and STARK zero-knowledge proof verification, demonstrating its broad composability.

Signet testing vs. mainnet consensus: High signet transaction counts show developer interest, not community consensus. OP_CAT's 74,000 signet transactions demonstrate that developers want to build with it, but signet activity has no bearing on activation governance. Conversely, CTV's low signet count may reflect its simplicity: there is less to experiment with when the opcode does exactly one thing.

The Emerging Developer Consensus

Despite the activation deadlock, a rough technical consensus is forming around a phased approach. CTV+CSFS (BIP 119 + BIP 348) is widely considered the frontrunner combination for a first covenant soft fork. The rationale: CTV is minimal and well-reviewed, CSFS adds signature verification flexibility without the broad expressiveness (and unpredictable consequences) of OP_CAT. Together, they enable LN-Symmetry, vaults, timeout trees, and simplified PTLCs.

A second phase could introduce OP_CAT along with additional arithmetic and elliptic curve operations, unlocking the full range of script-based covenants. This phased model mirrors how Segregated Witness laid groundwork for Taproot: each upgrade builds on the last.

However, BIP 446+448 complicates this narrative by offering a Taproot-native alternative to CTV that reuses existing signature hash structures. If the community gravitates toward BIP 446, the CTV+CSFS consensus may dissolve before it solidifies.

What This Means for Bitcoin Layer 2 Protocols

Layer 2 protocols are the primary beneficiaries of covenant activation, but they cannot wait for it. Every production L2 today is designed to work without covenants: Lightning uses HTLCs and penalty transactions, Spark uses statechains with FROST threshold signatures, and Ark uses connector outputs with pre-signed transaction trees.

Covenants would enhance these protocols rather than replace their current designs. For Spark, covenants could enable more expressive on-chain conditions for statechain exits, reducing reliance on pre-signed transactions and improving the trust model. For Lightning, CTV+CSFS would enable LN-Symmetry, eliminating the toxic justice transaction mechanism and simplifying channel state management. For Ark, covenants would make the shared UTXO model more efficient and reduce interactivity requirements.

The key insight: well-designed L2 protocols treat covenants as an upgrade path, not a prerequisite. Spark already provides instant, self-custodial Bitcoin transfers without any new opcodes. If and when covenants activate, they become an additional tool for improving exit efficiency and reducing trust assumptions.

The Road Ahead

The covenant debate is unlikely to resolve quickly. The combination of competing proposals, institutional resistance, and the absence of an urgent catalyst (Bitcoin works without covenants, even if it could work better with them) means activation could take years. Several scenarios are plausible.

• The community converges on CTV+CSFS (or BIP 446+CSFS) as a minimal first step, and a Speedy Trial attempt gains sufficient miner support. This is the optimistic path but requires one proposal to clearly win the "template opcode" slot.
• OP_CAT gains enough grassroots developer support that its activation becomes a movement similar to UASF, bypassing the proposal competition entirely. The 74,000 signet transactions and broad composability make this plausible but risky.
• No covenant activates for several more years. L2 protocols continue building with existing primitives, and the urgency for covenants gradually fades as workarounds mature.
• A phased approach succeeds over multiple years: CTV+CSFS first, OP_CAT later, each building on tested primitives. This mirrors the SegWit-to-Taproot trajectory.

Whatever path prevails, Bitcoin's covenant debate reveals the deeper tension in protocol governance: the features that would most improve Bitcoin's capabilities are also the hardest to activate, precisely because the community values stability and caution above all else.

Building on Bitcoin Today

The covenant debate matters for Bitcoin's long-term trajectory, but it should not obscure what is already possible. Protocols like Spark deliver instant, low-cost Bitcoin and stablecoin transfers today, using statechains and FROST threshold signatures within Bitcoin's current consensus rules. Developers can start building with the Spark SDK now, and any future covenant activation would only expand what the protocol can do.

For a deeper look at how Bitcoin's soft fork process has worked historically, see our research on Bitcoin soft fork activation history. To understand the specific covenant proposals in more detail, read our coverage of OP_CTV and the OP_CAT debate.

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.