Skip to content
← Reth Expert — Production Engineering
Reth-based Chains — Reading the Extension Pattern
Lesson 23 of 25·CONTENT18 min50 XP
Course
Reth Expert — Production Engineering
Lesson role
CONTENT
Sequence
23 / 25

Lesson 22 — Case study — alphanet, Tempo, MegaETH, and reading Reth-based L1s in the wild

Question

Paradigm's stack = alphanet (its 2024 testbed, now archived) + Tempo (production) + reusable patterns. Read the architecture choices.

Principle (minimum model)

  • alphanet (historical). Paradigm's 2024 research testnet for experimental EIPs. Archived; it moved to Ithaca's Odyssey (ithacaxyz/odyssey), which has had no pushes since 2025-07.
  • Tempo. Production-grade payment rail. Stable coin + machine payment + custom precompiles.
  • Pattern: library-first. Both alphanet and Tempo used/use Reth as a library, not a fork. Track upstream.
  • Pattern: explicit customisation. Document every diff from mainnet. Tempo's chainspec + precompiles + pool are all documented.
  • Pattern: production discipline. Continuous monitoring + chaos drills + bug bounty + rapid response.
  • Pattern: external partnerships. Tempo's docs list bridge partners (Across, Chainlink CCIP, LayerZero/Stargate, Relay and others), and the Machine Payments Protocol is co-authored with Stripe.
  • Pattern: open-source. Paradigm publishes architectures + code. Lowers integration cost for ecosystem.
  • Why this matters. Reth's core maintainers are also among the top contributors to tempoxyz/tempo, so Tempo shows how the people who design the SDK use it.

Worked example + steps

Case study — Paradigm's stack: alphanet, Tempo, and the L1 pattern

You've now seen the four extension slots (ChainSpec, executor, payload builder, RPC) and the dependency shape of a Reth-based chain. This lesson is the synthesis: what does Paradigm's full stack look like, and now that Tempo's source is public, how do you read it against the structure you just learned?

1. The stack, top to bottom

LayerComponentWhat it does
EVM corerevmThe byte-level EVM interpreter
ToolkitalloyRust types, providers, signers, ABI
Execution clientrethFull Ethereum node — staged sync, mempool, RPC, MDBX, P2P
Reth-based chainop-reth (ethereum-optimism/optimism, rust/op-reth; reth's crates/optimism/ until Feb 2026)OP Stack execution as a reth node crate
R&D testnet (historical)alphanet → Odyssey"What if Ethereum had EIP-X precompile?" playground — archived / inactive
Production L1TempoPayments L1 built on the Reth SDK

Every layer below depends only on the layers above it. That's the architectural invariant. Tempo doesn't fork reth — it builds on reth.

2. alphanet — the precompile R&D playground (historical)

Status: paradigmxyz/alphanet is archived. Its last commit is from 2024-10-19 and its README says it "has been moved to Odyssey and is no longer being maintained". Odyssey (Ithaca) has had no pushes since 2025-07. Treat both as history, not as a live testnet.

alphanet was an OP-Stack testnet rollup (its README notes it never ran a public testnet; you ran it locally with --dev). Its explicit purpose: try EVM extensions before they exist on mainnet — and, per its README, it was "not a fork of reth": it implemented node-builder traits instead.

What alphanet implemented (README + commit history):

  • EIP-7702 — set EOA account code
  • EIP-7212 / RIP-7212 — secp256r1 (P-256) verification precompile (relevant for WebAuthn / Passkeys)
  • EIP-2537 — BLS12-381 precompiles
  • EOF (EVM Object Format) EIPs
  • EIP-3074 AUTH/AUTHCALL instructions — experimented with early, then removed (PR #97)

Why it is still worth a look as a learning target: the repo is small (crates/node, crates/precompile, crates/wallet, crates/testing) and shows the trait-based extension pattern in miniature. But it pins 2024-era reth APIs that have since changed, so read it for the shape, not for code you can copy.

3. From alphanet to production

What happened to alphanet's experiments is the useful part of the story:

  • EIP-7702 and EIP-2537 shipped on Ethereum mainnet in Prague (Pectra).
  • P-256 verification shipped on OP Stack chains at Fjord (RIP-7212) and on Ethereum mainnet in Osaka (Fusaka, EIP-7951) — revm's Osaka precompile set includes P256VERIFY_OSAKA.
  • EIP-3074 was dropped in favour of 7702; EOF did not ship in Prague or Osaka.

So an R&D testnet is a leading indicator for EIPs, not a roadmap for any particular production chain. alphanet is not a way to predict Tempo — Tempo's own source and specs are.

4. Tempo — Paradigm's payment L1 on Reth

Now public, and the structure validates the entire thesis of this module:

  • tempoxyz/tempo (1,000+★ as of 2026-10, Rust) — "the blockchain for payments." This is the L1 node crate.
  • tempoxyz/reth — 0 commits ahead, 2686 commits behind (2026-10) upstream Paradigm Reth. They did not fork Reth. Tempo depends on upstream Reth as a library. This is the textbook example of "compose, don't fork."
  • Tempo Moderato is the public testnet.
  • Bridges: Tempo's docs (partners/bridges) list Chainlink CCIP alongside Across, LayerZero/Stargate, Relay and others.

Adjacent crates shipped alongside the L1:

  • tempoxyz/zones — confidential blockchains anchored to Tempo. Confidential balances and transactions; a Zone processes txs every 250ms and batches withdrawals to Tempo (~500ms blocks); TIP-403 compliance inherited from L1. Testnet only (README).
  • tempoxyz/mpp-specs — Machine Payments Protocol: an HTTP-402-based payment protocol for agent/machine transactions. IETF draft, co-authored by Tempo and Stripe. Payment-method-agnostic core with per-method extensions.
  • tempoxyz/tempo-foundry — a custom Foundry fork (repo description: "Temporary fork of Foundry with Tempo support"). Unlike the node, this one is a fork.
  • tempoxyz/tidx — hybrid PostgreSQL + ClickHouse indexer (OLTP point lookups + OLAP analytics).

What you find when you open tempoxyz/tempo, matching what you just learned:

  • Custom ChainSpec and hardforks (crates/chainspec/, crates/hardfork/)
  • Custom executor (crates/evm/) plus payment precompiles (crates/precompiles/): TIP-20 tokens, TIP-403 policy registry (regulated-asset checks), fee manager, stablecoin DEX. No FX-rate or settlement-attestation precompile; on-chain FX is listed as "coming soon".
  • Custom payload builder (crates/payload/builder/) that reserves block space for payment txs via a separate general_gas_limit for everything else
  • Custom RPC namespaces (crates/node/src/rpc/): tempo_forkSchedule, tempo_simulateV1, token_*, consensus_*
  • Custom pool (crates/transaction-pool/): tip ordering, an address filter, and a 2D-nonce sub-pool. The testnet has a public RPC; nothing in the code points to a private mempool.
  • Custom consensus (crates/consensus/): Simplex BFT via Commonware

What to verify is absent (because the SDK lets it be absent):

  • A divergent fork of reth core (confirmed — Cargo.toml pins paradigmxyz/reth crates by git rev, and the tempoxyz/reth fork is 0 commits ahead)
  • A bespoke EVM implementation (revm is the EVM)
  • A custom execution-layer networking stack (reth's P2P is reused; consensus messages go over Commonware's own networking in crates/consensus/)

5. MegaETH — an independent chain, read through what is public

MegaETH is megaeth-labs, an independent company — not Paradigm-affiliated — and an Ethereum L2 built on the OP Stack, not an L1 (its docs, docs/architecture.md in megaeth-labs/documentation: ~10 ms mini-blocks, block data on EigenDA, settlement on Ethereum via OP Stack dispute resolution). It is a useful contrast to Tempo for a different reason than "deeper SDK use": it shows how far the public evidence goes, and where it stops.

  • The node is closed. 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. Its source is not public. megaeth-labs/reth is an empty, archived GitHub fork (0 ahead, 8978 behind; 2026-10), which says nothing about what the private node does.
  • megaeth-labs/mega-evm — custom EVM built on revm + op-revm (revm =40.0.3, alloy-evm =0.36.0) with MegaETH-specific specs (EQUIVALENCE through REX6). No Reth dependency. A thin fork, megaeth-labs/revm, adds hooks revm doesn't expose. The stateless-validator README describes a "hyper-optimized, parallel, JIT-compiled executor on sequencer nodes"; that executor has no public code.
  • megaeth-labs/salt — replaces the MPT as the state commitment; nothing public says it replaces MDBX. ~1 GB of memory authenticates 3 B items; random disk I/O during state-root updates is eliminated. This is outside the standard 6 component slots.
  • megaeth-labs/stateless-validator — a different validator binary entirely, separate from the sequencer. Reads SALT witnesses, runs blocks against a vanilla revm interpreter, fits on commodity hardware. It is not a Reth node: its only Reth crates are reth-ethereum-forks (paradigmxyz/reth v2.3.0) and reth-optimism-chainspec (Optimism monorepo).

The point of putting MegaETH next to Tempo: Tempo's claim is checkable, MegaETH's is not. Tempo's Cargo.toml pins upstream Reth and you can read every swapped component. For MegaETH you can read the revm-level EVM, the state commitment and the validator, but how its node composes Reth (SDK components, a private fork, or both) is inference until that source is published.

6. The L1 vs L2 distinction in the extension model

Reading op-stack-on-reth and (eventually) reading tempo-on-reth will look structurally similar but differ in:

AspectOP Stack (L2)Tempo (L1)
Deposit txsYes (from L1)No
L1 cost chargeYesNo
L1 block oracle slotYesNo
Standalone consensusNo (anchored to L1)Yes (Simplex BFT via Commonware)
Sequencer modelSingle sequencerNo sequencer — a validator set produces blocks
Fee assetETHUSD stablecoins (TIP-20), converted via the Fee AMM

The L1-ness of Tempo means the consensus layer is also a customization point, not just the execution layer. That's a slot most L2 chains skip.

7. Why this matters for what you ship

If you are building on top of Tempo:

ProjectWhy Reth-on-Tempo knowledge matters
Cross-VM intent matcherIntent matching needs deterministic EVM semantics. Reading Tempo's executor crate tells you exact gas costs, precompile availability, and execution edge cases.
Cross-chain settlement layerSettlement proofs on the EVM side must match Tempo's state exactly. Reading Tempo's chainspec and executor gives you the source of truth.
Merchant treasury / payment opsMerchant operations need predictable confirmation semantics. Tempo's payload builder + mempool policy tells you when a tx becomes inclusion-final.

You are well ahead of anyone integrating with Tempo who hasn't read reth at the trait level.

8. Final practice

The deliverable for this module: open tempoxyz/tempo and write a 1-page architectural summary in a single sitting by reading:

  1. The Tempo node crate's Cargo.toml — confirm the reth dependency is upstream and unforked
  2. The chainspec crate — hardforks + precompile schedule
  3. The NodeBuilder composition (crates/node/src/node.rs) — which of the 6 components are swapped, which inherit
  4. Each swapped crate in order — payload, pool, RPC namespace
  5. The tests directory — what behaviors did they care enough about to assert?

If you want a smaller warm-up first, the archived alphanet repo shows the same trait-based pattern in a few crates — but on 2024-era reth APIs.

Final check: write 5 specific things you verified by reading tempoxyz/tempo source, ranked by importance for your own work. If you can't list 5, this module hasn't fully landed — re-read sections 4 and 5, then go back to the source.

Summary (3 lines)

  • Paradigm stack = alphanet (2024 testbed, archived) + Tempo (prod) + library-first Reth + explicit customisation + production discipline.
  • Patterns: library-first / explicit-diff documentation / external partnerships (bridges such as CCIP, LayerZero, Across; MPP with Stripe) / open-source.
  • Reth's core maintainers are also top Tempo contributors — Tempo is the SDK used by the people who design it. Next: quiz.