The Bitcoin Commons

Bitcoin Commons is a project that solves Bitcoin's governance asymmetry through two complementary innovations: BLVM (the technical stack providing mathematical rigor) and Bitcoin Commons (the governance framework providing coordination without civil war). Together, they enable safe alternative Bitcoin implementations with forkable governance.

Bitcoin Core is a single implementation with informal governance. Bitcoin Commons provides: (1) BLVM - Mathematical rigor enabling safe alternatives, (2) Commons - Forkable governance enabling coordination. Bitcoin Core has excellent consensus security; Bitcoin Commons adds governance security and implementation diversity.

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 complete. All core components implemented, but governance not yet activated. System is not yet battle-tested in production.

BLVM ensures correctness through mathematical rigor. Commons ensures coordination through governance rules.

You can't have safe alternatives without BLVM, and you can't have coordination without Commons.

BLVM (Bitcoin Low-Level Virtual Machine): Technical innovation providing mathematical rigor through the Orange Paper (mathematical specification), formal verification (blvm-spec-lock with Z3), 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 governance framework; BTCDecoded is the first complete implementation of both innovations (BLVM + Commons). Think of BLVM as the technical foundation, Bitcoin Commons as the governance constitution, and BTCDecoded as the first "government" built on both. Other implementations can adopt the same framework.

BLVM is the technical stack providing mathematical rigor: Orange Paper (spec) → blvm-consensus (verified implementation) → blvm-protocol → blvm-node → blvm-sdk.

Think of it as a compiler-like architecture where the Orange Paper is the IR.

Complete mathematical specification of Bitcoin consensus, extracted from Bitcoin Core. Serves as the IR in BLVM's compiler-like architecture, enabling safe alternative implementations.

BLVM uses blvm-spec-lock with Z3 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.

Bitcoin Core embeds consensus rules in 350,000+ lines of C++ with no mathematical specification. BLVM provides: (1) Mathematical specification (Orange Paper), (2) Formal verification (blvm-spec-lock with Z3), (3) Proofs locked to code, (4) Compiler-like architecture enabling safe alternative implementations. BLVM doesn't replace Bitcoin Core; it enables safe alternatives.

Like a compiler: source code → IR → machine code. BLVM: Bitcoin Core code → Orange Paper (IR) → blvm-consensus → blvm-node.

The Orange Paper is the IR that multiple implementations can target, enabling diversity while maintaining consensus correctness.

Forkable governance framework solving Bitcoin's governance asymmetry. Applies Ostrom's commons principles through cryptographic enforcement, enabling coordination without authority.

If you disagree with governance, fork the rules (not just the code) and create a better-governed implementation.

5-tier constitutional model with graduated thresholds: Tier 1 (3-of-5, 7 days) to Tier 5 (5-of-5, 180 days).

Combines Layers (repository) and Tiers (change type) using "most restrictive wins."

All actions are cryptographically signed and auditable. Users can fork governance rulesets to create exit competition.

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) Graduated thresholds prevent rapid changes, (5) Transparent audit trails.

Users can fork governance rules (not just code) if they disagree with decisions.

This creates exit competition: if governance is captured, users fork to a better model while maintaining Bitcoin consensus compatibility.

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 alternatives). Bitcoin Commons solves the governance problem (coordination without civil war). They enable each other.

Three layers: (1) Mandatory Consensus (BLVM ensures correctness), (2) Optional Modules (Commons enables competition), (3) Governance Infrastructure (coordination and enforcement).

Technically yes: BLVM can be used independently. However, without Bitcoin Commons governance, you'd still have the governance capture problem. They're designed to work together.

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 blvm-spec-lock with Z3 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 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 Bitcoin Core, you can fork the governance rules, not just the code.

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—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 6 tiers are implemented: blvm-spec (Orange Paper) complete, blvm-consensus with nearly 200 formal proofs, blvm-protocol, blvm-node, blvm-sdk, and governance infrastructure 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, governance fork capability, emergency tier system. Governance is not yet activated (test keys only).

Phase 2: Governance enforcement begins. Requires security audits, keyholder onboarding, governance app deployment, and community testing.

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.