Second Edition · May 2026 · 66 pages
Download the PDF · Source on GitHub
Bitcoin has no standards for evaluating consensus changes. Zero.
There is no checklist. No threshold for what “rough consensus” means. No required review period. No criteria for who counts as a reviewer. No definition of what makes activation safe. When someone proposes a change to the rules every node enforces, the community argues — and the loudest, most persistent, or most-funded faction tends to win procedurally regardless of the substantive merits.
Consensus Change Standards is a 66-page framework that fills that gap. It gives reviewers, developers, miners, node operators, and counsel a shared scorecard for evaluating any proposed change to Bitcoin’s consensus rules.
What’s in the framework
- A 20-criterion scorecard across four categories: Proposal Quality, Code Quality, Activation Safety, and Community Process. Each criterion is binary (Met / Not Met). Total maps to a classification band: Green (20/20, ready), Yellow (15–19, identified gaps), Orange (10–14, significant deficiencies), Red (<10, not ready).
- Seven red flags (§5.0) for spotting risky proposals before doing the full evaluation. Anchored to the substantive sections that explain why each flag matters.
- Heuristic anchors (§5.3) for the eight fuzzy criteria where reasonable reviewers might disagree on Met / Not Met. Illustrative, not algorithmic.
- Worked examples (§5.4) applying the scorecard to Taproot and BIP-110. Criterion-by-criterion, with citations.
- A comparative legal note (§4.6) mapping the California negligence and §552 analysis onto UK, Commonwealth, EU, and civil-law jurisdictions.
- A 23-entry glossary of technical terms aimed at lawyers and policy readers.
The case study: BIP-110
BIP-110 is the immediate occasion for the framework. It scores 3 out of 20 — Red.
The mechanism is a 55% UASF run through Bitcoin Knots with LOT=true: an early lock-in trigger at 55% miner signaling, mandatory lock-in around August 2026 where BIP-110 nodes reject blocks from non-signaling miners regardless of actual signaling levels, and activation at max_activation_height block 965,664.
A 55% threshold means up to 45% of hashrate could be mining blocks that BIP-110 nodes consider invalid. Mandatory lock-in removes the “abandon if it doesn’t catch on” safety valve that every modern successful soft fork preserved. Per bip110monitor.com, peak miner signaling has never exceeded 0.15%.
The activation client itself — Knots release v29.3.knots20260508 — shipped with release notes describing it as one that “fixes critical vulnerabilities in long-standing network design.” The proposal has had roughly a two-month public review period. There is no risk disclosure on the distribution platforms users are downloading it from.
By comparison: Taproot scores 18/20. Per the literal bands that’s Yellow, but the two “Not Met” criteria are framework-temporal artifacts. C19 asks for a chain-split contingency plan published by the proposal author; C20 asks for the proposal to be evaluated against this framework’s scorecard and the results published. Neither documentation convention existed in 2021 when Taproot activated. On every criterion within the proposers’ actual decision space, Taproot is Met — substantively Green.
The fifteen-criterion gap between Taproot and BIP-110 reflects categorically different framework readiness — not a marginal disagreement about specifications.
The legal layer
Most consensus change debates are framed as community politics. They are not just that. Software authors, maintainers, and distributors of consensus-critical code may have duties to users under existing law:
- California negligence (§4.1) — Biakanja multi-factor balancing for duties to non-contractual users foreseeably injured by software defects.
- Negligent misrepresentation (§4.2) — Restatement (Second) of Torts § 552, applied to representations made on distribution platforms and release notes.
- Fiduciary duty (§4.3) — Tulip Trading v Persons Unknown (EWCA 2023) reinstated the fiduciary duty pleading against developers, struck out the negligence claim. The factual posture (stolen-key recovery) differs from a chain-split scenario, but the legal reasoning travels.
- Comparative law (§4.6) — Caparo Industries v Dickman (UKHL 1990) and Hedley Byrne v Heller (UKHL 1964) supply structural parallels in England and Wales. Sullivan v Moody (HCA 2001) and Cooper v Hobart (SCC 2001) do the same for Australia and Canada. The 2024 EU Product Liability Directive extends strict liability to software (with a contested open-source carve-out). Swiss Code of Obligations Article 41 supplies the civil-law tort baseline.
None of these is a settled holding that “Knots maintainers will lose a class action.” The point is that the legal exposure is real enough to weigh against pushing a 3/20 proposal to mainnet — and that proceeding anyway is a position someone may eventually have to defend in a courtroom, not just on a mailing list.
The Inscription Era backdrop
The framework is procedurally neutral on the substantive Ordinals / inscriptions disagreement. §1.2 lays out that backdrop — Casey Rodarmor’s Ordinals protocol (December 2022), the OP_FALSE OP_IF envelope mechanism, Taproot’s witness-data fee discount, the 2023-onward debate — so a reader can see what motivated BIP-110 without the framework taking a side on whether inscriptions are good or bad for Bitcoin. The scorecard would reach the same 3/20 score for a proposal whose substantive merits you agree with.
Who this is for
- Protocol developers and reviewers — a checklist to apply to your own proposals before asking others to review them, and to others’ proposals before signaling support.
- Miners and pool operators — criteria for evaluating whether a signaling request meets a threshold worth signaling for.
- Node operators — language for explaining what “not ready” means without re-litigating the merits.
- Counsel — a treatment of the California and comparative legal exposure surface that a software project distributing consensus-critical code is operating on.
Read it
Published under Creative Commons Attribution 4.0 International.
Cite as: Asaf Fulks, Consensus Change Standards: A Framework for Bitcoin Protocol Governance (2d ed. 2026), asaffulkslaw.com.