Bitcoin’s 2026 Covenant Race: CTV, CSFS and Taproot

Bitcoin traded near $85,700 on the morning of September 22, up more than 5 percent in a day and back above a level it had not held since late January, with a market capitalization once again over $1.7 trillion, according to CoinGecko market data. The rally pulled headlines back to the price chart. Yet the more consequential Bitcoin story of the autumn is not the candle; it is a quiet fight over a handful of new instructions that would let Taproot do things it still cannot do today.

Taproot activated on November 14, 2021, and almost five years later it remains the last consensus change Bitcoin has managed to ship (CoinDesk). The upgrade delivered Schnorr signatures, a cleaner scripting format called Tapscript, and a spend design that hides unused conditions inside a Merkle tree. What it did not deliver was covenants: rules that let a coin restrict how it may be spent next. In 2026 that missing capability has become the center of Bitcoin’s technical debate, and the leading answer now has a name developers repeat like a slogan: CTV plus CSFS.

This is a field guide to that race. It covers what a covenant is, why the whole fight lives inside Taproot’s script path, the two front-running opcodes (BIP-119 and BIP-348), the Taproot-native challenger that surfaced in March (BIP-446 and BIP-448), the maximalist option nobody can agree on (OP_CAT), and the obstacle that August’s fork fiasco laid bare: Bitcoin still has no dependable way to say yes.

What a covenant actually is

A covenant is a spending condition that constrains the next transaction, not merely who is allowed to sign this one. Plain Bitcoin script answers a single question: who may spend these coins? It checks a signature and moves on. A covenant adds a second question: where may these coins go? To answer it, the script must inspect properties of the spending transaction, such as its outputs, amounts and structure. Bitcoin was deliberately built without that ability, both to keep validation simple and to avoid coins that carry restrictions around with them.

The reason developers want to relax that limit is that a surprising amount of useful engineering depends on it. A vault can force any withdrawal through a mandatory time delay, so a thief who steals your signing key still cannot move the coins immediately. A congestion-control tree can commit to a batch of future payments and settle them later when fees fall. Payment pools let many users share a single on-chain output. Off-chain systems such as Ark and a cleaner version of Lightning need covenants to shed the constant coordination they require today.

The fault line running through every proposal is recursion. A non-recursive covenant constrains the next hop and then lets go. A recursive covenant can force the same rule onto the coin’s children, and their children, indefinitely. Recursion is powerful, and it is also exactly what worries many contributors, because coins that stay permanently restricted raise questions about fungibility and censorship. Covenants are not smart contracts in the Ethereum sense, where programmable spending is baked into the account itself; Bitcoin has chosen instead to weigh narrow, auditable opcodes one at a time, a different philosophy from the account model explored in our coverage of EIP-7702 and smart accounts.

Why the fight lives inside Taproot’s script path

Taproot (BIP-341) gave every modern Bitcoin output two ways to spend. The key path is a single Schnorr signature: cheap, private, and indistinguishable from any other Taproot spend. The script path reveals one leaf of a Merkle tree of scripts, exposing only the condition actually used. Tapscript (BIP-342) is the language for that script path, and it did something forward-looking: it reserved a large block of opcodes called OP_SUCCESSx. An OP_SUCCESSx opcode makes a script succeed immediately today, which sounds pointless until you see the purpose. It is a clean hook for future soft forks. Assign one of those reserved numbers real rules, and older nodes still accept the transaction while upgraded nodes enforce the new logic.

That is why the covenant proposals are, at the byte level, a contest over which reserved opcodes get meaning. CSFS would give semantics to OP_SUCCESS204. The rival BIP-448 bundle claims OP_SUCCESS203, 204 and 206 for its three operations (bips.dev). CTV is the exception that proves the rule: it reuses an older no-op, OP_NOP4, so it can function even outside Taproot, though in practice it would live in the Tapscript path too (covenant toolkit).

Taproot even makes the security model of covenant vaults cleaner. Developers are now standardizing how to build a Taproot output with no usable key path at all, so a coin can only be spent through its script, meaning through its covenant. Bitcoin Optech’s September 18 newsletter describes a draft that uses a Nothing Up My Sleeve point, a public key whose private key is provably unknown, as the internal key, derived so that any wallet reproduces the identical address (Optech #423). For a vault that is precisely the point: there should be no signing shortcut around the rules. The blunt summary is that without Taproot there is no tidy home for covenants. The 2021 upgrade wired the socket; 2026 is the argument over which plug to use.

CTV (BIP-119), the most reviewed proposal

OP_CHECKTEMPLATEVERIFY, proposed by Jeremy Rubin more than five years ago, is the most mature covenant design in the ecosystem (Bitcoin Magazine). Its mechanism is narrow by design. An output commits to a 32-byte hash of the exact transaction permitted to spend it. That hash covers the transaction version, the locktime, the number and sequences of the inputs, the number of outputs, a hash of the outputs, and the index of the input being spent (bips.dev). Try to spend with anything that does not match, and the script fails on the spot.

Because the template pins the outputs, CTV cannot easily be twisted into forcing a rule to propagate forever, which is the whole selling point: it is bounded and predictable. The canonical use cases follow directly. Congestion control lets a wallet or exchange pre-commit a tree of payouts and settle them later, with each recipient free to accelerate their own branch using child-pays-for-parent fees. Simple vaults add an unvault step and a time delay, plus a clawback path to a recovery key if something looks wrong. Non-interactive payment channels and timeout trees round out the list.

A concrete vault shows why this matters. You send coins to an address that can only be spent by first broadcasting a pre-committed unvault transaction, which starts a timer of, say, one day. During that day the funds sit visibly in limbo. If the withdrawal is legitimate, you wait out the delay and the coins move on to their destination. If an attacker who has stolen your key triggers the unvault, you see it happen and use a separate recovery key to sweep the coins somewhere safe before the timer expires. The thief holds your signing key and still cannot outrun the clock.

CTV reuses OP_NOP4, so old software treats it as a harmless no-op, which keeps activation soft-fork safe. For everyday holders, the most relevant promise is the vault: self-custody that can survive a stolen key. It is the Bitcoin-native cousin of the recovery and inheritance tooling now spreading through smart-account wallets, except enforced by consensus rather than by a wallet vendor.

CSFS (BIP-348), the other half

OP_CHECKSIGFROMSTACK was co-formalized by Brandon Black and Jeremy Rubin in late 2024 (CoinDesk). Where the ordinary OP_CHECKSIG can only verify a signature against the current transaction, CSFS takes a public key, a message and a signature off the stack and verifies the signature against that arbitrary message using Schnorr (Spark). In other words, it lets a script confirm that a key approved some piece of data, whatever that data happens to be.

That unlocks a different family of tools than CTV. Delegation becomes possible, where a key authorizes a specific instruction without handing over full control. Oracle attestations can be verified on-chain, which matters for Discreet Log Contracts and prediction-style products. And CSFS enables simpler Point Time Locked Contracts, or PTLCs, which can replace Lightning’s hash-based HTLCs with better privacy and fewer failure modes.

The most important trick emerges when the two opcodes are combined. Developers have shown that CTV and CSFS together can emulate ANYPREVOUT, the long-requested feature behind LN-Symmetry (formerly called eltoo), a way to update Lightning channels without the punitive, error-prone penalty transactions in use today (covenant toolkit). That is the crux of why the two are proposed as a pair. CTV answers the question, “is this the right transaction?” CSFS answers a different one, “did this key sign this data?” Between them they cover most of what builders have been asking for.

How the debate got here

None of this is new. Jeremy Rubin published CTV around 2019, and by early 2022 it had come close to a formal activation attempt before the effort was shelved amid sharp disagreement over process and whether the demand was proven. The same years produced a scatter of rival ideas, including Christian Decker’s ANYPREVOUT for Lightning, OP_CAT revival proposals, and several vault-specific opcodes, none of which converged. The lesson developers drew from that period was that Bitcoin will not activate a covenant that arrives alone and contested; it needs a design with obvious use cases, thorough review, and visible demand from the people who would build on it.

The revival that followed was deliberate. Over 2023 and 2024, contributors narrowed the field toward the smallest set of opcodes that could serve the most requested applications, and Brandon Black’s work with Rubin to formalize CSFS in late 2024 supplied the missing piece for Lightning symmetry and oracle-based contracts (CoinDesk). By the spring of 2025, CTV and CSFS together had become the proposal that the widest span of the technical community could live with, which is what the June letter was built to demonstrate. The 2026 arrival of the Taproot-native BIP-446 and BIP-448 is, in a way, that same convergence process running one more lap.

The frontrunner is CTV plus CSFS

The combination, sometimes bundled with a third helper opcode and marketed as LNHANCE, has become the clear developer favorite (Spark). It occupies the middle ground: enough expressive power to build vaults, better Lightning and non-interactive Ark, without the unbounded recursion that makes reviewers nervous. Neither the most conservative option nor the most aggressive, which is exactly why it leads.

The clearest signal of that consensus was an open letter published at ctv-csfs.com on June 9, 2025, signed by 66 Bitcoin application and protocol developers at launch, a list that has since grown past 80. It asks Bitcoin Core contributors to prioritize the review and integration of CTV and CSFS within six months, so that both activation planning and final scrutiny can proceed. Its central claim is blunt: “CTV and CSFS are uniquely well reviewed, simple, and have been proven to be both safe and widely demanded.”

The signatories read like a cross-section of Bitcoin engineering: Casa co-founder Jameson Lopp, Blockstream cryptographer Andrew Poelstra, vault researcher James O’Beirne, Lightning and eltoo pioneer Christian Decker, and BitVM inventor Robin Linus, alongside contributors from firms such as Anchorage, Luxor and Alpen Labs (ctv-csfs.com). That breadth is unusual, and it is the strongest evidence yet that the debate has narrowed to how, not whether. The LNHANCE variant simply adds OP_INTERNALKEY, which copies the Taproot internal key onto the stack to shrink certain scripts.

The Taproot-native challenger: BIP-446 and BIP-448

In March 2026 the neat CTV-plus-CSFS story gained a complication. Greg Sanders, Antoine Poinsot and Steven Roose published a rival design: BIP-446 (OP_TEMPLATEHASH) and BIP-448, titled Taproot-native (Re)bindable Transactions, both entering Draft status and created on March 11, 2026 (bips.dev). It is not a rejection of the frontrunner’s goals so much as a cleaner attempt at them.

BIP-448 packages three operations. OP_TEMPLATEHASH, defined in BIP-446, is a Taproot-native reimagining of CTV that commits to the spending transaction’s structure with tidier semantics and claims OP_SUCCESS206. CSFS provides the signature-over-data check on OP_SUCCESS204. OP_INTERNALKEY, on OP_SUCCESS203, pushes the Taproot internal key onto the stack to optimize the rebindable-signature designs. The bundle only ever extends Tapscript, never legacy script, and it reuses Taproot’s existing signature-hashing machinery rather than inventing a new commitment format, which is what earns it the Taproot-native label (bips.dev).

The target is rebindable transactions, the most direct route to LN-Symmetry without ANYPREVOUT’s rough edges, plus vaults and reduced interactivity in channel designs (Bitcoin Index). Its authors pitch OP_TEMPLATEHASH as a drop-in replacement for CTV. There is a meaningful catch: comparisons note that BIP-448’s design lacks BitVM compatibility, which matters to the teams building BitVM bridges and Bitcoin rollups (Spark). The choice, in other words, is not purely about elegance; it is about which downstream ecosystem you optimize for. A credible, well-authored alternative is double-edged: it sharpens the engineering, and it also fractures attention at the exact moment the CTV camp was trying to consolidate it.

OP_CAT and the recursive fault line

At the far end of the spectrum sits OP_CAT (BIP-347), from Ethan Heilman and Armin Sabouri. It does something almost comically simple: it concatenates the top two items on the stack, subject to a 520-byte limit, an operation Satoshi disabled back in 2010 (Spark). Restored and combined with Schnorr signature tricks, concatenation is enough to emulate broad covenants, including recursive ones.

That expressive power is both the attraction and the problem. OP_CAT would supercharge BitVM and enable rich contract logic that the narrower opcodes cannot. It would also make it possible to build coins whose spending rules follow them forever, which is the specific outcome many contributors want to avoid, on fungibility and censorship grounds. The specification reached Complete status in 2026 and has tens of thousands of test transactions on experimental signets, but it has no agreed activation path (Spark).

Not everyone treats recursion as a bogeyman. Blockstream cryptographer Andrew Poelstra, himself a signatory to the CTV-plus-CSFS letter, has publicly pushed back on the idea that Bitcoin should freeze in place, arguing that developers need to argue passionately and correctly for beneficial changes and expressing sympathy for OP_CAT’s flexibility (Bitcoin Magazine). Even so, the CTV-plus-CSFS pitch is partly a reaction to OP_CAT: hand builders most of what they need through bounded, auditable opcodes now, and leave the recursive frontier for a later, more careful debate.

What builders would actually ship

The demand behind all of this is concrete, not theoretical. Real teams have designs sitting on the shelf waiting for an opcode.

• Vaults. James O’Beirne’s vault work and the broader time-delay custody model need CTV-style templating so that even a leaked signing key cannot move funds past a mandatory delay and a clawback path.
• Ark. The shared-UTXO scaling protocol needs CTV to make its rounds non-interactive; without a covenant, operators must front liquidity and coordinate every participant on every round.
• Lightning. LN-Symmetry replaces punitive channel closes with clean state updates, and PTLCs replace HTLCs for better privacy and smoother cross-protocol swaps.
• Payment pools. Many users share one on-chain UTXO and rebalance off-chain, cutting fees and shrinking their on-chain footprint.
• BitVM and rollups. OP_CAT would slash the cost of the giant verification scripts that BitVM bridges and Citrea-style rollups depend on, which is exactly where BIP-448’s missing BitVM support stings.

Ark is the clearest case of a project bending itself around a missing opcode. Its shared-UTXO rounds work today only through elaborate multiparty pre-signing, and operators must lock up real liquidity to keep them running. Teams building on the model, including Second (whose co-founder Steven Roose is also a co-author of BIP-448), which put its Bark implementation on mainnet in June 2026, and Ark Labs, which raised a Tether-led seed round in March 2026, have been explicit that a covenant would let them shed those workarounds. CTV would turn an interactive, capital-hungry protocol into a far lighter one.

This is the same layer-two ambition powering much of Bitcoin’s 2026 roadmap, from the staking economy around Babylon to the trust-minimized bridges that keep trying to move value off the base chain. Covenants would let several of these designs drop their workarounds and lean on consensus instead. The table below maps the main use cases to the opcodes that unlock them.

The obstacle BIP-110 exposed

Here is the twist that makes 2026 interesting: developers largely agree on what they want to build. The hard part is turning agreement into an activated rule, and August showed just how hard that has become. BIP-110, a temporary data-limiting soft fork with a low bar, opened its signaling window on August 8 at block 961,632 and drew only about 2.5 percent miner support against a 55 percent threshold (CoinDesk). A tiny minority chain split off, mined two blocks, then stalled while holding roughly 0.15 percent of hashpower as the main chain rolled on. It was a controlled demolition of the notion that a determined minority can force a change on everyone else.

The contrast with Taproot’s own activation is stark. Taproot used a mechanism called Speedy Trial, a short signaling window with a 90 percent miner threshold; it locked in at block 687,284 in June 2021 and activated that November precisely because almost everyone already agreed (CoinDesk). Bitcoin’s earlier upgrades were rarely so smooth; the SegWit fight in 2017 needed the threat of a user-activated soft fork to break a deadlock. The pattern across all of them is the same: signaling ratifies a consensus that already exists, it does not manufacture one.

Strategy executive chairman Michael Saylor read the outcome as vindication of the design, posting that “Bitcoin worked exactly as designed. BIP-110 was free to fork, and the network was free not to follow,” and adding that “consensus is earned, not declared” (Crypto Times). Blockstream chief executive Adam Back had been blunter beforehand, saying the proposal “doesn’t have tech nor ecosystem consensus” and that “this is not the way” (Bitcoin.com News).

Casa’s Jameson Lopp, who signed the CTV-plus-CSFS letter yet opposed BIP-110’s low threshold, framed the principle plainly: “Bitcoin is not a democracy whereby a simple majority can overwhelm the minority,” and real changes “need broad buy-in, not node-counting games” (blog.lopp.net). The lesson for covenants is sobering. Even the frontrunner needs something close to unanimity. CTV’s own activation client, running since March 30, 2026 with a demanding 90 percent Speedy Trial threshold, has drawn essentially zero miner signaling all year and is set to time out in March 2027 (Spark). Broad agreement among builders has simply not translated into mined signals, and miner signaling is where covenant activation and the older 51 percent question quietly meet.

The queue behind Taproot

Covenants do not have the waiting room to themselves. Consensus Cleanup (BIP-54), a bundle of four narrow fixes covering the timewarp bug, a cap on legacy signature operations that can make blocks slow to validate, a merkle-tree weakness that can fool light clients, and duplicate-transaction hardening, has a finalized specification from Chaincode Labs researcher Antoine Poinsot but no activation of its own (Bitcoin Optech).

Behind that sits the largest change anyone is seriously discussing: post-quantum migration, sketched across BIP-360 and BIP-361, which would eventually retire the elliptic-curve signatures Bitcoin uses today (bip360.org). Each of these competes for the same scarce resource, the community’s willingness to coordinate one careful soft fork. The uncomfortable arithmetic is that Bitcoin has activated roughly one consensus change every several years, and there are at least four credible candidates in line. Some of them, the quantum sunset in particular, arguably cannot wait indefinitely.

Covenants therefore sharpen the governance question rather than settle it. A network that can agree on the destination but not on the on-ramp is a network that ships nothing, and every month of delay strengthens the argument of those who believe Bitcoin has quietly ossified. The covenant camp’s implicit bet is that a proposal with this much documented support can break the logjam and re-establish that Bitcoin can still change.

Tooling is running ahead of consensus

One of the odder features of the moment is that the software is further along than the politics. Even without activation, the ecosystem is building as though covenants are inevitable. covenants.diy, a browser-based Tapscript editor, now lets anyone experiment with OP_CTV, OP_CSFS, OP_CAT, ANYPREVOUT, OP_TEMPLATEHASH and OP_INTERNALKEY on test networks (Optech #423). Bitcoin Inquisition, a signet that enables the proposals, has hosted years of experiments, with ANYPREVOUT live since late 2022 and OP_CAT accumulating tens of thousands of test transactions (Spark).

The wallet and infrastructure layers have shipped the Taproot pieces covenants build on, too: MuSig2 signing, Simple Taproot Channels in Lightning, and Miniscript support inside Tapscript. The September draft for provably unspendable internal keys is one more piece of plumbing that future vaults will use, ensuring a covenant output has no key-path escape hatch (Optech #423). The result is a strange inversion of Bitcoin’s usual caution: for once, the code is more ready than the community.

What it means for US holders and the SEC

For a reader in the United States, the regulatory picture is refreshingly short. No agency approves or blocks a Bitcoin soft fork. The Securities and Exchange Commission oversees securities, exchanges and custodians, not Bitcoin’s consensus rules, and a covenant activation is not something the SEC can permit or forbid. The base layer sits outside its remit.

The consequences are downstream. If a soft fork ever produced a contested chain split, as BIP-110 briefly did, spot-Bitcoin ETF issuers and custodians would have to decide which chain their product represents, and the tax treatment would follow the Internal Revenue Service’s long-standing position that forked or airdropped coins are ordinary income at the moment of receipt (IRS). Moving your own coins between your own address types, for instance into a future covenant vault, is not a taxable disposal; it is a transfer to yourself.

The near-term impact that actually matters is custody. Covenant vaults promise self-custody that can survive a stolen key, the Bitcoin-native answer to the recovery features spreading through consumer wallets, a theme we unpack in our smart-account field guide. For institutions weighing how to hold Bitcoin, an enforced withdrawal delay is a more meaningful development than any single day’s price move.

The road to a decision

The next real venue is TABConf in October, following the OPNEXT gathering in April and BTC++ in July, where contributors have been working through activation questions in person (CoinDesk). Some in the community think BIP-119 could see a decision by year-end, and have floated the possibility of Bitcoin’s first user-led soft fork in four years (PANews). Most sober timelines point to late 2026 or 2027.

Three rough scenarios capture the range. In the first, consolidation, the CTV-plus-CSFS camp folds the best of BIP-446 and BIP-448 into a single agreed package and a patient, high-threshold activation begins in 2027. In the second, stalemate, the CTV-versus-OP_TEMPLATEHASH and bounded-versus-recursive debates grind on, Bitcoin ships nothing again, and the ossification narrative hardens. In the third, shock, an external trigger such as a quantum milestone or a major custody failure that a vault would have prevented forces the whole queue to reorder.

For anyone tracking the race, a few signals will matter more than conference chatter. Watch whether the CTV and OP_TEMPLATEHASH camps merge their code or keep shipping competing patches; whether any major mining pool breaks the year-long silence and signals; and whether a flagship product, an Ark wallet or an institutional vault, launches on a signet in a way that turns abstract demand into a working demo. Activation follows rough consensus, and rough consensus tends to form around something people can already see running.

The honest read is that the engineering is nearly finished and the coordination is not. Bitcoin has just proven, with BIP-110, that it can reject a change it dislikes. It has not yet proven, almost five years after Taproot, that it can still accept one it wants. The covenant race is, at bottom, a test of whether Bitcoin’s caution has become a strength or a cage.

Frequently Asked Questions

What is a Bitcoin covenant?

A covenant is a spending rule that restricts how a coin can be spent next, not just who is allowed to sign. Ordinary Bitcoin script checks a signature; a covenant also constrains the destination or structure of the following transaction, which is what makes vaults, congestion control and better Lightning channels possible.

What are CTV and CSFS in Bitcoin?

CTV (OP_CHECKTEMPLATEVERIFY, BIP-119) lets an output commit to the exact transaction allowed to spend it. CSFS (OP_CHECKSIGFROMSTACK, BIP-348) verifies a signature against arbitrary data rather than the current transaction. Together they are the frontrunner combination for Bitcoin’s next soft fork.

Why do Bitcoin covenants need Taproot?

New opcodes live in Tapscript, the scripting language Taproot introduced in BIP-342, which reserved a set of OP_SUCCESS opcodes so future upgrades can be added by soft fork. Most covenant proposals, including the Taproot-native BIP-448, define their opcodes inside that Taproot script path.

When will Bitcoin activate a covenant soft fork?

There is no confirmed date. Developers favor CTV plus CSFS, and some expect a decision by late 2026 or 2027, but miner signaling for CTV’s activation client has been near zero all year, and Bitcoin has not activated any consensus change since Taproot in 2021.

Are Bitcoin covenants safe for regular holders?

The frontrunner proposals are non-recursive, meaning a covenant constrains only the next transaction and cannot lock coins away forever. The main safety debate is over recursive options such as OP_CAT. Regular holders are not affected unless they choose to use a covenant, for example to protect funds in a vault.

Marcus Okafor covers Bitcoin protocol development and layer-one infrastructure for HOGE Wire.