Skip to main content

Bitcoin's Covenant Renaissance: How OP_CTV, LNHANCE, OP_CAT, and BitVM2 Could Finally Bring Smart Contracts to Bitcoin L1

· 13 min read
Dora Noda
Dora Noda
Software Engineer

For fifteen years, Bitcoin's scripting language has been deliberately, aggressively boring. No loops. No recursion. No state. A small stack, a handful of opcodes, and a culture that treats every proposed expansion like a potential civil war. That conservatism is the reason Bitcoin has never been successfully exploited at the consensus layer — and the reason developers who wanted to build anything beyond "send coins from A to B" eventually gave up and moved to Ethereum.

That calculus is shifting in 2026. OP_CHECKTEMPLATEVERIFY has concrete activation parameters on the table for the first time since BIP-119 was drafted. OP_CAT has an official BIP number. LNHANCE is being actively discussed as a Lightning-focused alternative. And BitVM2 — which doesn't require any soft fork at all — is already live in production, powering Citrea's mainnet bridge that launched in January. After years of "covenants are coming soon," Bitcoin is finally in the phase where multiple credible proposals are running in parallel, each solving a different slice of the problem.

What Covenants Actually Are (And Why They've Been So Contentious)​

A covenant, in Bitcoin terms, is a restriction on how a UTXO can be spent in the future. Normal Bitcoin script can only answer the question "is this spend authorized right now?" A covenant extends that to "is this spend authorized, and does the next transaction match these conditions?"

That small extension unlocks a surprising amount of functionality. Vaults that enforce a mandatory time delay before funds can leave a specific destination. Congestion-control commitments that let one on-chain transaction fund thousands of off-chain payments. Payment pools. Non-interactive channels. ZK-rollup bridges that don't rely on multisig federations. The list of things that become newly possible is long enough that developers have been arguing about covenants for the better part of a decade.

Why the fight? Two real concerns, one cultural one. Technically, recursive covenants — covenants that enforce themselves onto every subsequent spend, forever — could theoretically be used to create permanently restricted coins, undermining Bitcoin's fungibility. Culturally, Bitcoin's development ethos treats every new opcode as potential attack surface, and enabling covenants after Taproot is, to some developers, an unacceptable expansion of the protocol's complexity budget. The Bitcoin Magazine coverage of the BIP-119 debate captured this dynamic bluntly: "Enabling covenants on Bitcoin is a big step change with barely any existing research on the topic, and attempting to rush it through by the back door so soon after Taproot activation should be resisted."

Three years of additional research later, that "barely any" critique is harder to sustain.

OP_CTV (BIP-119): The Minimalist Vault Proposal​

OP_CHECKTEMPLATEVERIFY is the covenant proposal closest to actual activation. Authored by Jeremy Rubin, BIP-119 adds a single opcode that commits a UTXO to being spent into a specific, predetermined transaction template — the version, locktime, input count, sequences, output count, outputs, and the spending input's position. Match the template, you can spend. Don't match, you can't.

That's it. OP_CTV is non-recursive by design: you can commit to a future transaction, but that future transaction can't itself commit to further transactions in a way that creates perpetual restriction. This deliberate limitation is why CTV advocates consider it the "safe" covenant — it enables vaults, congestion control, and certain Lightning improvements, but it can't be used to build permanently tainted coins.

The concrete news for 2026: CTV deployment parameters now specify a start time of March 30, 2026, a timeout of March 30, 2027, a minimum activation height of May 2027, a 90% miner signaling threshold, and a 2016-block signaling period. This is not consensus — it's a proposal for activation parameters. But it's the first time since 2022 that a concrete timeline has been on the table, and it represents the CTV camp calling the question: activate it, or formally reject it.

The practical killer app for CTV is the vault. Today, if a user wants to self-custody $1M in Bitcoin with protection against single-key compromise, their options are ugly: multisig with geographic key distribution (operationally painful), time-locked transactions (brittle), or custodial services (defeats the point). A CTV vault lets a user commit that any spend from their cold storage must first go through a time-locked intermediate address, during which the user can detect unauthorized activity and trigger a recovery clawback. This is the kind of primitive that materially changes the risk profile of large Bitcoin holdings.

OP_CAT (BIP-347): The Recursive Covenant Maximalist Path​

OP_CAT is almost the opposite proposal philosophically. Where CTV is one carefully scoped opcode designed to enable a specific set of use cases, OP_CAT is a primitive — string concatenation on the stack — that was already in the original Bitcoin scripting language before being disabled in 2010 over DoS concerns that no longer apply in the post-Taproot script size limits.

Re-enabling OP_CAT doesn't look like much on the surface: it just lets scripts concatenate two byte strings. But concatenation, combined with Schnorr signatures introduced by Taproot, is enough to build introspection — the ability for a script to examine the transaction spending it. And introspection is enough to build recursive covenants, state machines, and by extension, almost any smart contract you could write on an EVM-style chain.

StarkWare published a proof-of-concept bridge covenant on OP_CAT-enabled Bitcoin that demonstrates exactly this: trust-minimized bridging from Bitcoin to L2s, enforced entirely by Bitcoin script, without requiring a federated multisig or a separate bridge chain. The sCrypt team has published a multi-part series showing how OP_CAT enables stateful UTXO contracts, NFT-style ordinal trading, and recursive vaults.

The trade-off is exactly what CTV advocates worry about. OP_CAT's expressiveness includes the expressiveness to create permanently restricted coins. In practice, this already exists in weaker forms (multisig with lost keys, time-locks with impossibly distant maturity), and OP_CAT's defenders argue that the fungibility concern is theoretical rather than operational. But the philosophical divide is real: OP_CTV says "let's enable covenants for these specific use cases"; OP_CAT says "let's enable the primitive and let developers figure out the use cases."

OP_CAT receiving BIP-347 in 2024 was important less for its technical substance — CAT is a four-byte opcode — than for signaling that the covenant maximalist path had enough developer credibility to clear the BIP process.

LNHANCE: The Lightning-Targeted Compromise​

LNHANCE is the proposal with the clearest "what problem does this solve" pitch. Rather than arguing for covenants on abstract grounds, LNHANCE bundles OP_CTV with OP_CHECKSIGFROMSTACK (CSFS) and OP_INTERNALKEY, specifically targeting improvements to the Lightning Network.

The Lightning Network in April 2026 has grown to over 65,000 public nodes and has become the dominant Bitcoin payments rail, but it carries real protocol debt. Channel state verification still requires watchtower services or online wallets. Channel factories and multi-party channels are difficult to construct. Non-interactive channel openings — where one party can open a channel to another without the recipient being online — aren't possible in current Lightning.

LNHANCE enables LN-Symmetry (a cleaner channel state mechanism), timeout trees (efficient bulk channel closures), simplified PTLC scripts (point time-locked contracts replacing the current hash time-locked contracts), unidirectional non-interactive channels, improved vaults, and trustless coin pools. Every one of these is a concrete Lightning improvement rather than a speculative smart contract primitive.

This pragmatic framing is LNHANCE's political advantage. The Lightning Network has achieved real adoption, from regional payment processors to the L402 protocol that Lightning Labs is positioning as the native payments layer for AI agent transactions. Improvements that keep Lightning competitive are easier to justify than improvements that primarily enable BTC-on-other-chains use cases.

BitVM2: The Soft-Fork-Free Alternative That's Already Live​

The most pragmatically important development of the past eighteen months isn't a covenant proposal at all — it's BitVM2, and the fact that it requires zero changes to Bitcoin consensus.

BitVM2, authored by Robin Linus, extracts the essence of what covenants enable (verifiable off-chain computation anchored to Bitcoin) without requiring Bitcoin itself to perform the computation. The protocol works on a challenge-response model: a prover makes a claim about some off-chain computation, posts a bond, and if a verifier believes the claim is wrong, they can initiate a binary search dispute that isolates the specific step where the prover cheated. That one step is then executed on-chain in Bitcoin script, and the liar's bond is slashed.

The economic elegance: honest provers are never challenged, so disputes are rare, so the on-chain cost is amortized to near-zero. The computational elegance: BitVM2's revised protocol resolves any dispute in just three on-chain transactions, down from the dozens required in the original BitVM scheme. The permissionless elegance: anyone can challenge, so the security of the system doesn't depend on a fixed set of verifiers staying honest.

BitVM2 is live right now. Citrea — Bitcoin's first ZK-rollup — launched its mainnet on January 27, 2026, with a BitVM2-based bridge (codenamed "Clementine") as the production trust model. GOAT Network released its BitVM2 testnet V3 in Q1 2026, targeting a full Bitcoin-native zkRollup stack. The pattern is becoming clear: teams that don't want to bet their launch timeline on a contentious Bitcoin soft fork are choosing BitVM2 instead.

The limitation is economics, not cryptography. Disputes are paid in Bitcoin blockspace, and in a worst-case scenario where fees spike during a dispute window, challengers can get priced out. This "dispute-economics" risk is the open problem BitVM2 operators are managing with overcollateralization, watchtower services, and careful choice of which computations to secure. It's a real constraint, but a very different kind of risk than "waiting for Bitcoin consensus to agree on an opcode."

The Activation Question: Why Technical Consensus Isn't Enough​

The uncomfortable truth about Bitcoin's covenant debate is that the technical disagreements — recursive vs. non-recursive, minimalist opcode vs. general primitive — are largely resolvable. The harder question is how to activate any of them.

Bitcoin's soft fork history is short and politically charged. SegWit required a UASF (User-Activated Soft Fork) threat to break a miner deadlock in 2017. Taproot used Speedy Trial — a three-month BIP8 window with a 90% miner signaling threshold — and activated cleanly in November 2021. Since then, every discussion of activation methodology has been shadowed by what happened before.

The CTV 2026 parameter proposal uses a Speedy-Trial-style signaling window, which has precedent. But covenant opponents have been clear that they don't consider Speedy Trial appropriate for contentious changes — it was designed specifically for proposals that had already achieved overwhelming consensus, and its three-month window doesn't give the broader ecosystem time to raise objections. Expect the activation methodology fight to be, if anything, more intense than the technical fight.

The political conditions might actually favor activation. Bitcoin's on-chain activity has declined significantly from its 2024 inscription peak, block space demand is soft, and Bitcoin miners — who have to approve any soft fork through signaling — are looking for new narratives that drive demand for block space. Vaults, Lightning improvements, and Bitcoin-secured L2s all generate on-chain transaction demand. The economic self-interest alignment is clearer than it's been in years.

What This Means for Bitcoin Infrastructure Builders​

For teams building on Bitcoin, the covenant renaissance creates a real strategic choice. Teams that need smart-contract-like functionality now have three credible paths:

Path 1 — Wait for CTV/CAT/LNHANCE. Lower complexity, requires soft fork to activate, uncertain timeline. Best for teams whose use case is fundamentally impossible without consensus-level changes (e.g., non-federated vaults at scale).

Path 2 — Build on BitVM2. Available today, higher implementation complexity, economic-security-dependent. Best for teams building Bitcoin L2s, bridges, or rollups who need to ship in 2026 without waiting for consensus.

Path 3 — Hybrid approach. Launch on BitVM2, design the protocol so that covenant activation would provide a cleaner upgrade path. This is the stance GOAT Network and several other Bitcoin L2 teams are taking.

For infrastructure providers, the shared implication is the same: Bitcoin script is getting more expressive no matter which of these paths wins. Wallets, RPC providers, indexers, and node infrastructure all need to be ready to handle richer transaction types — covenant-bearing UTXOs, BitVM2 challenge transactions, new Lightning channel structures — in production.

BlockEden.xyz provides enterprise-grade RPC infrastructure for Bitcoin and Bitcoin-adjacent networks, including emerging L2s building on BitVM2 and covenant-enabled primitives. Explore our API marketplace to build on foundations designed for Bitcoin's next chapter.

The Shape of Bitcoin's Next Decade​

The most interesting thing about 2026 isn't that one of these proposals will definitely activate — any of them could still stall for another year or three. It's that Bitcoin's development culture has decisively moved past the binary "covenants yes vs. covenants no" debate that defined 2022-2024.

The conversation is now about which combination of covenant primitives, off-chain verification protocols, and Layer 2 architectures delivers the most useful programmability with the least consensus change. CTV for vaults and congestion control. CAT for expressiveness and bridges. LNHANCE for Lightning. BitVM2 for anything that can tolerate the dispute-resolution model. These aren't competing visions — they're complementary tools in an expanded Bitcoin scripting toolkit.

Bitcoin spent fifteen years being boring on purpose. That strategic patience built the most secure settlement layer in history. The question for the next decade is whether that same security discipline can survive being extended to cover a genuinely expressive programmable layer. If the 2026 activation debates end with even one of these proposals shipping, the answer will be yes — and Bitcoin's role in the broader crypto ecosystem will shift from "digital gold that doesn't do anything" to "the settlement layer everything else trusts."

Sources:

Share on Twitter