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

Question

Paradigm's stack = alphanet (testbed) + Tempo (production) + reusable patterns. Read the architecture choices.

Principle (minimum model)

• alphanet. Paradigm's research-grade testnet. Experiments live here before production.
• Tempo. Production-grade payment rail. Stable coin + machine payment + custom precompiles.
• Pattern: library-first. Both alphanet + Tempo use Reth as a library. 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. Chainlink CCIP for cross-chain. Worldcoin for IDs. Builds composition.
• Pattern: open-source. Paradigm publishes architectures + code. Lowers integration cost for ecosystem.
• Why this matters. Paradigm is the modal contributor to Reth + Revm + Alloy + openhl + Tempo + many more. Their stack = the de-facto standard.

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

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

paradigmxyz/alphanet is an OP-Stack-compatible testnet rollup. Its explicit purpose: try EVM extensions before they exist on mainnet.

Examples of what alphanet has shipped or experimented with:

• EIP-7212 — secp256r1 (P-256) verification precompile (relevant for WebAuthn / Passkeys)
• EIP-3074 / 7702 — account abstraction primitives
• Various opcode and gas tweaks

Why this matters as a learning target: alphanet is small enough to read end-to-end, and the customizations are educational by design. It's the cleanest "how do I add a precompile to a chain" example in the wild.

3. From alphanet to production

The trajectory matters: alphanet is where Paradigm tries things, and then either:

• The experiment graduates into mainnet Ethereum as an EIP (e.g., 7212 is on the path), or
• The experiment graduates into a production Reth-based chain (e.g., Tempo)

If you want to predict what Tempo has, look at what's been validated in alphanet recently. The technical lineage is direct.

4. Tempo — Paradigm's payment L1 on Reth

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

• tempoxyz/tempo (900+★, Rust) — "the blockchain for payments." This is the L1 node crate.
• tempoxyz/reth — 0 commits ahead, 1374 commits behind 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.
• Chainlink CCIP is the cross-chain rail (CCTP doesn't cover Tempo).

Adjacent crates shipped alongside the L1:

• tempoxyz/zones — confidential blockchains anchored to Tempo. Encrypted deposits/withdrawals, 250ms block time, compliance (TIP-403) inherited from L1.
• tempoxyz/mpp-specs — Machine Payments Protocol: an HTTP-402-based payment protocol for agent/machine transactions. IETF draft. Payment-method agnostic (Tempo, Stripe, ACH).
• tempoxyz/tempo-foundry — Foundry fork with Tempo support (also a thin fork, same compose-don't-fork pattern).
• tempoxyz/tidx — hybrid PostgreSQL + ClickHouse indexer (OLTP point lookups + OLAP analytics).

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

• Custom ChainSpec with Tempo-specific forks and precompile schedule
• Custom executor with payment-specific precompiles (FX rate read, settlement attestation, regulated-asset checks)
• Custom payload builder with merchant-aware ordering and rate-limiting
• Custom RPC namespace (tempo_* methods) for merchant/payment endpoints, plus integration with the Machine Payments Protocol
• Custom mempool policy — likely private mempool at launch, restricted to authorized submitters

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

• A divergent fork of reth core (confirmed — the fork is empty)
• A bespoke EVM implementation (revm is the EVM)
• A custom networking stack (reth's P2P is reused)

5. MegaETH — same pattern, deeper customization (independent of Paradigm)

MegaETH is megaeth-labs, an independent company — not Paradigm-affiliated. That's precisely what makes it the strongest comparison case for the extension model: the SDK pattern survives outside Paradigm's own portfolio. If Tempo shows the shallow end of the SDK (swap a few components, keep everything else), MegaETH shows the deep end:

• megaeth-labs/reth — empty fork (0 commits ahead, 7666 commits behind). Same compose-don't-fork pattern as Tempo, just further out of sync.
• megaeth-labs/mega-evm — custom EVM built on revm + op-revm with MegaETH-specific specs (EQUIVALENCE through REX4). The sequencer runs JIT/AOT compiled execution via Paradigm's revmc.
• megaeth-labs/salt — they replaced MDBX with a custom authenticated KV store. ~1 GB of memory authenticates 3 B items; random disk I/O during state-root updates is eliminated. This goes far past 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. The architectural move: separate the high-spec sequencer from low-spec validators by giving them entirely different node code.

The point of putting MegaETH next to Tempo in this lesson: the SDK doesn't constrain how deep you customize. Tempo swaps three components and inherits ~80% of upstream. MegaETH swaps the EVM executor, replaces the storage layer, and ships an entirely separate validator client — and still does not fork Reth (megaeth-labs/reth: 0 ahead, 7666 behind). The ceiling is much higher than first reading suggests.

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:

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:

You are months ahead of anyone who shows up at Tempo's launch without having 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 (likely in node/src/lib.rs or similar) — 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've never read alphanet end-to-end, do that first as practice — it's smaller and cleaner.

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 (testbed) + Tempo (prod) + library-first Reth + explicit customisation + production discipline.
• Patterns: library-first / explicit-diff documentation / external partnerships (CCIP, Worldcoin) / open-source.
• Paradigm is modal contributor to Reth / Revm / Alloy / openhl / Tempo. Their stack = de-facto standard. Next: quiz.