Bitcoin's consensus rules,
written down and verified.

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 real. BLVM — the first implementation — is in active development. Cryptographic merge enforcement is off — not “activation in progress.” Apply your own security review before running 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 does not replace the reference client; it is a path to checkable alternatives alongside it.

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.

The Compact and YAML are written. Keys are test keys. The GitHub App is not installed. Almost all current work is direct push. Do not read the designer as a live merge gate.

Governance forks are meant to be listable without a gatekeeper. A fork-registry.yml lives in the governance repo; the designer can load it. That is a file and a UI, not a running public registry product.

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

Alignment is supposed to come from usage and the module layer, not from a new coin. Merge mining — reusing proof-of-work across chains — is an optional pool-level supplement, not the main sustainability bet, and it does not change Bitcoin consensus rules.

BLVM: Core layers exist (spec register, Orange Paper, consensus, protocol, node, wrapper, SDK) and are in active development. Not a battle-tested production deployment for everyone.

Governance: Compact and layer×tier YAML exist. Cryptographic merge enforcement is off. Test keys; the App is not installed. 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, not a custodial tip jar. Fund a listed Commons proposal, or donate to Commons directly. Plebly is the funding venue — not Commons and not the BLVM node.

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 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.