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
| Layer | Component | What it does |
|---|---|---|
| EVM core | revm | The byte-level EVM interpreter |
| Toolkit | alloy | Rust types, providers, signers, ABI |
| Execution client | reth | Full Ethereum node — staged sync, mempool, RPC, MDBX, P2P |
| Reth-based chain | op-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 L1 | Tempo | Payments 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/AUTHCALLinstructions — 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 separategeneral_gas_limitfor 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.tomlpinsparadigmxyz/rethcrates by git rev, and thetempoxyz/rethfork 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/...fromweb3_clientVersion, and MegaETH's revm fork saysrethis compiled against it, so the node links Reth crates. Its source is not public.megaeth-labs/rethis 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 (EQUIVALENCEthroughREX6). 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 arereth-ethereum-forks(paradigmxyz/rethv2.3.0) andreth-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:
| Aspect | OP Stack (L2) | Tempo (L1) |
|---|---|---|
| Deposit txs | Yes (from L1) | No |
| L1 cost charge | Yes | No |
| L1 block oracle slot | Yes | No |
| Standalone consensus | No (anchored to L1) | Yes (Simplex BFT via Commonware) |
| Sequencer model | Single sequencer | No sequencer — a validator set produces blocks |
| Fee asset | ETH | USD 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:
| Project | Why Reth-on-Tempo knowledge matters |
|---|---|
| Cross-VM intent matcher | Intent matching needs deterministic EVM semantics. Reading Tempo's executor crate tells you exact gas costs, precompile availability, and execution edge cases. |
| Cross-chain settlement layer | Settlement 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 ops | Merchant 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:
- The Tempo node crate's
Cargo.toml— confirm the reth dependency is upstream and unforked - The chainspec crate — hardforks + precompile schedule
- The NodeBuilder composition (
crates/node/src/node.rs) — which of the 6 components are swapped, which inherit - Each swapped crate in order — payload, pool, RPC namespace
- 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/temposource, 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.