Bitcoin's consensus rules,
written down.

Bitcoin Commons is the umbrella: a formal specification and a forkable governance model. BLVM is the first implementation of that spec, built by BTCDecoded. It is not part of Commons. Another group could implement the same written rules later.

A second implementation has to follow Bitcoin’s rules, not invent them. Spec-lock binds Rust functions to Orange Paper sections and checks them in CI. Around that sits a suite: property tests, coverage-guided fuzz on consensus, protocol, and node, golden vectors from mainnet wire bytes and Core script fixtures, and a differential against Bitcoin Core / libbitcoinkernel. The differential is one of those layers. See how testing is layered.

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 tests the same chain against the reference node — property tests, fuzzing, golden vectors, and a Core differential — is the kind of parallel verification that surfaces those failures earlier. Commons publishes the written rules that make serious alternatives practical, and a governance model that can keep them maintained.

No. Commons validates the same chain and the same consensus rules. Think browsers, not a new coin. BLVM is a separately written implementation; Commons is the spec and governance around it.

The dominant full-node implementation has no formal spec tied line-for-line to its code. Consensus rules exist as implicit behavior in one codebase. That is a single point of failure. Commons publishes layered specifications so independent implementations can target written rules.

The specification is published. BLVM, the first implementation, is in active development. Enforcement is off and the keys are test keys. Review the software before you run a node with real funds. See project status.

BLVM (Bitcoin Low-Level Virtual Machine) is the first implementation of the Commons spec, built by BTCDecoded: a consensus library, protocol layer, full node, and SDK.

The Consensus Spec is the numbered rule register. The Orange Paper is the extended formal specification — so multiple implementations can target the same written rules.

Specification locking ties consensus-critical functions to Orange Paper sections. Checks in CI fail if the spec and the code drift apart.

Empirical checks sit beside that: property tests, fuzzing, golden vectors, and a Core differential. See Proof of consensus compatibility. BLVM is a path to checkable alternatives alongside the reference client.

Layers (which code is affected) and action tiers (how serious the change is); most-restrictive-wins. Emergency is a third dimension, not an action tier. You can fork governance — not Bitcoin consensus — if you disagree with how software changes ship. Phase 1 is current. Enforcement is off and the keys are test keys. The designer is not a live merge gate.

Governance forks are listable without a gatekeeper. A fork-registry.yml lives in the governance repo; the designer can load it.

If governance is captured, the exit is another ruleset. Consensus stays on Bitcoin. Architecturally: mandatory consensus at the base, optional modules above.

Alignment comes from usage and the module layer. Merge mining — reusing proof-of-work across chains — is an optional supplement for a pool that wants it. It leaves Bitcoin consensus rules unchanged.

BLVM: Core layers exist (spec register, Orange Paper, consensus, protocol, node, wrapper, SDK) and are in active development.

Governance: The Compact and the layer×tier YAML are published. Enforcement is off and the keys are test keys. See project status.

Review the spec and proofs, review governance rules, file issues and PRs, help test and audit, or join governance discussion. To ship your own Bitcoin-compatible implementation, target the written rules and, if you want the Commons model, fork the governance YAML.

Open source under BTCDecoded (BLVM repos, governance). Start with the White Paper, technical documentation, and governance documentation.

Through Plebly: on-chain escrow. Fund a listed Commons proposal, or donate to Commons directly.

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 so rules and power stay visible.

Cypherpunks removed trusted third parties from transactions. Commons publishes the rules for changing the software. BLVM is a second implementation checked against a written spec.