BTCDecoded

Bitcoin Decoded: Bitcoin LLVM and Cryptographic Commons

Bitcoin's Governance Crisis

Bitcoin solved the Byzantine Generals' Problem for transactions, but it never solved the Byzantine Generals' Problem for development. At a $2 trillion market cap, humanity's hardest money is controlled by a handful of developers with no systematic governance.

The asymmetry is stark: Bitcoin's technical consensus is bulletproof, but its social consensus is fragile. A handful of people with write access to the code repository control a $2 trillion project. This creates a single point of failure that threatens Bitcoin's future.

Gavin Andresen warned us about this in 2014. He said Bitcoin needed "three or four or five robust re-implementations" to give confidence that the system wouldn't have "some horrible bug that we manage to miss." But the governance problem had to be solved first.

Built on Bitcoin Commons

BTCDecoded implements the Bitcoin Commons governance framework, a forkable model for building uncapturable governance institutions. The framework provides the architectural approach and governance principles; BTCDecoded is our complete implementation.

Learn About the Framework

Architecture

BTCDecoded's 7-repository stack enforces correctness through mathematical specification and formal verification. The Orange Paper provides the mathematical foundation; blvm-consensus implements it with formal verification (Kani model checking); all higher layers depend directly on blvm-consensus. See the architecture documentation for detailed technical information.

1

blvm-spec

Mathematical Specification

Complete mathematical specification of Bitcoin consensus extracted from Bitcoin Core. Includes the 21 million supply convergence proof (Theorem 6.1).

2

blvm-consensus

Formally Verified Implementation

Pure Rust implementation of Orange Paper functions with Kani model checking for formal verification. All consensus decisions are mathematically proven. UTXO set operations verified for consistency and double-spend prevention.

Formal Verification: Kani proofs verified in source code. Chain selection, block subsidy (21M limit proof), proof-of-work, transaction validation all verified with bounded model checking.

3

blvm-protocol

Protocol Abstraction

Bitcoin variant abstraction (mainnet, testnet, regtest) built on blvm-consensus. All consensus calls go through the formally verified layer.

4

blvm-node

Full Node Library

Complete Bitcoin node library using blvm-protocol and blvm-consensus. Adds storage, networking, and RPC. Optional features: Iroh QUIC transport (NAT traversal), Quinn QUIC transport, UTXO commitments (faster initial sync).

5

blvm

Binary Wrapper

Standalone binary executable that wraps blvm-node. Provides command-line interface for running a full Bitcoin node. Depends on blvm-node library.

6

blvm-sdk

Developer Toolkit

Developer toolkit for building alternative Bitcoin implementations. Provides module composition framework for declaratively assembling custom Bitcoin nodes, plus governance cryptographic primitives.

7

governance

Governance Configuration

Central source of truth for governance rules, layer hierarchy, and emergency tier system. Defines who can merge what, and when.

8

blvm-commons

Cryptographic Enforcement

GitHub App enforcing governance rules through signature verification and review periods. Uses blvm-sdk for cryptographic operations. Phase 1: Infrastructure complete, enforcement not yet activated.

Dependency Chain: Orange Paper → blvm-consensus (formally verified with Kani model checking) → blvm-protocol → blvm-node → blvm (binary wrapper) → blvm-sdk → governance → blvm-commons. All consensus decisions flow through the mathematically proven blvm-consensus layer.

Note: blvm-node and blvm are both part of the Application Layer (Layer 4-5). governance and blvm-commons are both part of the Governance Infrastructure Layer (Layer 7-8).

BLVM Stack Architecture

BLVM architecture showing blvm-spec (Orange Paper) as the foundation, blvm-consensus as the core implementation with verification paths (Kani proofs, spec drift detection, hash verification), and dependent components (blvm-protocol, blvm-node, blvm-sdk) building on the verified consensus layer.

Download BLVM

Bitcoin node implementation with formal verification

Phase 1: Infrastructure Complete

System is unreleased and untested in production. Governance rules not yet enforced. See System Status for details.

Source Code

Available now on GitHub

View Releases

Binaries & Packages

Coming soon after Phase 2 activation

  • Executables (Linux, macOS, Windows)
  • RPM packages
  • DEB packages

The Orange Paper (blvm-spec)

The Orange Paper is the first complete mathematical specification of Bitcoin's consensus protocol. Unlike previous descriptions, this specification is derived entirely from the current Bitcoin Core codebase and represents the protocol as it exists today. The specification is available in the blvm-spec repository and in the unified documentation.

Using AI-assisted extraction, we've formalized Bitcoin's consensus rules into mathematical functions that can be used to build alternative implementations without consensus risk.

Supply Convergence Proof

Theorem 8.2 (Supply Convergence): The total supply converges to exactly 21 million BTC.

Proof: From Theorem 6.1, we have:

$$\lim_{h \to \infty} \text{TotalSupply}(h) = 21 \times 10^6 \times C$$

Since the subsidy becomes 0 after 64 halvings (height 13,440,000), the total supply is exactly:

$$\text{TotalSupply}(13,440,000) = 50 \times C \times \sum_{i=0}^{63} \left(\frac{1}{2}\right)^i = 50 \times C \times \frac{1 - (1/2)^{64}}{1 - 1/2} = 100 \times C \times (1 - 2^{-64})$$

For practical purposes, $2^{-64} \approx 0$, so the total supply is effectively 21 million BTC.

Source: Orange Paper, Theorem 8.2

This Rust code is formally verified using Kani model checking to prove the supply convergence property.

blvm-consensus/src/economic.rs View on GitHub →
/// Kani proof: Supply Convergence (Orange Paper Theorem 8.2)
///
/// Mathematical specification:
/// lim(h→∞) TotalSupply(h) = 21 × 10⁶ × C
///
/// This proves that the total supply converges to exactly 21 million BTC.
/// After 64 halvings (height 13,440,000), the subsidy becomes 0, so:
/// TotalSupply(13,440,000) = 50 × C × Σ(i=0 to 63) (1/2)^i = 100 × C × (1 - 2^-64)
/// For practical purposes, 2^-64 ≈ 0, so supply ≈ 21M BTC.
#[kani::proof]
fn kani_supply_convergence() {
    // Test convergence property: as height increases, supply approaches 21M
    // After 64 halvings (height = 13,440,000), subsidy = 0

    // Calculate supply at different heights to show convergence
    let height_after_64_halvings = HALVING_INTERVAL * 64;

    // Bound for tractability (test up to 10 halvings)
    let max_test_height = HALVING_INTERVAL * 10;
    kani::assume(max_test_height <= height_after_64_halvings);

    // Supply at height h approaches 21M as h increases
    // Formula: TotalSupply(h) = 50 × C × Σ(i=0 to min(63, ⌊h/H⌋)) (1/2)^i
    // Where H = HALVING_INTERVAL = 210,000

    // Test monotonic convergence: supply increases but never exceeds 21M
    let supply_at_max = total_supply(max_test_height);

    // Critical invariant: supply never exceeds maximum money (21M BTC)
    assert!(
        supply_at_max <= MAX_MONEY,
        "Supply Convergence: total supply must never exceed 21M BTC"
    );

    // Convergence property: after many halvings, supply approaches 21M
    // For height = HALVING_INTERVAL * 64, subsidy = 0, so supply is constant
    // The supply at this point is: 50 × C × (1 - (1/2)^64) / (1 - 1/2) = 100 × C × (1 - 2^-64)
    // Since 2^-64 is negligible, this is effectively 100 × C = 21M BTC

    // Verify supply is bounded and converges
    assert!(
        supply_at_max >= 0,
        "Supply Convergence: total supply must be non-negative"
    );

    // Supply increases monotonically until halvings stop
    if max_test_height > 0 {
        let supply_at_h_minus_1 = total_supply(max_test_height - 1);
        assert!(
            supply_at_max >= supply_at_h_minus_1,
            "Supply Convergence: supply must increase monotonically"
        );
    }
}
Read in Documentation View on GitHub
Consensus Coverage Comparison

Comparison of consensus coverage between Bitcoin Core (testing-based) and Bitcoin Commons (formal verification plus testing).

Cryptographic Commons

BTCDecoded implements the Bitcoin Commons governance framework, a forkable model for building uncapturable governance institutions. The framework applies Ostrom's principles of successful commons management to Bitcoin development, using cryptographic enforcement instead of social pressure.

Why Bitcoin Commons Matters

Bitcoin solved trust in transactions, but never solved trust in development. At a $2 trillion market cap, humanity's hardest money is controlled by a handful of developers with no systematic governance.

The Bitcoin Commons framework solves this by integrating four proven philosophies:

  • Ostrom's Commons Principles - Proven institutional design for managing shared resources
  • Bitcoin's Cryptographic Enforcement - Mathematical proof replaces social pressure
  • Hayek's Spontaneous Order - Competition discovers optimal solutions
  • Cypherpunk Privacy - Technology protects individual sovereignty

This creates a governance system that is harder to capture than traditional Bitcoin development, while maintaining the flexibility needed for protocol evolution.

Centralized vs Decentralized Governance

Bitcoin Commons moves governance from centralized control (few maintainers, single point of failure) to decentralized, forkable governance (distributed maintainers, multiple implementations, user choice). This architectural shift makes capture structurally difficult.