Formal spec. Verified node. Forkable governance.
Bitcoin consensus rules in a formal spec anyone can audit. A full node differential-tested against mainnet. Governance you can fork, customize, and deploy with cryptographic thresholds.
Orange Paper
Bitcoin consensus rules written as a formal mathematical specification. Every rule is explicit, auditable, and testable by any implementation, not buried in an implementation-specific codebase.
BTCDecoded full node
A second Bitcoin full node, differential-tested against 900,000+ mainnet blocks with zero divergence. Run it, build on the SDK, or plug in modules for mining, Lightning, and more.
Governance designer
Fork the governance rules. Set thresholds, review periods, and layer controls. Export a signed YAML config and run it with cryptographic enforcement.
Orange Paper
The Orange Paper is the formal specification for BLVM and the commons stack: protocol rules, architecture, and related definitions in one auditable document. Larger slices in the chart mean more specification text lives under that heading; click a slice to preview or jump to the full viewers.
Learning
Long-form narrative, FAQs, and updates, plus the hosted documentation for reading deeper.
Documentation
Technical documentation on docs.thebitcoincommons.org: architecture, repositories, verification, and how the pieces fit together.
Orange Paper
The formal specification as published on this site, including structure, math, and definitions you can audit line by line.
White Paper
Narrative walkthrough of the commons idea: problem, modular governance, economics, and roadmap, with PDF and e-book downloads.
Substack
Essays and project updates in long form, with context and commentary outside the repo and docs.
FAQ
Short answers to common questions: how governance works, what ships when, and how this relates to Bitcoin the network.
Stay informed
Release notes, essays, and project updates, straight to your inbox.
Implementations
Multiple codebases can adopt the same governance ideas; each ships its own process while sharing principles.
BTCDecoded
Reference stack with governance infrastructure and the Orange Paper extract in-repo.
Your implementation
Fork the governance model and adapt it to your organization’s release and review culture.
Frequently Asked Questions
Common questions
Bitcoin Commons is the overarching project. It combines two innovations: BLVM, the implementation stack (Orange Paper formal specification, verified consensus, full node), and cryptographic commons governance with forkable rules, accountable process, and coordination without civil war. BTCDecoded is the engineering organization that builds and ships BLVM under Bitcoin Commons. Together they target safe alternative Bitcoin implementations you can govern without recentralizing into informal gatekeeping. BLVM supplies checkable correctness; Commons supplies coordination—both are aimed at a serious second node and governance that resists informal capture.
Bitcoin Commons is the umbrella; BLVM is the stack (spec, proofs, node). BTCDecoded is the GitHub org and team shipping that work today—another group could use the same open frameworks later.
BTCDecoded has been differentially tested against Bitcoin Core across 900,000+ mainnet blocks with zero consensus divergence. Fuzzing in CI stresses consensus and protocol code beyond what chain replay alone reaches.
Today's network is not running a second reference-grade full node at this bar: btcd's mainnet footprint is on the order of tens of nodes, with serious use concentrated in Lightning testing; libbitcoin is not a drop-in full node: it does not ship the UTXO set and mempool integration a network participant expects. No alternative full-node effort has matched this mainnet differential record against that reference implementation. How differential testing works.
Bitcoin Core remains the dominant full-node implementation, with no authoritative formal specification tied line-for-line to that code and concentrated merge authority. Redundancy matters: CVE-2018-17144 remained in Bitcoin Core production releases for nearly two years before the fix. An independent client that differentially tests the same chain against the reference node and fuzzes consensus-relevant parsing is the kind of parallel verification that surfaces those failures earlier. For the full testing record and what counts as a reference-grade second node, see Proof of consensus compatibility. Bitcoin Commons provides both the mathematical specification that makes serious alternatives practical and the governance framework that can keep them maintained.
No. Neither BLVM nor Bitcoin Commons forks Bitcoin's blockchain or consensus rules. BLVM provides mathematical specification enabling safe alternative implementations. Bitcoin Commons provides governance framework enabling coordination. Both maintain full Bitcoin consensus compatibility.
Phase 1 infrastructure is complete. All core components are implemented and verified. Phase 2 begins governance activation with a keyholder cohort. The system is ready for that transition. Governance rules are not yet cryptographically enforced in production. See Project status for phase detail.
BLVM
BLVM (Bitcoin Low-Level Virtual Machine) is the technical stack for rigorous Bitcoin implementations: blvm-spec (Orange Paper), blvm-consensus, blvm-protocol, blvm-node, blvm (binary wrapper), and blvm-sdk.
The Orange Paper is the mathematical specification of Bitcoin consensus—the "IR" in a compiler-like pipeline (Core consensus → Orange Paper → blvm-consensus → blvm-node) so multiple implementations can target the same written rules.
Specification locking and formal verification tie consensus-critical code to the Orange Paper; the codebase includes on the order of 200 embedded proofs checked continuously. Proofs live with the code so drift forces updates. A dependency chain routes consensus through verified functions; spec-drift tooling flags mismatches.
Empirical checks complement that: differential testing and CI fuzzing (see Proof of consensus compatibility). BLVM does not replace the reference client; it is a path to checkable alternatives alongside it.
Bitcoin Commons governance
Bitcoin Commons applies Elinor Ostrom's commons principles with cryptographic enforcement: forkable rules, transparent multisig decisions, and coordination without turning governance into an informal gate. You can fork governance (not Bitcoin consensus) if you disagree with how software changes ship.
The model uses a 5-tier constitutional path (graduated thresholds and review periods), layers (which repo is affected) and tiers (what class of change), with "most restrictive wins" when both apply—for example a Protocol Engine fix can require stricter review than a routine maintenance tier alone would. A three-tier emergency path shortens review only for proportional critical response. Maintainer keyholders approve changes via signatures; the blvm-commons GitHub app verifies thresholds and blocks merges until requirements are met.
The Fork Registry is public and self-service: submit a pull request to list your governance fork (automated validation; no gatekeeper approval). Use "Fork Your Governance" to browse, compare, see genealogy, and start from templates. If governance is captured, users can exit to another ruleset—consensus stays on Bitcoin; the threat of exit reduces capture pressure.
Architecturally: mandatory consensus (BLVM) at the base, optional modules and competition above, and economic coordination through the module marketplace (merge mining is an optional supplement, not the default story). You can use BLVM without Commons (technically), but you still face governance capture risk; Commons without BLVM still leaves informal implementation risk for consensus-critical code.
Revenue and alignment start with the module marketplace and usage; Lightning zaps and similar channels can fund governance and development directly. Merge mining reuses proof-of-work across chains and is an optional pool-level supplement—not the main sustainability bet. Where used, a small share of merged-chain rewards can support development without changing Bitcoin consensus rules.
Implementation status
BLVM: Core layers are implemented (Orange Paper, blvm-consensus with ~200 proofs, protocol, node, wrapper, SDK). Work continues on HA, build/signing, deterministic builds, and hardening. Not yet battle-tested as a production deployment for everyone.
Governance: Infrastructure is in place (blvm-commons app, fork exports, emergency tiers, layer+tier rules) but production governance is not activated yet (test keys; keyholders not onboarded). Phase 2 starts with keyholder onboarding. Interested developers, researchers, or institutions can reach the project via BTCDecoded on GitHub. Audits, app deployment, and community testing remain on the path to stable Phase 2 and beyond.
Get involved
Review BLVM and proofs, review governance rules, file issues and PRs, help test and audit, or participate in governance discussion. To ship your own Bitcoin-compatible implementation, adopt BLVM and/or Commons governance, fork rulesets for your org, and list yourself in the Implementations Registry.
Open source under BTCDecoded (BLVM repos, governance, blvm-commons). The fork registry lives in the governance repo.
Start with the White Paper, technical documentation, and governance documentation.
Philosophy
Bitcoin's codebase is a commons—shared, valuable, not owned by a single party. Ostrom showed how durable commons are governed; Bitcoin Commons applies that with cryptography so rules and power stay visible.
Cypherpunks removed trusted third parties from transactions; Commons and BLVM push the same idea into how software is governed and verified—less informal trust in a single implementation or maintainer culture, more auditability and mathematical specification.