Lesson 11 — The 6 components — what each one unlocks

Question

6 slots: Pool / Network / Executor / Consensus / Payload / Add-ons (RPC + ExEx). Each is a builder trait you can implement. What customising each one unlocks.

Principle (minimum model)

• The slots. ComponentsBuilder takes .pool(...), .network(...), .executor(...), .payload(...), .consensus(...). RPC and ExEx go in the add-ons.
• Consensus = validation rules, not the protocol. The consensus component checks headers and blocks. The protocol that orders blocks (Ethereum PoS, CometBFT, Malachite, Commonware Simplex) runs as a separate engine that drives Reth, usually over the Engine API.
• bera-reth swaps 4 of 5. Its BerachainNode sets its own pool, executor, payload and consensus builders and keeps EthereumNetworkBuilder. BeaconKit (CometBFT-based) provides consensus.
• Tempo pairs Reth with Commonware's threshold-simplex consensus and ships its own EVM, precompiles, pool and payload crates.
• OpenHL (psyto/rdk) is a Hyperliquid-shape perp L1, not Hyperliquid: Reth + Malachite BFT, with the CLOB, funding and liquidation as custom precompiles.
• Default impls. Reth provides Ethereum defaults for every slot. You replace only what your thesis needs, and the trait bounds make sure the pieces fit.

Worked example + steps

The 6 components — what each one unlocks

Tempo is building a payments L1 on Reth. Berachain ships bera-reth. OpenHL (psyto/rdk) is a Hyperliquid-shape perp L1 on Reth. None of them forked Reth — they each swapped a few of Reth's 6 components and inherited the rest. That's the SDK's whole pitch: don't rewrite a Rust EVM client, swap the parts that matter to your thesis. This lesson walks those 6 components — and shows what each swap unlocked for production chains.

The empirical proof, today:

Every chain in this table uses upstream-as-library. The customizations live entirely in their own crates.

MegaETH is left out on purpose. Its public megaeth-labs/reth fork is empty (0 ahead, 8978 behind, archived; 2026-10), but its node is closed source, so an empty public fork says nothing about how that node uses Reth.

flowchart TB
    Builder["builder · .with_types"] --> Comps[".with_components"]
    Comps --> Pool["pool — admission rules"]
    Comps --> Net["network — P2P"]
    Comps --> Exec["executor — EVM, opcodes, gas"]
    Comps --> Cons["consensus — block validation rules"]
    Comps --> Payload["payload — block building"]
    Comps --> AddOns["add-ons — RPC + ExEx"]
    AddOns --> Launch[".launch — your chain"]

The 6 components, walked

Each gets a *Builder trait — PoolBuilder, NetworkBuilder, etc. — that the SDK calls during .launch() to construct the actual subsystem.

OpenHL — a Hyperliquid-shape L1 on Reth (what it swaps)

Hyperliquid's own node is closed source and isn't built on Reth, so you can't read its component swaps. psyto/rdk, which hosts OpenHL (the reference implementation the openhl course builds), is an open Hyperliquid-shape perp L1 on Reth:

• consensus — Malachite BFT consensus instead of Ethereum PoS. It finalizes blocks and drives Reth's execution.
• executor — the order book, funding and liquidation are exposed to the EVM as custom precompiles, so contracts can read and act on CLOB state.
• everything else — Reth crates used as a library (reth-node-builder, reth-node-ethereum, … pinned by git rev).

Tempo — what they swap

Tempo's source is now public (tempoxyz/tempo — 900+★, "the blockchain for payments"). Worth knowing before you open it: their Reth fork at tempoxyz/reth is archived and 0 commits ahead, 2686 commits behind upstream Paradigm Reth (2026-10). They did not fork Reth at all. The entire payments-specific customization lives in the tempoxyz/tempo crate, which depends on upstream Reth as a library.

That's the strongest possible empirical proof of the SDK's pitch — and it tells you exactly which components Paradigm's design enabled them to swap without touching the 80% they inherit:

• pool — Payment-prioritized lanes. A merchant payment shouldn't wait behind a high-gas DeFi tx; the pool surfaces them differently.
• payload — Block construction tuned for payment-finality patterns.
• add_ons — Custom RPC namespaces for payment-specific endpoints, plus integration with the Machine Payments Protocol (their HTTP-402 layer for agent payments).
• consensus / executor — not defaults. crates/consensus is "a Tempo node using commonware's threshold simplex as consensus", and the repo ships its own crates/evm and crates/precompiles.

Adjacent novel surfaces worth knowing they shipped (not direct Reth component swaps, but enabled by the unmodified Reth dependency):

• Zones — confidential blockchains anchored to Tempo, with encrypted deposits/withdrawals and 250ms block times. Compliance policies (TIP-403) inherited from L1.
• tidx — PostgreSQL+ClickHouse hybrid indexer for hot point lookups + analytics.

The pattern: swap the parts that match your thesis, keep everything else. Tempo's thesis is fast-finality payments, so it swaps the pool and payload for payment ordering, consensus for low-latency BFT finality, and the EVM for payment precompiles. It keeps sync, storage and the RPC runtime from Reth.

Berachain (bera-reth) — what they swap

From src/node/mod.rs, BerachainNode::components_builder():

ComponentsBuilder::default()
    .node_types()
    .pool(BerachainPoolBuilder)
    .executor(BerachainExecutorBuilder)
    .payload(BasicPayloadServiceBuilder::new(BerachainPayloadServiceBuilder::default()))
    .network(EthereumNetworkBuilder::default())
    .consensus(BerachainConsensusBuilder)

• consensus — BerachainBeaconConsensus adds Proof-of-Liquidity rules on top of Ethereum's header checks: the PoL system transaction must be the first tx in the block, with the right hash. Block ordering and finality come from BeaconKit, a CometBFT-based consensus client, over the Engine API.
• executor / pool / payload — Berachain builders that understand the PoL transaction type (POL_TX_TYPE) and Berachain's header and receipt types.
• add_ons — BerachainAddOns with a Berachain EthApi builder and engine validator, so the standard eth_* RPC speaks Berachain's types.
• network — Reth's EthereumNetworkBuilder, unchanged.

berachain/bera-reth is interesting structurally too: it's not even a GitHub fork of upstream Reth — it's a fresh repo that depends on Reth crates. Even cleaner expression of "compose, don't fork" than Tempo's empty-fork pattern.

MegaETH — what you can see, and what you can't

MegaETH is an Ethereum L2 built on the OP Stack, not an L1. Per its docs (megaeth-labs/documentation, docs/architecture.md), a single sequencer produces ~10 ms mini-blocks and ~1 s EVM blocks, block data is posted to EigenDA, and the chain settles on Ethereum through OP Stack dispute resolution. Its RPC nodes report mega-reth/... from web3_clientVersion, and MegaETH's revm fork says reth is compiled against it, so the node links Reth crates. But mega-reth is closed source: which of the 6 components it replaces, and whether it patches Reth privately, is not public. What is public sits below the component slots:

• the EVM (what the executor slot wraps) — megaeth-labs/mega-evm is built on revm and op-revm (revm =40.0.3, alloy-evm =0.36.0) with MegaETH specs EQUIVALENCE through REX6. It has no Reth dependency. Hooks revm doesn't expose (multi-dimensional gas, gas kept on halt) live in a thin fork, megaeth-labs/revm.
• state commitment — SALT (Small Authentication Large Trie) is MegaETH's authenticated KV store in place of Ethereum's Merkle Patricia Trie. Per its README, the authentication layer for up to 3 billion items needs only about 1 GB of memory, and state-root updates need no random disk I/O. Nothing public says it replaces MDBX itself (its storage backend sits behind a trait), and it isn't one of the standard 6 component slots.
• validators run a different binary — megaeth-labs/stateless-validator verifies blocks statelessly using SALT witnesses and a vanilla revm executor, so validators need a fraction of sequencer hardware. It is not a Reth node: its only Reth crates are reth-ethereum-forks (paradigmxyz/reth v2.3.0) and reth-optimism-chainspec (from the Optimism monorepo).

What MegaETH teaches here is the layer under the SDK: a chain can customize the EVM at the revm level and build a validator from revm, alloy-evm and two Reth crates, with no node builder at all. It is not evidence about the SDK's ceiling. With the node closed, any statement about which Reth components MegaETH swaps is inference. (The stateless-validator README mentions a "hyper-optimized, parallel, JIT-compiled executor on sequencer nodes"; there is no public code for it.)

The pattern: swap what your thesis demands

If you can articulate your chain's thesis in one sentence, you can usually map it to 1–3 component swaps:

🔍 Find in repo. Open EthereumNode::components()'s definition. The default builders for each component are listed there — that's the menu of "what comes for free."

What stays constant: the load-bearing 80%

The components you don't swap are the bulk of the value:

• Sync orchestrator (the Stage pipeline you read in Module 1)
• MDBX schema and storage layer
• Header download, sender recovery, hashing, Merkle, indexes
• JSON-RPC server runtime, engine API server
• Tokio runtime, tracing, metrics

This is why "compose, don't fork" is the only viable maintenance story for an L1 you intend to run for years. Paradigm's updates flow into the 80%; your fork-shaped surface area stays in the 20% you wrote.

Recall before the quiz

Without scrolling:

1. Of the 6 components, which does a Hyperliquid-shape perp L1 like OpenHL most heavily customize, and why?
2. Why is pool the right component to swap for payments-priority, not consensus?
3. What's the maintenance argument for "compose, don't fork"?
4. Sketch the minimum set of components you'd swap to ship a privacy-focused L1.

The next lesson is a quiz. Engage with these recalls now if any answer is shaky.

Summary (3 lines)

• 6 slots: pool / network / executor / consensus / payload / add-ons. Ethereum defaults for all; replace selectively. consensus = validation rules; the ordering protocol runs outside and drives Reth.
• bera-reth (pool, executor, payload, consensus + BeaconKit/CometBFT) / Tempo (Commonware Simplex + own EVM, pool, payload) / OpenHL (Malachite + CLOB precompiles).
• Type-system composition. Next: quiz.