Skip to content

Crate Reference

The base/base Cargo workspace splits into 8 top-level crate groups. Each group owns a domain of the Base Reth Node and contains its own set of sub-crates.

Crate GroupSub-cratesPurpose
alloy8Alloy type extensions for Base (consensus types, RPC types, EVM, hardforks)
builder3Block building, flashblock production, and metering
client7Node client — CLI, engine, flashblocks integration, metering, RPC
consensus15OP Stack consensus — derivation, gossip, P2P, sequencing (Kona-based)
execution14Execution layer — EVM, chainspec, payload building, storage, txpool
infra7Infrastructure tooling — basectl, ingress RPC, WebSocket proxy
proof7Fault proof system — FPVM, preimage oracle, proof driver (Kona-based)
shared9Shared utilities — primitives, access lists, JWT, bundles, CLI utils

Crate names in Cargo.toml follow these patterns:

  • base-* — Core Base crates (e.g., base-primitives, base-flashblocks, base-builder-core)
  • kona-* — Consensus and proof crates derived from the Kona project (e.g., kona-derive, kona-proof)
  • Infrastructure — Named after their binary or function (e.g., based, basectl-cli, ingress-rpc-lib)

At a high level, dependencies flow in this direction:

shared, alloy (foundation types)
execution (EVM, state, txpool)
client (node assembly, CLI, RPC)
builder (block building, flashblocks)
consensus (independent OP Stack consensus)
proof (independent fault proof system)
infra (infrastructure binaries, depends on various crates)

The shared and alloy crates provide foundational types used throughout the workspace. The execution crates build on these to implement the EVM and state management. The client crates assemble the full node, and the builder crates handle block production.

The consensus and proof crate groups are relatively independent — they implement the OP Stack consensus protocol and fault proof system respectively, with their own internal dependency chains.

All crates live under crates/ in the repository.