# [BTCFi Series 7] Covenants: Bitcoin's Frozen Fork

> CTV and CSFS would unlock vaults, cheaper bridges, and Ark-scale off-chain venues. We trace why activation stalled and what a 2026 out-of-Core push means.

- Source: https://www.steadyrain.xyz/en/articles/btcfi-series-7-covenants-ctv-csfs/
- Publisher: Steady Rain
- Author: 0xYatha
- Published: 2026-07-15T02:36:36.384Z
- Categories: BTCFi
- Language: en

## Introduction

Bitcoin has not activated a consensus change since Taproot in November 2021. Every other major smart-contract chain has iterated on its execution layer several times over in the same window. Bitcoin, by design, has not — and the frustration this has produced inside the BTCFi builder community is now surfacing as an organized push for a specific, minimal upgrade: the pairing of **OP_CHECKTEMPLATEVERIFY** (CTV) and **OP_CHECKSIGFROMSTACK** (CSFS).

The pitch is narrow. CTV lets a coin commit, in advance, to the exact shape of the transaction that spends it. CSFS lets a script verify a signature over arbitrary data pulled from the stack. Neither introduces recursion. Neither enables the fully general programmability that OP_CAT proponents want. Together, they would nonetheless unlock a class of constructions — non-custodial vaults, more efficient joinpools and channel factories, cheaper discreet log contracts, and simpler paths for Lightning and Ark — that BTCFi builders have been emulating with increasingly fragile presigned-transaction machinery.

The interesting question for us is not whether CTV+CSFS is technically sound. That debate is largely exhausted; the proposal has been in the open for years. The interesting question is why an upgrade this narrow has stalled, and what the mid-2025 open letter and the proposed 2026\~2027 out-of-Core activation timeline mean for how Bitcoin makes consensus decisions going forward. If activation succeeds through a client that is not Bitcoin Core, it will be the first such precedent since the SegWit UASF era, and it will reshape how future protocol changes are negotiated. If it fails, it will confirm that Bitcoin's upgrade path is, functionally, frozen — and that BTCFi builders should plan accordingly.

## What a covenant actually is

*[Figure: img1]*

A covenant, in Bitcoin script terms, is a spending condition that constrains not just whether a UTXO can be spent, but what the spending transaction must look like. Today, script answers a single-tense question: given the witness data, is this spend authorized right now? A covenant extends the tense: given this spend, does the transaction it produces match a shape we committed to earlier?

CTV, specified as BIP-119, implements this in the most restrictive way possible. When a UTXO is locked to a CTV script, the opcode hashes a specific set of fields from the spending transaction and compares them to a template hash embedded in the script. Per Bitcoin Optech, the committed fields are: transaction version, locktime, the scriptsigs, the number of inputs, the sequence values, the number of outputs, the outputs themselves, and the index of the spending input. If any of these differ from the template, the spend fails.

Two properties of this design are worth pausing on. First, CTV commits to outputs but not to inputs — specifically, not to the txids of the inputs. This is what allows the same template to be reused across different funding transactions, which is what makes vaults and congestion-control constructions practical. Second, CTV is **non-recursive by construction**. The template hash is a fixed value in the script; it cannot itself be computed from the spending transaction. A CTV output can force its next hop, but that next hop is a concrete, pre-specified transaction — it cannot in turn be a CTV output whose template is derived from something on the stack. This structural non-recursion is the entire basis of the argument that CTV cannot produce permanently restricted coins.

CSFS is a different primitive. Where Bitcoin's existing OP_CHECKSIG verifies a signature over the current transaction, CSFS verifies a signature over arbitrary data that a spender places on the stack. That data can be anything — a message about a future price, an oracle attestation, a commitment produced by a counterparty in a channel protocol. On its own, CSFS is not a covenant; it is a delegation and attestation primitive. Its power in this pairing comes from what it lets scripts do in combination with CTV: verify that an off-chain party has authorized a specific piece of state, then use CTV to constrain the on-chain settlement of that state.

We have to be honest about a research gap here. The precise mechanics of how CSFS composes with CTV to produce, say, an LN-Symmetry-style channel or a more efficient Ark round were not fleshed out in the source material we worked from. What is clear is that CSFS is included in the "first step" package specifically because CTV alone does not close the design gap that Lightning and Ark builders care most about. Readers who want to trace those constructions in detail should go to the Delving Bitcoin thread and the referenced BIPs directly.

## What CTV unlocks for BTCFi

*[Figure: img2]*

The clearest way to see why builders are pushing this is to walk through the concrete constructions that CTV materially improves.

### Vaults

A Bitcoin vault, in the sense the term has come to acquire, is a cold-storage scheme where any spend from cold must first pass through a time-locked intermediate address. During the delay window, the vault owner can observe the pending spend and, if it is unauthorized, invoke a recovery clawback that redirects funds to a safer key. This is the closest thing Bitcoin has to a native answer to key compromise.

Today, vaults are built with **ephemeral keys and presigned transactions**. The owner generates a temporary keypair, signs the vault's spend paths with it, and then destroys the private key. The security of the vault then rests on the assumption that the ephemeral key was in fact deleted and never leaked before deletion. Bitcoin Optech describes this construction as "fragile at best," which is the polite version of the practitioner view. Verifying key deletion in a way that is auditable and repeatable is a real operational problem, and the class of people willing to run such a scheme with meaningful capital is small.

With CTV — and BIP-345's OP_VAULT builds on CTV for exactly this reason — the presigned-transaction dance is replaced by a covenant. The vault output commits to the shape of the delayed-spend transaction directly in consensus. No ephemeral key exists to leak. No trusted deletion is required. The vault becomes a stateless, replicable construction that a wallet can produce deterministically from public parameters.

### Joinpools and channel factories

Constructions that pool many users' funds into a single UTXO and let them exit or restructure independently — joinpools, channel factories, and their variants — depend on being able to renegotiate off-chain state without going through two full rounds of interactive signing every time. Optech notes that CTV cuts the signing rounds required for state transitions in these constructions **from two to one**. That sounds like an implementation detail; it is actually a scaling and liveness change. A construction that requires all N participants to be online for two rounds fails half as often, in the limit, if it only requires one — and the failure modes of these constructions are usually worse than the happy path suggests.

### Discreet log contracts

DLCs are how Bitcoin does oracle-attested contracts today. A single DLC with, say, BTC/USD payoffs rounded to the nearest dollar can involve more than ten thousand potential outcomes, per Optech, each requiring its own signature adaptor that the counterparties must create, exchange, verify, and store. CTV replaces that per-outcome adaptor with a template. The setup cost of a large DLC drops by roughly the size of the outcome space, which for practical contracts is one to two orders of magnitude.

### Congestion control and batching

CTV also enables a specific fee-market construction: an exchange or custodian can commit onchain to a single template output that, when later unrolled, pays out to many recipients. During congestion, the commitment is cheap; the unroll happens when fees permit. This does not create new capacity, but it lets large actors decouple the timing of user-facing settlement from the timing of onchain confirmation, which changes the demand curve for blockspace during spikes.

The BitVM path is worth mentioning separately. BitVM2 is already live in production, powering Citrea's mainnet bridge without any soft fork. What covenants would offer is not enablement but cost reduction: current BitVM constructions burn substantial script bytes emulating primitives that CTV+CSFS would provide directly. The claim from proponents is that covenants make trust-minimized bridges cheaper, not that they make them possible for the first time.

## The minimalist bet versus OP_CAT's design space

*[Figure: img3]*

CTV+CSFS is not the only covenant proposal on the table. The most-discussed alternative is **OP_CAT**, a four-byte opcode that simply concatenates the top two items on the stack. It was part of the original Bitcoin scripting language and was disabled in 2010 over denial-of-service concerns tied to unbounded stack growth. OP_CAT was assigned BIP number 347 in 2024, which is a signal that it has cleared the process bar of technical seriousness, not a signal that it is close to activation.

The design philosophy gap between the two camps is real. CTV is a **specific, purpose-built opcode**: it does one thing (commit to a template hash), and it does it in a way that structurally rules out recursion. OP_CAT is a **primitive**: it does one very small thing (concatenate bytes), but that primitive, combined with Taproot's Schnorr signatures, enables script introspection — the ability of a script to reason about the transaction that contains it — which in turn enables recursive covenants and general state machines. StarkWare has published a proof-of-concept OP_CAT bridge covenant demonstrating trust-minimized Bitcoin-to-L2 bridging without a federated multisig. That kind of construction is not available under CTV+CSFS.

The tradeoff, then, is between two positions that are both internally coherent.

The CTV+CSFS position is that covenants should be added in the smallest possible increments, that recursion is a distinct escalation, and that the fungibility concern raised against recursive covenants — the theoretical possibility of coins permanently locked into restrictive scripts — is severe enough that it should be handled as its own debate, not tucked inside a general-purpose primitive. Proponents accept that this means several BTCFi constructions will remain out of reach.

The OP_CAT position is that the recursive-covenant concern is largely theoretical, that weaker forms of restriction already exist (multisig, timelocks, hashlocks), and that adding general introspection is a one-time protocol change that opens far more design space than a series of narrow opcodes ever will. The DoS concerns that motivated OP_CAT's disabling in 2010, this camp argues, no longer apply given the script size limits Taproot introduced. We flag the "no longer apply" claim as contested; it is asserted more often than it is proven in the material we reviewed.

There is a third position, held mostly by Bitcoin Core contributors who have been vocal skeptics: that the covenant debate as a whole is premature, that neither proposal has accumulated the review-years that a consensus change warrants, and that Bitcoin's scripting culture — which treats every new opcode as attack surface — should default to no unless the case for yes is overwhelming. This position does not require a technical objection to CTV specifically. It requires only a high prior against consensus changes.

## The June 2025 letter and the 2026 activation plan

*[Figure: img4]*

In June 2025, according to reporting we could not fully verify from primary sources within our research pack, an open letter was published calling for the activation of CTV+CSFS. The topic brief cites approximately 66 signatories including named cryptographers and Lightning developers, but the specific list, exact wording, and full argument of the letter are not directly accessible from the sources we worked with. We are naming this as a gap rather than reciting a list of signatories we cannot verify. What we can say is that the letter existed, that it was covered as a significant industry event, and that its purpose was to demonstrate developer consensus around the minimal covenant package as a first step.

The response from Bitcoin Core contributors, per the topic brief, was pushback rather than endorsement. Again, we do not have direct access to the specific technical objections raised — the Delving Bitcoin thread that hosts the substantive debate was only partially readable in our source material — and we are not going to invent them. What is clear from the shape of the debate is that no faction inside Core has moved to merge CTV+CSFS activation logic into the Core codebase itself.

This is where the 2026 timeline gets interesting. According to a synthesis published in April 2026, the concrete deployment parameters being proposed for an out-of-Core activation client are:

- **Start time**: March 30, 2026
- **Timeout**: March 30, 2027
- **Minimum activation height**: approximately May 2027
- **Signaling threshold**: 90% of miners over a 2016-block period

We treat these numbers as proposed parameters from a secondary source, not finalized consensus. But if they hold, this would be the first concrete soft-fork timeline Bitcoin has produced since Taproot. The mechanism is BIP9-style miner signaling: over each 2016-block window, miners can set a bit in their block versions to signal readiness. If 90% signal within the window, the fork locks in and activates at the minimum activation height.

The out-of-Core dimension is the load-bearing part of the plan. Because Core has not merged the activation logic, the signaling and activation code would ship in an **alternative client** — a Bitcoin implementation that follows all existing consensus rules but adds CTV+CSFS as a new rule at the minimum activation height, provided the miner signaling threshold has been met. Nodes running Core would remain valid so long as no CTV transaction is mined. If CTV activates and Core nodes reject a CTV-committing block, a chain split occurs.

## Governance stakes: what an out-of-Core activation would signal

*[Figure: img5]*

Bitcoin's consensus process has no formal governance body. In practice, the norm has been that Bitcoin Core's maintainers hold a soft veto: changes that Core will not merge do not activate. The SegWit UASF of 2017 was the last serious challenge to that norm, and even it ultimately routed through Core's codebase; the UASF client (BIP148) was a fork of Core with modified activation logic, and SegWit was already in Core by the time the UASF pressure peaked.

An out-of-Core activation for CTV+CSFS would be a stronger challenge to the Core-veto norm than SegWit UASF was. The alternative client would carry activation code that Core maintainers have explicitly declined to adopt. If miners signal above 90% and the fork activates, either Core would need to merge CTV+CSFS to keep its users on the majority chain — which would establish a precedent that a sufficiently coordinated developer coalition plus miner supermajority can force Core's hand — or Core would need to explicitly reject the fork and accept a chain split, which is a much larger break with the assumption that Bitcoin has a single canonical implementation.

There is a legitimate argument that this is healthy. Bitcoin's upgrade process being effectively frozen since 2021 is not a design outcome anyone chose; it is an equilibrium that emerged from the difficulty of coordinating consensus changes without formal governance. Forcing the question — either activate or explicitly reject — produces information that a permanent stalemate does not.

There is also a legitimate argument that this is dangerous. The 90% miner signaling threshold is a floor, not a proof of user consent. Taproot's activation had far broader visible support across users, businesses, and developers than CTV currently does. A soft fork that activates on a bare miner supermajority against Core objection could set a precedent that is exploitable by future coalitions with narrower aims — and covenants are exactly the class of change where the space of "narrower aims" is large.

Neither argument is decisive on its own. The empirical question is whether the developer coalition behind the letter can produce enough surrounding infrastructure — economic node support, wallet integration commitments, exchange readiness — to make the 90% miner signal look like ratification rather than a captured signal. As of the sources we reviewed, that surrounding infrastructure was still being assembled.

## Remaining objections

We would be dishonest to imply the technical objections have been resolved. Three are worth naming even without full sourcing.

The first is the **TxWithhold** concern, explored by Gleb Naumenko in a BitMEX article referenced in the Delving Bitcoin thread. Covenants can be used to construct scripts that pay miners to withhold specific transactions from blocks. The severity depends on how easy such constructions become and how tolerant the fee market is; the concern is not that covenants introduce transaction withholding, but that they may make it substantially cheaper to bribe for. This has not, to our knowledge, been formally analyzed in the specific CTV+CSFS context in a way that resolves the debate.

The second is the **complexity budget** critique. Every new opcode expands the surface area of consensus code and creates new interactions with existing script primitives. Bitcoin's development culture treats this expansion as costly by default. The CTV+CSFS package is narrow, but it is not free, and the reviewer-hours required to audit interactions with Taproot, sighash flags, and future proposals are non-trivial.

The third is the **first-step problem**. If CTV+CSFS activates, does that make the OP_CAT debate easier or harder? Proponents argue easier: the community will have proved it can ship a soft fork, and the design space beyond CTV can be evaluated on its own merits. Skeptics argue harder: activation of a narrow covenant will consume the political capital that would otherwise be available for a more ambitious proposal, and Bitcoin will be left with a partial covenant that is inadequate for the constructions OP_CAT would have enabled. Both are plausible. The historical evidence is thin because Bitcoin has not shipped an upgrade since 2021.

## Implications for BTCFi

For BTCFi builders, the practical question is how to plan capital and roadmap allocation against the uncertainty. Three orientations seem defensible.

The first is to build against the current script set. BitVM2 in production on Citrea shows that meaningful trust-minimization is achievable without any new opcode, at the cost of substantially higher onchain footprint. Teams that need to ship in 2026\~2027 cannot condition their roadmap on activation.

The second is to build against CTV+CSFS as a soft target. Vault products, channel-factory-based venues, and DLC-heavy applications benefit disproportionately from activation, and their designs can be structured so that a covenant-aware version is a clean upgrade from a presigned-transaction version. The downside is that the presigned-transaction version remains fragile, and users bear that fragility until activation.

The third is to build against the deeper OP_CAT design space, on the assumption that once one covenant activates the second becomes politically easier. This is a longer bet. It also depends on a chain of counterfactuals — CTV activation, subsequent OP_CAT debate, activation of OP_CAT itself — each of which is contingent.

The open questions we would watch through the rest of 2026 and into 2027 are narrow and answerable. Does the alternative client ship, and does Core respond with its own signaling logic or with explicit rejection? What is miner signaling behavior in the first 2016-block window after the March 2026 start? Do the specific technical objections from Core contributors get published in a form that can be evaluated, or does the debate remain diffuse? And does the surrounding coalition — wallets, exchanges, custodians — publicly commit before the signaling window opens, or after?

If the answer to those questions is "the alternative client ships, miners signal above 90%, and Core merges the change in response," Bitcoin will have discovered a new upgrade path, and BTCFi will have a substantially different design space to build against within eighteen months. If the answer is "the client ships, signaling fails, and the debate resets," we will have confirmed that Bitcoin's upgrade process is not merely conservative but structurally blocked, and BTCFi's roadmap will need to assume script stasis for the foreseeable future. Both outcomes are informative. The one that would be worst is the third: the client ships, miners signal, and the resulting chain split reveals that Bitcoin's governance was less coherent than any faction assumed. That outcome is not the most likely, but it is the one that most rewards paying attention to now.