The Bitcoin Commons

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.

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.

The two innovations stack together: BLVM is the implementation (Orange Paper as the shared IR, spec-locked consensus, full node). Bitcoin Commons is the governance layer with forkable rules, cryptographic thresholds, and accountable process for how that software changes and ships. BLVM supplies checkable correctness; Commons supplies coordination without civil war. You do not get a serious second node without both the spec-backed stack and governance that resists informal capture.

BLVM (Bitcoin Low-Level Virtual Machine): Technical innovation providing mathematical rigor through the Orange Paper (mathematical specification), formal verification (specification locking annotations), proofs locked to code, and a compiler-like architecture. This ensures correctness.

Bitcoin Commons (Cryptographic Commons): Governance innovation providing forkable governance through Ostrom's principles, cryptographic enforcement, 5-tier governance model, and transparent audit trails. This ensures coordination.

Bitcoin Commons is the umbrella project. BLVM is the implementation stack (spec, proofs, node). BTCDecoded is the GitHub organization and engineering team that builds and ships BLVM and implements Commons governance for the project today. Another group could ship a BLVM-based node under the same open frameworks; BTCDecoded is the team doing the work now.

BLVM (Bitcoin Low-Level Virtual Machine) is the technical stack that provides mathematical rigor for Bitcoin implementations. It includes: (1) blvm-spec (Orange Paper) - complete mathematical specification of Bitcoin consensus, (2) blvm-consensus - pure mathematical implementation with formal verification, (3) blvm-protocol - Bitcoin abstraction layer, (4) blvm-node - full node implementation, (5) blvm - binary wrapper for blvm-node, (6) blvm-sdk - developer toolkit. Think of it as a compiler-like architecture where the Orange Paper is the IR (intermediate representation).

The Orange Paper is a complete mathematical specification of Bitcoin's consensus protocol, extracted from Bitcoin Core using AI-assisted analysis. It serves as the "intermediate representation" (IR) in BLVM's compiler-like architecture. It enables safe alternative implementations by providing formal, verifiable consensus rules that can be mathematically proven correct.

BLVM uses specification locking annotations and formal verification to formally verify consensus-critical code. The Orange Paper provides the mathematical specification; blvm-consensus implements it with proofs locked to code. All consensus decisions flow through verified functions, and the dependency chain prevents bypassing verification. This provides mathematical proof of correctness, not just testing.

The dominant C++ full node embeds consensus rules in 350,000+ lines with no mathematical specification. BLVM provides: (1) Mathematical specification (Orange Paper), (2) Formal verification (specification locking annotations), (3) Proofs locked to code, (4) Compiler-like architecture enabling safe alternative implementations. BLVM does not replace that client; it enables checkable alternatives.

Like a compiler has source code → IR → machine code, BLVM has: Bitcoin Core consensus code → Orange Paper (IR) → blvm-consensus → blvm-node. The Orange Paper serves as the intermediate representation that multiple implementations can target, just like multiple compilers can target the same IR. This enables implementation diversity while maintaining consensus correctness.

Bitcoin Commons is a forkable governance framework that solves Bitcoin's fundamental governance asymmetry. While Bitcoin's technical consensus is bulletproof (proof-of-work, cryptographic signatures), its development governance has remained fragile, controlled by a handful of maintainers with no systematic process. Bitcoin Commons applies Elinor Ostrom's Nobel Prize-winning commons management principles through cryptographic enforcement, making development governance as robust as technical consensus. It enables coordination without authority, allowing multiple implementations to compete while maintaining Bitcoin consensus compatibility. The framework provides an architectural solution: if you disagree with governance decisions, you can fork the governance rules (not just the code) and create a better-governed implementation.

The system uses a 5-tier constitutional model with graduated signature thresholds and review periods: Tier 1 (routine maintenance) requires 3-of-5 signatures and 7 days; Tier 3 (consensus-adjacent changes) requires 5-of-5 signatures and 90 days; Tier 5 (governance changes) requires 5-of-5 signatures and 180 days. The system combines two dimensions: Layers (which repository is affected, for example Protocol Engine, Consensus, or related layers) and Tiers (what type of change), using "most restrictive wins" for maximum security. All governance actions are cryptographically signed by maintainers and transparently auditable. A three-tiered emergency system provides proportional response (0-90 day review periods) for critical issues. Users can export governance rulesets as versioned, signed packages and fork to different governance models if they disagree with decisions, creating exit competition that prevents capture.

Multiple mechanisms: (1) Forkable governance rules allow users to exit if governance is captured, (2) Multiple implementations compete, preventing monopoly, (3) Cryptographic enforcement makes power visible and accountable, (4) Economic alignment through the module marketplace and usage-based revenue (optional merge mining can supplement but is not the primary bet), (5) Graduated thresholds prevent rapid changes, (6) Transparent audit trails.

Users can fork the governance rules (not just the code) if they disagree with decisions. This creates exit competition: if governance is captured, users can fork to a better governance model while maintaining Bitcoin consensus compatibility. The threat of forking prevents capture.

Elinor Ostrom's Nobel Prize-winning research identified 8 principles for managing commons successfully. Bitcoin Commons applies these through: clearly defined boundaries, proportional equivalence, collective choice, monitoring, graduated sanctions, conflict resolution, minimal recognition of rights, and nested enterprises.

BLVM solves the technical problem (mathematical rigor, safe alternative implementations). Bitcoin Commons solves the governance problem (coordination without civil war). You can't have safe alternatives without BLVM's mathematical foundation, and you can't have coordination without Commons' governance framework. They enable each other.

The modular architecture has three layers: (1) Mandatory consensus (BLVM ensures correctness), (2) Optional modules (Commons enables competition), (3) Economic coordination (the module marketplace funds development and aligns adoption with revenue; merge mining is an optional supplement). BLVM enforces correctness in the base layer; Commons supplies governance for how modules and releases evolve. The architecture is where both meet.

Technically yes: BLVM is a technical stack that can be used independently. However, without Bitcoin Commons governance, you'd still have the governance capture problem. The innovations are designed to work together: BLVM enables safe alternatives, Commons enables coordination between alternatives.

The governance framework could theoretically be applied to other implementations, but BLVM's mathematical rigor (Orange Paper, formal verification) is what makes alternative implementations safe. Without BLVM, you'd have governance but still risk consensus bugs from informal implementations.

BLVM uses specification locking annotations and formal verification to mathematically prove code correctness. The Orange Paper provides the specification; blvm-consensus implements it with proofs. All consensus decisions flow through verified functions. This provides mathematical proof, not just testing.

BLVM has nearly 200 formal proofs in the source code, providing comprehensive formal verification coverage of consensus-critical functions. The proofs are embedded directly in the codebase and verified continuously.

Formal verification proofs are embedded in the code itself, not separate documentation. The proofs verify that the code matches the Orange Paper specification. If code changes, proofs must be updated, ensuring correctness is maintained.

Through multiple layers: (1) Orange Paper provides mathematical specification, (2) Formal verification proves implementation matches spec, (3) Proofs locked to code prevent drift, (4) Dependency chain forces all consensus through verified functions, (5) Spec drift detection alerts if code diverges from spec.

The Fork Registry is a public, self-service registry for governance forks. Anyone can submit a pull request to add their governance fork. No approval is needed, just automated validation. The registry tracks governance forks with their signature thresholds, review periods, and relationships (which fork was created from which). Use the "Fork Your Governance" section on this website to browse the registry, compare forks, view the genealogy tree, and create your own fork.

All governance actions require cryptographic signatures from maintainers. The blvm-commons (GitHub App) verifies signatures, enforces thresholds (e.g., 6-of-7), and blocks merges until requirements are met. This makes power visible and accountable: you can see who signed what, when.

Forkable governance means users can fork to a better governance model. This creates exit competition: captured governance loses users to better-governed implementations. The threat of forking prevents capture. Unlike typical reference-client governance, you can fork the governance rules, not just the code.

Primarily through the module marketplace: paid distribution and discovery tie project revenue to real adoption. Lightning-based governance zaps and similar channels add direct community funding. Merge mining is a possible supplement for operators who enable it, not the default path. Well-governed implementations still benefit when the network is healthy, but the economic story starts with modules and usage, not hash-rate side chains.

Merge mining lets miners work additional chains with the same proof-of-work. It is an optional supplement for pools that want extra revenue; it is not the main sustainability lever (see the module marketplace and module fees). Where it is used, a small share of merged chain rewards can flow to development without changing Bitcoin's consensus rules.

Bitcoin Commons uses maintainer multisig governance. Maintainer keyholders approve changes through cryptographic signatures. This keeps decisions transparent and auditable while preserving Bitcoin consensus compatibility.

Governance forks allow users to choose different governance rulesets without affecting Bitcoin consensus. Users can export governance rulesets as versioned, signed packages and fork to a better governance model if they disagree with decisions. This provides an escape hatch: captured governance loses users to better-governed implementations. The threat of forking prevents capture while maintaining Bitcoin consensus immutability.

Interactive Tools: Use the "Fork Your Governance" section on this website to browse existing forks, start from templates, customize your own ruleset, compare different governance models, and view the fork genealogy tree. The system includes a self-service fork registry where anyone can submit their governance fork via pull request with no approval needed, just automated validation.

Bitcoin Commons uses a dual-dimensional system: Layers (which repository) and Tiers (what type of change). When both apply, the system uses "most restrictive wins" - taking the highest signature threshold and longest review period. For example, a bug fix in the Protocol Engine (Layer 3) requires 4-of-5 signatures and 90 days, even though Tier 1 (routine maintenance) normally requires only 3-of-5 and 7 days. This ensures maximum security for sensitive repositories.

Bitcoin Commons uses a three-tiered emergency response system for proportional handling of critical issues: Tier 1: Critical Emergency (network-threatening, 0 days, 4-of-7 maintainers, 7 day max), Tier 2: Urgent Security (security issues, 7 days, 5-of-7 maintainers, 30 day max), Tier 3: Elevated Priority (important but not critical, 30 days, 6-of-7 maintainers, 90 day max). This ensures rapid response to critical threats while maintaining appropriate review for less urgent issues.

All 8 layers are implemented: blvm-spec (Orange Paper) complete, blvm-consensus with nearly 200 formal proofs, blvm-protocol, blvm-node, blvm (binary wrapper), and blvm-sdk all functional. Recent work includes high availability features, build state tracking, fork verification, binary signing tools, and deterministic build verification. The system is not yet battle-tested in production.

All core governance infrastructure is implemented: blvm-commons (GitHub integration, signature verification, status checks), governance fork capability (ruleset export and forking), emergency tier system (three-tiered response), and layer+tier combination model. However, governance is not yet activated (test keys only) and keyholders are not yet onboarded. Phase 2 begins with initial keyholder onboarding; see BTCDecoded on GitHub to follow progress or get involved.

Phase 2 governance activation begins with initial keyholder onboarding. If you are a Bitcoin developer, researcher, or institution interested in participating as a keyholder, contact the project via the BTCDecoded organization on GitHub. Security audits, governance app deployment, and community testing remain part of the path to stable Phase 2 and Phase 3 full operation.

Review BLVM code and formal proofs, review Bitcoin Commons governance rules, submit issues and pull requests, help with testing and security audits, build your own implementation using both innovations, or participate in governance discussions.

Yes! You can use BLVM's technical stack (Orange Paper, blvm-consensus) and adopt Bitcoin Commons governance framework. Fork the governance model, customize it for your organization, and build your own Bitcoin-compatible implementation. See the Implementations Registry.

All code is open source on GitHub under the BTCDecoded organization. Key repositories: BLVM (blvm-spec/Orange Paper, blvm-consensus, blvm-protocol, blvm-node, blvm, blvm-sdk) and Commons (governance, blvm-commons). The fork registry is maintained in the governance repository.

White Paper for complete technical and governance overview, Documentation for unified technical documentation, and Governance Docs for governance rules and processes.

Bitcoin's codebase is a commons: a shared resource that benefits everyone but no one owns. Traditional commons fail due to tragedy of the commons. Ostrom showed how to manage commons successfully. Bitcoin Commons applies these proven principles through cryptographic enforcement.

Cypherpunks focused on eliminating trusted third parties in transactions. Bitcoin Commons extends this to development: eliminate trusted parties in governance through cryptographic enforcement, transparency, and forkability. BLVM extends this to implementation: eliminate trusted implementations through mathematical proof.