Consensus Layer Overview

blvm-consensus answers one question: given a transaction, block, UTXO set, and activation flags, does Bitcoin consensus accept it? It does not open sockets, read blvm.toml, or choose mainnet vs regtest. That belongs to blvm-protocol and blvm-node.

What this layer is for

Consensus code is the trust anchor of the stack. Wallets, pools, and modules depend on the node reporting chain state that matches what every other Bitcoin mainnet participant would accept. If validation is wrong here, every higher layer is wrong.

The layer implements rules from the Orange Paper as deterministic Rust: script execution, block connection, subsidy and difficulty math, mempool acceptance rules used by the node, and soft-fork behavior at documented activation heights. Block and script logic live in block/ and script/ submodules; canonical types, serialization, and crypto come from blvm-primitives (re-exported by blvm-consensus for API stability).

Relationship to the Orange Paper

The Orange Paper is the specification (implementation-agnostic IR). blvm-consensus is the implementation, validated against that spec, not generated from it. Optimization passes speed the code without changing specified meaning; see Optimization passes.

Chain of trust: Orange Paper → blvm-consensus → tests + spec-lock → node deployment

Verification methodology, coverage, and CI: Formal Verification. Policy: verification policy, proof limitations.

What lives here vs elsewhere

Concern	Layer
Script/block/UTXO math	blvm-consensus (this page)
Network magic, ports, message serialization	blvm-protocol
Storage, P2P, RPC, modules	blvm-node
Fast sync (UTXO commitments, peer consensus, spam filtering)	node docs (blvm-protocol / blvm-node, not consensus rules)
Orange Paper function catalog & Rust API names	API Index: Consensus

Architecture position

Stack layer 2: between the Orange Paper (layer 1) and protocol abstraction (layer 3). Full stack: Stack overview.

Design principles

Pure functions: Deterministic validation; explicit inputs instead of hidden globals
No rule interpretation in apps: Node calls into consensus; modules never patch rules
Controlled dependencies: Cargo.toml pins and ranges are the source of truth for crypto and BLVM crates
Testing in depth: Testing, property-based tests, differential testing via blvm-bench
Formal verification: Spec-lock proofs complement tests; see Formal Verification
No consensus rule interpretation: Only mathematical implementation of the Orange Paper
Optimization passes: Runtime optimizations speed the code without changing specified meaning; see Optimization passes

Core functions

Transaction validation

Transaction structure and limit validation
Input validation against UTXO set
Script execution and verification

Block validation

Block connection and validation
Transaction application to UTXO set
Proof of work verification

Economic model

Block reward calculation
Total supply computation
Difficulty adjustment

Mempool protocol

Transaction mempool validation
Standard transaction checks
Transaction replacement (RBF) logic

Mining protocol

Block creation from mempool
Block mining and nonce finding
Block template generation

Chain management

Reorganization primitives in blvm-consensus (src/reorganization.rs); blvm-node wires them for the live process_block path (block index, chainwork tip selection, undo persistence, events: see blvm-node fork choice and reorg)
P2P network message processing

Advanced features

SegWit: Witness data validation and weight calculation (see BIP141)
Taproot: P2TR output validation and key aggregation (see BIP341)

Optimization passes

The implementation is validated against the Orange Paper; optimization passes optimize the implementation code (not the spec). Meaning is defined by the Orange Paper; see compiler-like architecture. Production and Rayon feature flags: consensus features.

Constant folding: Pre-computed constants and constant propagation
Memory layout optimization: Cache-aligned structures and compact stack frames
SIMD vectorization: Batch hash operations with parallel processing
Bounds check optimization: Removes redundant runtime bounds checks using BLVM Specification Lock-proven bounds
Dead code elimination: Removes unused code paths
Inlining hints: Aggressive inlining of hot functions

Area	Repository path
Crate root	blvm-consensus
Transactions / scripts	`src/transaction.rs`, `src/script/`
Blocks / chain	`src/block/`
Economic rules	`src/economic.rs`
Mempool rules	`src/mempool.rs`
Mining helpers	`src/mining.rs`
SegWit / Taproot	`src/segwit.rs`
Optimizations	`src/optimizations.rs`

BLVM Documentation