I run a Bitcoin node. I solo mine on solar power. I operate Lightning channels. And I’m a practicing litigator in California. A few weeks ago I almost activated BIP-110 on my Umbrel node — a consensus change that could have forked me off the network. I caught it because I knew the right questions to ask. Most node operators don’t.
That experience made something obvious. Bitcoin has no standards for evaluating consensus changes. Zero. The BIP process tells you how to format a proposal. It says nothing about whether the proposal is actually safe to run. There’s no minimum review period. No required code audits. No agreed-upon activation thresholds. No chain split risk assessment. Nothing.
So I wrote the standards.
What This Paper Is
Consensus Change Standards is a 28-page framework for evaluating Bitcoin consensus change proposals. It’s not a BIP. It doesn’t propose changes to Bitcoin’s code. It proposes standards for the process — how proposals should be reviewed, tested, and activated before anyone runs them on a production network that secures over a trillion dollars in value.
The paper includes a 20-point Consensus Change Readiness Checklist. Binary scoring — each criterion is either met or not met. No subjectivity, no politics, no ideology. Just standards.
For reference, BIP-110 scores about 4 out of 20. Taproot scores 19 to 20. That gap tells you everything about why Taproot activated smoothly and BIP-110 stalled at less than 3% of nodes.
The Problem
Bitcoin’s consensus rules are the most consequential code in the financial world. When you change those rules, you’re not pushing a software update. You’re potentially fracturing the monetary network. If a chain split happens without replay protection, transactions valid on one chain can be valid on the other. Users lose funds. Exchanges have to pick which chain to list. Contracts denominated in “Bitcoin” become legally ambiguous.
Despite those stakes, each consensus change proposal currently invents its own activation mechanism, sets its own threshold, defines its own timeline, and gets evaluated with no consistent framework. Some proposals get years of careful review. Others get pushed to activation in weeks. The difference is determined by personalities and politics, not by any institutional process.
BIP-110 is the case study for everything wrong with this approach. It proposed restricting arbitrary data in Bitcoin transactions — a goal reasonable people can debate. But the procedural failures were stacking:
55% activation threshold. SegWit required 95%. When that stalled, BIP-91 created a parallel path at 80%. Taproot used 90%. A 55% threshold means 45% of miners could be mining blocks that your node considers invalid. That’s not a soft fork. That’s a chain split waiting to happen.
Buggy activation client. The client was released as a fork of Bitcoin Knots in late 2025. Multiple developers reported significant bugs — the client couldn’t reliably fork the network and could have forked users off both chains. An activation client for a trillion-dollar network shipped with the code quality of a weekend project.
Two months of review. From initial proposal to release of the activation client — approximately two months. SegWit took twenty months from proposal to activation. Taproot took nearly four years. Two months is not a review period. It’s a rush to deployment.
No risk disclosure on distribution platforms. On at least one node management platform, the BIP-110 client appeared in the same dropdown as stable Knots releases. No warning label, no differentiation. If you understood version management but didn’t know the specific implications of BIP-110, you could have activated consensus-changing code thinking it was a routine update.
Untested sunset mechanism. BIP-110 does include an automatic expiry at a defined block height — that’s a meaningful improvement over proposals with no deactivation mechanism. But there’s no public evidence the sunset mechanism was tested on testnet. A sunset clause that hasn’t been tested is a promise, not a guarantee.
Historical Precedent
The paper walks through every major consensus change in Bitcoin’s history and extracts the lessons.
P2SH (2012) used a 55% activation threshold — the same one BIP-110 later adopted. The activation was messy. Miners signaled inconsistently and the community didn’t know which of two competing proposals (BIP-16 vs BIP-17) would win. Lesson: low thresholds create uncertainty even when the proposal has merit.
The Block Size Wars (2015-2017) consumed more community energy than any other event in Bitcoin’s history. Multiple competing proposals, the Bitcoin Cash hard fork, the near-miss of SegWit2x. The key lessons: miner signaling is unreliable as a measure of community consensus because pools signal for proposals their users don’t endorse. Economic nodes — exchanges, payment processors, businesses — determine which chain carries value, not miners. And hard forks are permanent and expensive. Bitcoin Cash still exists as a separate chain with a fraction of Bitcoin’s value.
SegWit (2017) was proposed in December 2015 and didn’t activate until August 2017. BIP-9 required 95% miner signaling, which stalled. The community developed BIP-148 — a User Activated Soft Fork that would have rejected non-SegWit blocks starting August 1, 2017, regardless of miners. That threat worked. BIP-91 locked in on July 21, 2017, forcing miners to signal, and SegWit locked in before the UASF deadline. Lesson: UASFs are a tool of last resort, not a standard activation mechanism. BIP-148 worked because SegWit had overwhelming community support and years of review. Applying the same mechanism to a proposal with weeks of review and marginal support — like BIP-110 — is reckless.
Taproot (2021) is the gold standard. Proposed in January 2018, it went through years of review, formal cryptographic analysis, multiple rounds of community feedback, and a novel activation mechanism (Speedy Trial) with a defined signaling window and built-in timeout. It activated in November 2021 at 90% miner signaling. No chain split. No community fracture. No economic disruption.
The pattern across all of these is clear. Successful consensus changes have high activation thresholds, long review periods, and broad community support. Failed or stalled proposals have low thresholds, rushed timelines, and narrow support. This isn’t coincidence. This is how governance works.
The Framework
The paper proposes concrete minimum standards across four areas.
Proposal requirements. Every consensus change proposal should include a clear problem statement supported by data, a complete technical specification, a backward compatibility analysis, a fully specified activation mechanism, a rollback procedure, and a reference implementation with tests. “Bitcoin should do one thing and do it well” is a philosophy, not a problem statement. “The UTXO set has grown by X% in Y months due to Z transaction type, imposing quantifiable costs of $W per node operator per year” is a problem statement.
Tiered review periods. Not all changes carry the same risk. Soft forks that add new validation rules without invalidating anything currently valid (like Taproot and SegWit) should get a minimum of twelve months of review. Soft forks that invalidate currently valid transactions or restrict existing functionality (like BIP-110) should get a minimum of twenty-four months. Hard forks should generally be avoided entirely.
Code audit standards. The activation client needs at minimum three independent developer reviews, comprehensive test coverage, at least three months of testnet deployment, fuzzing and adversarial testing, and disclosure of any AI-generated code. BIP-110’s client met none of these.
Activation thresholds. For miner-activated soft forks, the minimum threshold should be 90% — consistent with Taproot. Thresholds below 80% should be treated as presumptively dangerous. Thresholds below 60% are reckless and should be rejected regardless of the proposal’s merits. UASFs should be reserved for situations where a proposal has demonstrated overwhelming community support but miner signaling is blocked by a small number of pool operators acting against their users’ interests.
Sunset clause requirements. Any proposal that calls itself “temporary” needs a self-executing sunset clause — automatic expiry at a defined block height, no human intervention required. The sunset mechanism must be tested on testnet before mainnet deployment.
Legal Analysis
This is the part of the paper that nobody else has written. I’m a practicing attorney, so I can walk through the legal exposure that reckless consensus changes create in a way that developers and node operators should understand.
Negligence. If you release a buggy activation client, promote its adoption, and a user suffers financial loss because of it — say, mining blocks on a minority chain that get orphaned — you could face a negligence claim. A developer who follows rigorous standards has a strong defense. A developer who ships buggy code with a low activation threshold and no review period does not. Open-source licenses don’t categorically eliminate tort liability, especially when the developer is actively encouraging adoption.
Tortious interference. A reckless activation that causes a chain split can interfere with existing contracts. If a business contract says “payment in Bitcoin” and a chain split creates ambiguity about which chain is Bitcoin, the resulting dispute was caused by the split. The question of which chain is “Bitcoin” has no settled legal answer. During the Bitcoin Cash fork, exchanges generally treated the chain with the most accumulated proof of work as Bitcoin — but that convention is informal and could be challenged.
Fiduciary duties. The Tulip Trading case in the UK Court of Appeal considered whether Bitcoin developers owe fiduciary duties to Bitcoin holders. The court found there was a serious issue to be tried — it didn’t rule that the duty exists, but it didn’t dismiss the argument either. Whether or not you believe developers are fiduciaries, the standard of care exercised in a consensus change process will be evaluated if anything goes wrong.
Mining pool operator liability. Pool operators who signal for a consensus change on behalf of their users bear responsibility for the consequences. A solo miner assumes their own risk. A pool operator signaling for a poorly reviewed proposal with a low activation threshold is taking risks with other people’s hashrate — and other people’s money.
Regulatory implications. Chain splits create tax headaches. Tokens on both chains may be separate assets requiring cost basis allocation. The IRS had to issue Revenue Ruling 2019-24 to address tax treatment of the Bitcoin Cash fork. A governance framework that minimizes chain split risk also minimizes regulatory disruption.
The 20-Point Checklist
The framework synthesizes everything into a concrete scoring system. Twenty binary criteria across four categories:
Proposal Quality (1-5): Problem statement, technical specification, backward compatibility analysis, activation mechanism, rollback procedure.
Code Quality (6-10): Independent review by three developers, comprehensive test suite, three months on testnet, fuzzing and adversarial testing, AI code disclosure.
Activation Safety (11-15): 90% threshold for MASF, UASF prerequisites met, chain split risk assessment, replay protection, six-month activation timeline.
Community Process (16-20): Minimum review period completed, public discussion with diverse participation, exchange and infrastructure provider consultation, chain split contingency plan, evaluation against this framework.
Score all twenty. 20/20 is green — ready for activation. 15-19 is yellow — address gaps first. 10-14 is orange — significant deficiencies, don’t proceed. Below 10 is red — actively resist.
BIP-110 scores 4/20. Taproot scores 19-20/20.
Why This Matters Now
The Core vs Knots debate has been going on for over a year. One side lifted the OP_RETURN limit to 100K bytes. The other side shipped a consensus change with a 55% activation threshold and a buggy client. Neither side has proposed shared standards for how these decisions should be evaluated.
I’m not on either side. I’ve run both. I mine, I run a node, I litigate for a living. This framework is written from all of those perspectives because governance disputes don’t get resolved by ideology — they get resolved by standards.
The framework is published under Creative Commons Attribution 4.0 International. Share it, adapt it, build on it, translate it. Just give credit. If the framework is useful, it will be adopted. If it can be improved, it should be improved. That’s how Bitcoin works. That’s how its governance should work too.
View on GitHub — open for community review, amendments, and pull requests.
Asaf Fulks, J.D. | California State Bar No. 343622 | asaffulkslaw.com
Published by The Forum Press, a Fulks, Inc. company | theforumpress.com