Should Bitcoin Stop Changing? The Ossification Debate and the Future of Protocol Upgrades

Bitcoin has not had a consensus change since Taproot activated in November 2021. That gap, now approaching five years, is the longest in the protocol's history. For some, this is exactly how it should be: a monetary system gaining credibility through stability. For others, it represents a closing window for upgrades that could unlock vastly more capable Layer 2 protocols and fix known vulnerabilities at the base layer.

This tension has a name: ossification. The term describes the gradual hardening of Bitcoin's consensus rules into a state that becomes practically impossible to change. Whether ossification is a feature or a failure depends on who you ask, and the answer has real consequences for every project building on Bitcoin.

What Ossification Means

In engineering, ossification occurs when a protocol becomes so widely deployed that any change risks breaking existing implementations. The Internet Protocol (IP) is a classic example: IPv6 was finalized in 1998, yet IPv4 still carries the majority of internet traffic nearly three decades later because the cost of migrating is enormous.

Bitcoin's version of this dynamic is both technical and social. At the technical level, every consensus change requires coordination across thousands of full nodes, mining pools, exchanges, wallets, and Layer 2 protocols. At the social level, Bitcoin lacks a formal governance body: changes happen only when the community reaches rough consensus, a deliberately high bar.

The Lindy effect is central to the ossification thesis. Every year that Bitcoin's rules remain unchanged increases confidence that they will continue to hold. Proponents argue that this predictability is not a limitation: it is the core value proposition of sound money.

A Timeline of Bitcoin Soft Forks

Bitcoin has undergone seven major soft forks since its launch. The pace of changes has slowed dramatically over time, with the gaps between upgrades growing wider as the stakes of each change increase. For a deeper look at each upgrade, see our complete history of Bitcoin soft fork activations.

The pattern is clear: from 2012 to 2017, Bitcoin averaged roughly one soft fork per year. Then came a four-year gap before Taproot. As of September 2026, the protocol has gone nearly five years without a consensus change. The bar for the next upgrade has never been higher.

The Case for Ossification

The ossification camp includes prominent developers, educators, and investors who argue that Bitcoin's current rule set is sufficient for its primary role as a store of value and settlement layer. Their arguments cluster around several themes.

Stability as a Feature

Money works best when its properties are predictable. Gold does not receive feature updates: its value derives precisely from its resistance to change. Bitcoin developer and author Jimmy Song has argued that "money is better when it's not changing" and that the base layer must remain stable for the layers built on top of it to mature.

Every consensus change, no matter how well-intentioned, introduces new attack surface. The SegWit upgrade introduced the witness discount, which enabled Ordinals inscriptions years later: an outcome its designers did not anticipate. Ossification advocates point to examples like this as evidence that even carefully reviewed changes produce unforeseeable consequences.

The Security Argument

Bitcoin secures hundreds of billions of dollars in value. Each soft fork creates a brief period where the network operates under split rules while nodes upgrade. A bug in consensus code is catastrophic in ways that bugs in application software are not: it can cause chain splits, double spends, or inflation. The CVE-2018-17144 vulnerability (which could have allowed unlimited Bitcoin creation) demonstrated how a single consensus bug can threaten the entire system.

L2 Innovation Without L1 Changes

Ossification proponents argue that meaningful scaling and functionality are achievable without touching consensus rules. The Lightning Network, built on SegWit, already handles millions of payments. Federated protocols like Fedimint and Cashu provide privacy and scalability using existing Script. Statechain-based protocols like Spark demonstrate that instant, self-custodial transfers are possible within current consensus rules.

The Case Against Ossification

The counter-argument comes primarily from protocol developers, L2 builders, and researchers who see specific technical limitations that only consensus changes can resolve. Their concern is not abstract: without new opcodes, certain categories of functionality remain fundamentally out of reach.

Covenants and What They Unlock

Covenants are spending conditions that restrict how future transactions can use a given output. Today, Bitcoin Script can verify who is spending (via signatures) and when they can spend (via timelocks), but it cannot enforce conditions on where funds go next. This limitation has concrete consequences.

• Vaults with clawback mechanisms require pre-signed transactions and secure key deletion: a fragile construction compared to what opcodes like OP_VAULT would enable natively
• Trustless, non-interactive rollup withdrawals are impossible without the ability to commit to transaction templates
• Channel factories and advanced payment channel designs need covenant primitives to scale beyond current Lightning Network limits
• Eltoo (LN-Symmetry), which would simplify Lightning state management and eliminate toxic close scenarios, requires SIGHASH_ANYPREVOUT

The core argument: Bitcoin's Script limitations force L2 protocols into trust assumptions or UX compromises that a small set of well-scoped opcodes could eliminate. For a detailed analysis of the leading proposals, see our coverage of the covenant activation path forward.

The Security Budget Problem

As block subsidies continue to halve, Bitcoin must eventually rely entirely on transaction fees to fund its security budget. If the base layer cannot support sufficiently rich L2 constructions, fewer transactions may settle on-chain, potentially weakening the incentives that keep miners honest. Anti-ossification voices argue that enabling more expressive L2s increases on-chain demand through channel opens, closes, and settlement transactions.

Post-Quantum Preparedness

Quantum computing represents an existential threat to Bitcoin's elliptic curve cryptography. While practical quantum attacks remain years away, migrating to post-quantum signature schemes will require consensus changes. A fully ossified protocol cannot adapt to this threat. Proposals like P2QRH (Pay-to-Quantum-Resistant-Hash) highlight that the question is not whether to upgrade, but when.

The quantum paradox: If Bitcoin ossifies before deploying quantum-resistant signatures, it may face a forced hard fork later under emergency conditions: the worst possible way to coordinate a protocol change. Proactive soft forks are safer than reactive hard forks.

The Current Proposal Landscape

Several concrete proposals are competing for community attention as the next potential soft fork. Their status as of September 2026 reveals the difficulty of advancing any consensus change in the current environment.

In June 2026, 66 Bitcoin application and protocol developers signed an open letter urging adoption of CTV and CSFS, citing "significant benefits that these changes would bring to end-users of bitcoin." Despite this organized support, miner signaling for CTV remains at zero percent nearly six months into its activation window, which runs until March 2027.

Political Dynamics and Activation Disputes

The technical merits of any proposal are only half the challenge. Soft fork activation in Bitcoin requires navigating a political landscape shaped by historical trauma: the blocksize war of 2015 to 2017 left deep scars on the community, and the memory of that conflict makes every subsequent upgrade proposal harder to advance.

SegWit and Taproot as Precedent

SegWit's activation in August 2017 required a user-activated soft fork (UASF) campaign that pressured miners into signaling support. The episode demonstrated that users, not miners, hold ultimate governance power in Bitcoin. But it was also deeply contentious, with credible risks of a chain split throughout.

Taproot, by contrast, used a Speedy Trial mechanism that gave miners a short window to signal 90% support. The upgrade itself had near-universal backing, which made Speedy Trial work. The lesson: activation methods that succeed for uncontroversial upgrades may fail for anything divisive.

The BIP-110 Episode

The most recent activation attempt provides a stark illustration of the difficulty. BIP-110, a proposal to temporarily restrict arbitrary data in Bitcoin transactions (targeting inscriptions and OP_RETURN data), attempted to activate via a miner-signaled soft fork in August 2026. The result: the breakaway chain mined just two blocks before stalling, garnering only 2.53% of hashrate support while the main chain continued uninterrupted.

Within 15 hours, the main chain was 90 blocks ahead. The episode demonstrated both Bitcoin's resistance to contested changes and the danger of attempting activation without broad consensus. It has become a cautionary reference point for every proposal that follows.

Activation paradox: The safer a soft fork is, the easier it is to activate: BIP-54 (Great Consensus Cleanup) faces less opposition because it fixes bugs without adding features. Covenant proposals are harder precisely because they expand what Bitcoin can do, which means they expand what can go wrong.

Developer Fatigue

Bitcoin Core development relies on a small number of contributors, many of whom are funded by grants rather than salaries. Covenant proposals have been debated since at least 2019, and the cycle of proposal, review, debate, and stalemate takes a toll. CTV was first proposed in 2020, and six years later has yet to activate. Some researchers have described a "soft fork exhaustion" phenomenon: the community's collective energy for debating consensus changes may itself be a finite resource.

The challenge is compounded by competing proposals. CTV, OP_CAT, APO, and LNHANCE each have overlapping but distinct capabilities. Advocates for each approach struggle to build consensus when the community must choose among alternatives, and the act of choosing creates political friction independent of the technical merits.

Alternative Paths: Working Without Consensus Changes

The practical reality of ossification: whether chosen or not, has driven innovation in designs that work within Bitcoin's current rules. These approaches accept Script's limitations and find creative workarounds.

BitVM

BitVM, introduced by Robin Linus in 2023, enables Turing-complete computation verification on Bitcoin without any consensus changes. The design uses fraud proofs: a prover makes a claim about the result of a computation, and any verifier can challenge it on-chain. The latest iteration, BitVM3 (announced in December 2025), uses garbled circuits to make dispute resolution roughly 1,000x cheaper than BitVM2.

BitVM operates under a 1-of-N trust assumption: only one honest participant is needed to prevent fraud. This is weaker than the fully trustless guarantees that covenants could provide, but it is sufficient for bridge designs where at least one verifier can be assumed honest. BitVM bridges are already being developed to connect Bitcoin to L2 networks.

Statechain Protocols

Statechains enable off-chain Bitcoin transfers by rotating signing authority rather than creating on-chain transactions. The approach works entirely within existing consensus rules, using pre-signed transactions and cooperative signing. Spark is the most prominent implementation, combining statechains with FROST threshold signatures and a leaf architecture that supports partial transfers and token issuance.

The statechain approach trades full trustlessness for instant settlement and zero channel management. Users maintain self-custody and can always exit to L1 unilaterally. The tradeoff: trust that at least one of the signing operators deletes old key material after each transfer (a 1-of-N honesty assumption).

Federated Models

Federated systems like Fedimint and the Liquid Network use multisig federations to custody funds and process transactions off-chain. These designs accept a higher trust assumption (trust a threshold of federation members) in exchange for functionality that would otherwise require consensus changes: confidential transactions, faster block times, and arbitrary programmability.

What Covenants Would Change for L2s

Even the most capable non-covenant designs hit fundamental limits that new opcodes could resolve. The following table compares what is possible today against what covenants would unlock.

Key distinction: Protocols like Spark and BitVM demonstrate that practical scaling is achievable today. Covenants would not replace these systems: they would strengthen their trust models, moving them from 1-of-N honesty assumptions toward fully trustless designs.

The Middle Path: Staged Ossification

A growing number of voices advocate for a middle position: activate a small, well-scoped set of covenant opcodes, then ossify. The logic is that Bitcoin needs one more round of upgrades to provide the primitives that L2 protocols require for full trustlessness, after which the base layer can safely harden.

CTV + CSFS has emerged as the frontrunner combination for this approach. CTV provides transaction template commitment (enabling vaults and congestion control), while CSFS enables signature verification against arbitrary messages (enabling more expressive spending conditions). Together, they form a minimal but powerful covenant toolkit without introducing the broad expressiveness (and broader risk surface) of OP_CAT.

The Great Consensus Cleanup (BIP-54) represents a parallel track that even some ossification advocates support: it fixes known bugs without adding new functionality. Mining pools representing roughly 15% of hashrate were already producing compatible blocks by mid-2026, though opposition from major pools like F2Pool has complicated the path to the 90% signaling threshold required for activation.

What This Means for Bitcoin Builders

The ossification debate is not merely philosophical. It has practical implications for anyone building applications, wallets, or infrastructure on Bitcoin today.

• If you are building an L2 protocol, design for current consensus rules first: there is no guaranteed timeline for any soft fork
• If you need vault-like custody, pre-signed transaction approaches work today but require careful key management
• If you are building bridges, BitVM provides a path to minimized trust without waiting for consensus changes
• If you need instant self-custodial transfers, statechain-based designs like Spark are production-ready now

The Spark protocol is an instructive example of this pragmatic approach. By building on statechains and FROST within existing consensus rules, Spark delivers instant transfers, stablecoin support via USDB, and native Lightning compatibility: all without requiring any soft fork. If covenants do activate in the future, they could further strengthen Spark's trust model, but the protocol does not depend on them. Developers can explore the Spark SDK and documentation to start building today, and users can experience the protocol through wallets like General Bread.

Conclusion

The ossification debate is ultimately about risk tolerance and time horizons. Ossification advocates prioritize the certainty of what works today: Bitcoin as stable, predictable, and resistant to capture. Upgrade advocates prioritize the capabilities that Bitcoin will need tomorrow: trustless L2s, quantum resistance, and a sustainable security budget.

Neither side is entirely wrong. Bitcoin's value does come from its resistance to change, and every consensus modification is a genuine risk. But a protocol that cannot adapt to existential threats (quantum computing) or enable its own scaling layer (covenants for L2s) may ossify into irrelevance rather than resilience.

The most likely outcome is not a binary. BIP-54 may activate as a bug-fix-only upgrade with broad support. Covenant proposals will continue to be debated, tested on signet, and refined. And the ecosystem will keep building within current rules, as Spark, BitVM, and federated protocols demonstrate that meaningful progress does not require waiting for permission from the base layer.

The question is not really whether Bitcoin should stop changing. The question is whether the changes that remain can achieve the consensus they need before the window closes.

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.