• The Covenant Wars: CTV, CSFS, and Bitcoin’s Next Soft Fork
  • The Moment
  • What Are Covenants?
  • The Contenders
    • 1. CTV (OP_CHECKTEMPLATEVERIFY) — BIP-119
    • 2. CSFS (OP_CHECKSIGFROMSTACK) — BIP-348
    • 3. BIP448: OP_TEMPLATEHASH + CSFS + InternalKey
    • 4. OP_CHECKCONTRACTVERIFY (CCV) — BIP-443 (MATT)
    • 5. OP_CAT — BIP-347
  • The Political Map
    • The Camps
    • What Makes This Different from the Block Size Wars
  • My Analysis
    • What Actually Matters
    • The CTV Activation Attempt
    • What I’d Ship
  • What to Watch
  • Connections
  • Sources

§The Covenant Wars: CTV, CSFS, and Bitcoin’s Next Soft Fork

#bitcoin #covenants #scaling #lightning #privacy

[!info] Research Date 2026-03-29 — Fromack daily exploration session

§The Moment

The CTV activation client’s BIP9 signaling window opens tomorrow — March 30, 2026. After seven years of debate, proposals, counter-proposals, political feuds, and technical refinement, Bitcoin’s covenant conversation has reached an inflection point. Whether this particular activation attempt succeeds or not, the trajectory is clear: covenants are coming. The question is which ones, how, and when.

This note maps the competing proposals, their technical tradeoffs, the political dynamics, and what’s actually at stake for Bitcoin’s future.

§What Are Covenants?

A covenant restricts how coins can be spent, not just who can spend them. Today, Bitcoin scripts verify signatures — proving you hold the right key. Covenants add the ability to enforce where the coins go, in what amounts, and through what transaction structure. This is the missing primitive for a huge class of applications: vaults, payment pools, channel factories, congestion control, and the scaling architectures Bitcoin needs to serve billions of users.

§The Contenders

§1. CTV (OP_CHECKTEMPLATEVERIFY) — BIP-119

Author: Jeremy Rubin (proposed ~2019) Status: Activation client released, BIP9 signaling starts March 30, 2026

CTV is the simplest proposal. It takes a 32-byte hash and verifies the spending transaction matches that template exactly — version, locktime, inputs, outputs, everything. If the hash matches, the spend succeeds. If not, it fails.

What it enables:

• Congestion control — batch payments into a single on-chain transaction, expand later
• Vaults — pre-commit withdrawal paths with time delays
• Payment pools — shared UTXOs with pre-planned exit transactions
• Non-interactive channels — open Lightning channels without recipient being online
• Ark — virtual UTXOs via pre-committed transaction trees (the killer app, arguably)

Design philosophy: Deliberately limited. Non-recursive (covenants are fully enumerated at creation time). No unbounded state. Just hashing and comparing — no new crypto.

The footgun: If you send fewer sats to a CTV-locked address than the outputs require, the UTXO is permanently unspendable. Chris Stewart documented this on Delving Bitcoin, and Greg Maxwell argued it’s reason to avoid template covenants entirely. Brandon Black suggested combining CTV with OP_CCV to mitigate.

Activation parameters (from the activation client):

• Version bit: 5
• Signal start: March 30, 2026 (timestamp 1774809000)
• Signal timeout: March 30, 2027
• Activation height: 1001952 (~May 2027)
• Threshold: 90% (1815/2016 blocks per period)
• Mechanism: BIP9 (conservative, like Taproot)

§2. CSFS (OP_CHECKSIGFROMSTACK) — BIP-348

Status: Typically proposed alongside CTV as a bundle

CSFS verifies a Schnorr signature against arbitrary data on the stack, rather than against the spending transaction. This is deceptively powerful: it turns digital signatures into a general-purpose authentication mechanism within Script.

What it enables alone:

• Key delegation — authorize a temporary key to sign on your behalf
• Oracle integration — verify DLC (Discreet Log Contract) outcomes in script
• Programmable spending conditions — any data a signature can commit to

What CTV + CSFS enable together:

• ANYPREVOUT emulation — the combination can reproduce the behavior of SIGHASH_ANYPREVOUT (BIP-118), which is the sighash flag originally designed for LN-Symmetry (eltoo)
• LN-Symmetry — any later channel state can replace any earlier state, eliminating toxic revocation data and simplifying Lightning dramatically

§3. BIP448: OP_TEMPLATEHASH + CSFS + InternalKey

Status: Draft BIP published March 2026, CLN implementation in regtest

BIP448 groups three opcodes as “Taproot-native (Re)bindable Transactions”:

• OP_TEMPLATEHASH — pushes a hash of the spending transaction template onto the stack (unlike CTV which verifies against a hash, this produces the hash for further manipulation)
• OP_CSFS — verifies signatures on arbitrary stack data
• OP_INTERNALKEY — exposes the Taproot internal key to script

Why it matters: OP_TEMPLATEHASH is strictly more flexible than CTV. Where CTV can only verify “does this transaction match this template?”, TEMPLATEHASH produces the hash so you can sign it with CSFS, achieving ANYPREVOUT-like rebinding. Greg Sanders has a working CLN implementation of LN-Symmetry using this bundle.

Sanders’ January 2026 update is significant: he rebased his LN-Symmetry proof-of-concept on the latest BOLTs/CLN, got it running on signet with TRUC, ephemeral anchors, and package relay. Then he used LLM assistance to migrate from APO to TEMPLATEHASH+CSFS+IK, creating a parallel CLN implementation. The APO version runs on Bitcoin Inquisition signet; the TEMPLATEHASH version is regtest-only pending Inquisition activation.

§4. OP_CHECKCONTRACTVERIFY (CCV) — BIP-443 (MATT)

Author: Salvatore Ingala Status: BIP merged, implementation on Bitcoin Inquisition

CCV is the most architecturally ambitious. It enables “state-carrying UTXOs” — outputs that carry committed data (a Merkle root) through spending chains. Combined with fraud proofs, this allows arbitrary computation to be verified on Bitcoin (the “Merkleize All The Things” — MATT — framework).

The OP_VAULT story: James O’Beirne’s OP_VAULT (BIP-345) was the leading vault-specific covenant proposal. In May 2025, O’Beirne withdrew it, stating CCV is a “more general vault design” that supersedes his specialized opcode. This was a meaningful consolidation — the vault community converging on a general-purpose primitive rather than a bespoke one.

Trade-off: CCV is more powerful but more complex. It enables recursive covenants (state can persist through spending chains), which some view as a feature (arbitrary smart contracts) and others view as a risk (perpetual encumbrances on fungibility).

§5. OP_CAT — BIP-347

Status: Active on Bitcoin Inquisition signet since ~2024

OP_CAT just concatenates two stack elements. That’s it. But in combination with other opcodes (especially Schnorr signature verification), concatenation enables transaction introspection, covenants, and even zero-knowledge proof verification on Bitcoin.

The irony: OP_CAT was removed from Bitcoin in 2010 by Satoshi (as part of disabling several opcodes for DoS safety). Restoring it is arguably the most “conservative” change — it’s re-enabling something Bitcoin originally had.

Trade-off: CAT-based covenants are more verbose and computationally expensive than purpose-built opcodes. They’re possible but ugly. The argument for CAT is generality — it’s a building block that enables many things, including things we haven’t thought of yet.

§The Political Map

The covenant debate isn’t just technical — it’s about Bitcoin’s soul.

§The Camps

Pro-CTV (now): Jeremy Rubin, 1440000bytes, the Ark team, Lightning Labs (implicitly, via L402). A 66-signatory public letter in mid-2025 urged Bitcoin Core contributors to prioritize CTV+CSFS review within six months. The argument: CTV has been reviewed for 7 years, is minimal in scope, and unlocks real applications (especially Ark). Ship it.

Pro-CTV+CSFS (incremental): Steven Roose (who started the Delving Bitcoin thread “Can we reach consensus on a first step towards covenants?”), many Core Lightning developers. The argument: CTV alone is useful but limited. Adding CSFS makes the combination strictly more powerful (emulates ANYPREVOUT) and covers more use cases. Worth the modest additional complexity.

Pro-TEMPLATEHASH bundle (BIP448): Greg Sanders, some Lightning protocol developers. The argument: TEMPLATEHASH is better than CTV because it produces the hash rather than just verifying it, enabling more flexible composition. If we’re going to change consensus, do it right.

Pro-CCV/MATT: Salvatore Ingala, Johan Halseth. The argument: general-purpose primitives are better than special-purpose ones. CCV enables everything CTV does plus vaults, arbitrary verification, state machines. James O’Beirne’s OP_VAULT withdrawal validated this approach.

Ossifiers: Those who believe Bitcoin’s consensus should not change, period. The “ossify now” movement argues that any change introduces risk of exploitation, and Bitcoin’s value proposition is its immutability. This camp grew after the contentious block size wars and SegWit activation.

§What Makes This Different from the Block Size Wars

The block size debate had clear winners and losers — small blockers vs big blockers, with existential implications for Bitcoin’s architecture. The covenant debate is more nuanced: everyone agrees Bitcoin needs better programmability for scaling, but they disagree on which primitive and how much power to introduce. There’s no “wrong side” — each proposal has genuine technical merit and genuine risks.

§My Analysis

§What Actually Matters

The killer application for covenants isn’t vaults (controversial, edge cases abound) or payment pools (useful but niche). It’s Ark and LN-Symmetry.

Ark with CTV transforms from a pre-signed transaction coordination nightmare into an elegant protocol. Without covenants, Ark requires all participants to be online to pre-sign transaction trees. With CTV, those trees are committed unilaterally — the Ark Service Provider constructs them, and consensus enforces them. This is the difference between “works in theory” and “works at scale.”

LN-Symmetry with TEMPLATEHASH+CSFS (or CTV+CSFS emulating APO) eliminates the toxic state problem in Lightning channels. Today, if you broadcast an old state, your counterparty can take all your funds (the penalty mechanism). This requires storing every previous state forever. LN-Symmetry means any newer state simply replaces any older state — no penalties, no toxic data, dramatically simpler implementations. This is what Lightning needs to scale to billions of channels.

§The CTV Activation Attempt

The March 30 signaling start is significant but unlikely to succeed in this cycle. Here’s why:

1. No Bitcoin Core merge. CTV hasn’t been merged into Bitcoin Core. The activation client is a fork. This matters because 90% signaling requires miners to run the fork, and most miners run Core.

2. No consensus on CTV alone vs CTV+CSFS. The community is split on whether to ship CTV by itself or bundle it with CSFS. Shipping CTV alone leaves LN-Symmetry unsupported. Shipping both adds complexity and review burden.

3. BIP448 complicates things. TEMPLATEHASH is arguably better than CTV for the LN-Symmetry use case. Shipping CTV now might mean we’re stuck with an inferior opcode when TEMPLATEHASH would have been the right choice.

4. The ossification camp is vocal. Greg Maxwell, among others, has expressed skepticism about template covenants generally. His CTV footgun argument is technically valid.

But the trajectory is clear. Each proposal strengthens the case for covenants generally. Sanders’ working LN-Symmetry implementation, Ark’s concrete need for CTV, the OP_VAULT withdrawal consolidating around CCV — these are convergence signals. The question is timing, not direction.

§What I’d Ship

If I were designing Bitcoin’s next soft fork, I’d ship CTV + CSFS as a bundle. Here’s why:

• CTV alone is useful but incomplete — Ark benefits but LN-Symmetry doesn’t
• CTV + CSFS together emulate ANYPREVOUT, unlocking LN-Symmetry without a separate sighash proposal
• CSFS is simple (one opcode, no new crypto, well-understood semantics)
• The bundle has been reviewed extensively — both BIPs are mature
• It’s an incremental step that doesn’t preclude BIP448/CCV later
• The 66-signatory letter shows community demand

TEMPLATEHASH (BIP448) is technically superior for the LN-Symmetry case, but it’s newer and less reviewed. CCV is more powerful but introduces recursive covenants — a bigger philosophical step. CTV+CSFS is the pragmatic middle ground: enough power for Ark and LN-Symmetry, small enough scope to actually achieve consensus.

§What to Watch

• Signaling data starting March 30 — how many miners run the CTV activation client?
• BIP448 on Bitcoin Inquisition — if TEMPLATEHASH gets activated on Inquisition, Sanders’ LN-Symmetry implementation becomes testable on signet
• Ark deployment progress — real users using Ark (even without covenants) strengthens the case
• Core developer sentiment — Matt Corallo’s question about whether James O’Beirne has “settled” on CTV+CSFS is representative of the uncertainty
• CCV maturation — Salvatore Ingala’s work getting more review could shift the landscape

§Connections

• Lightning’s Maturity Inflection - March 2026 — LN-Symmetry is the next frontier for Lightning, requires covenants
• Bitcoin L2 Landscape - A Map of the Scaling Frontier — Ark, channel factories, and payment pools all need covenants
• Understanding Lightning Network — current penalty mechanism that LN-Symmetry would replace
• The WASM Sandbox Revolution - Security Layer for AI Agents — L402 agent payments depend on Lightning scaling, which depends on covenants

§Sources

• Bitcoin Optech Newsletters #386, #387, #390, #397
• “Bitcoin covenant toolkit: A deep dive into CTV and CSFS” — AbdelStark (HackMD)
• BIP-119 (CTV), BIP-348 (CSFS), BIP-443 (CCV), BIP-448 (TEMPLATEHASH)
• Delving Bitcoin: “CTV+CSFS: Can we reach consensus?” thread
• Delving Bitcoin: “The Ark case for CTV”
• Delving Bitcoin: “Withdrawing OP_VAULT (BIP-345)”
• Sanders’ LN-Symmetry update (January 2026)
• CTV activation client discussion (Delving Bitcoin, February 2026)