The Bitcoin Commons

Bitcoin Commons combines BLVM (formal spec, verified consensus, full node) with forkable governance for coordinating software changes. BTCDecoded is the org shipping that stack today. See the white paper for the full argument.

BTCDecoded differential-tests against Bitcoin Core on mainnet block history with zero consensus divergence to date. Fuzzing in CI stresses consensus and protocol code beyond chain replay alone. Current depth and CI status are in technical documentation.

The dominant full-node implementation has no formal spec tied line-for-line to its code. Commons publishes layered specifications and differential testing so independent implementations can target written rules and catch drift early. See Proof of consensus compatibility and the white paper.

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.

Readiness depends on your deployment: apply your own security review, RPC hardening, and monitoring. Production governance is not cryptographically activated yet. See Project status.

BLVM (Bitcoin Low-Level Virtual Machine) is the technical stack for rigorous Bitcoin implementations: blvm-spec (consensus rule register + Orange Paper), blvm-consensus, blvm-protocol, blvm-node, blvm (binary wrapper), and blvm-sdk.

CONSENSUS_SPEC.md is the numbered rule register; the Orange Paper (PROTOCOL.md, ARCHITECTURE.md) is the extended formal specification—the "IR" in a compiler-like pipeline (Core consensus → spec register → 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 rule register and 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 applies Ostrom's commons principles with forkable rules and transparent multisig decisions. You can fork governance (not Bitcoin consensus) if you disagree with how changes ship.

The model combines repository layers (which code is affected) and action tiers (how serious the change is), with the most restrictive rule winning when both apply. Three emergency classes shorten review only for proportional critical response. Maintainer keyholders approve via signatures; the blvm-commons GitHub app is designed to enforce merge thresholds when production governance is activated.

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 loadable modules above. Optional modules are operational today; the module registry for permissionless listing is not live yet. Merge mining is an optional supplement, not the default sustainability story.

Sustainability is multi-channel: optional module usage (operational today), registry-based distribution when the registry is live, Lightning zaps, and optional merge mining for pools that want it—not a change to Bitcoin consensus rules.

Core BLVM layers and governance infrastructure are public in the BTCDecoded org; production governance is not activated yet. What is live, in progress, and planned is in Project status.

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.

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.