Lesson 1 — What is a sequencer? The rollup model in 15 minutes

Question

Optimism, Arbitrum, Base, ZKsync, Linea — all run sequencers. A sequencer orders user transactions and produces L2 blocks, then posts batched data + a state-root commitment to L1. Why does this design dominate, what does it actually do, and what makes it different from a Layer-1 validator?

Principle (minimum model)

• A sequencer = an L2 block producer + an L1 poster. It accepts user transactions, orders them, builds an L2 block, executes EVM, and posts batched data plus a state root to L1.
• Three components. Mempool (collects user txs) + builder (orders them into a block) + batcher (posts compressed batches to L1).
• Why rollups dominate. L1 throughput is bounded by global consensus; rollups inherit L1 security but execute off-chain, so they can process far more transactions than L1 itself.
• Centralised vs decentralised sequencers. Most production rollups (OP / Arbitrum / Base) run a single centralised sequencer. Faster, simpler, monetisable via priority-fee/MEV. Centralisation cost: censorship resistance, single point of failure.
• Force-include / escape-hatch. Even centralised sequencers must allow users to submit txs directly to L1 to be force-included in a future batch. Trust-minimised censorship resistance even with a single sequencer.
• Shared sequencing (Espresso / Astria). A shared sequencer is one sequencer set serving multiple rollups. Trade-off: more validators to coordinate; shared MEV auctions become possible. Neither is a live shared sequencer today: Astria halted its network in December 2025, and Espresso's docs now describe it as a settlement and confirmation layer for chains that keep their own sequencers (Lesson 6).
• op-rbuilder is the main open-source Rust block builder for OP Stack. Built by Flashbots on the Reth SDK and op-reth. It runs next to the sequencer's own execution client behind rollup-boost, which lets the sequencer use externally built blocks. Lesson 3 reads it in detail.

Worked example + steps

What is a sequencer? The rollup model in 15 minutes

You send a swap on Base. It confirms in under a second. The transaction shows up in your wallet. One company — Coinbase — chose the order it landed in, executed it on their own server, and will eventually post it to Ethereum. By every conventional definition, that's a centralized system. So why is Base called a "decentralized rollup"?

This lesson is the answer. A sequencer (the entity that orders transactions on a rollup) is centralized in Base, Optimism, Arbitrum, Mantle, and almost every production L2. Decentralization is "on the roadmap" everywhere and it's been on the roadmap for years. That's not an embarrassment — it's the design.

1. The rollup model

A rollup is two things glued together:

1. An L2 execution environment — its own EVM, its own state, its own block production
2. A commitment to L1 — periodic data + state root submissions to Ethereum (or another base chain)

The sequencer's job lives in part 1. It:

• Receives user transactions
• Orders them
• Executes them on L2
• Produces L2 blocks
• Submits batches to L1

flowchart TB
    Users["L2 Users"] -->|submit tx| Seq["Sequencer<br/>(centralized)"]
    Seq -->|execute| L2["L2 chain<br/>(Reth-based execution)"]
    L2 -->|batch| Batcher["Batcher<br/>(off-chain)"]
    Batcher -->|post calldata + state root| L1["L1 (Ethereum)"]
    L1 -->|finalize after challenge| L2

The architectural payoff: a centralized sequencer doesn't put your funds at risk. If it censors you, submit the tx directly to L1's force-inclusion contract — the protocol forces the sequencer to include it on a deadline. If it lies about state, L1 contracts reject your withdrawal.

That's the rollup model's whole pitch: trust the sequencer for UX, not for funds.

2. The sequencer's three jobs

Every sequencer does three things:

For OP Stack chains, these correspond to three repos:

• op-geth / op-reth, driven by op-node: the execution + ordering (optionally with op-rbuilder as an external block builder behind rollup-boost)
• op-batcher: the batching service
• op-proposer: the state root submission service

Reth-based L2s mirror this structure. The sequencer runs Reth as its execution layer; the batcher and proposer are separate services.

The user submits the tx as a deposit to the L1 inbox contract (on OP Stack, OptimismPortal). Derivation forces it into L2 within the sequencing window: OP Mainnet's seq_window_size is 3600 L1 blocks (~12 hours) in the superchain-registry op.toml. No one has to act after the deadline; every node's derivation includes it. So censorship has a finite cost: at most about a 12-hour delay plus L1 gas fees.

3. The centralization paradox

If decentralization is the whole point, why ship centralized sequencers? Five practical reasons keep the centralized default sticky:

1. Performance: a centralized sequencer has predictable ordering. Decentralized = consensus overhead = latency.
2. MEV (maximal extractable value — the value a block builder can capture by reordering txs): a centralized sequencer controls MEV extraction. Decentralized = either give up MEV or coordinate via auctions.
3. Liveness: one operator is easier to keep online than coordinated validators.
4. Pre-confirmations: a single sequencer can promise "your tx will be included" instantly. Multi-party requires voting.
5. Operational simplicity: monitoring, on-call, deployment — all easier with one operator.

The trade-off is UX (centralized sequencer) vs censorship-resistance (decentralized). Most L2s pick UX.

OP Mainnet, Base and most other OP Stack chains run a single sequencer today. Tempo, by comparison, is an L1: its validators run Simplex BFT consensus (via Commonware) and finalize blocks themselves (tempoxyz/tempo). Hyperliquid is also an L1 with its own validator set. Neither has a rollup sequencer to decentralize.

4. The L1↔L2 communication layers

Three contracts on L1 do the work for any rollup:

The sequencer must read the Inbox every L1 block. If its batches leave out deposits, or it falls more than the sequencing window behind (~12 hours on OP Mainnet), derivation rejects those batches and builds deposit-only blocks instead; the sequencer's unsafe blocks get reorged out.

On the other direction, the sequencer submits state roots to the OutputOracle. These start a challenge period (7 days for optimistic rollups; ZK rollups have none, the state root is final once its proof verifies).

The L2 chain halts (no new unsafe blocks). User funds are safe (no state changes happening). Deposits sent to the Inbox still get in: on OP Stack, once the sequencing window (~12 hours on OP Mainnet) passes, derivation builds deposit-only blocks that include them. The exact recovery path depends on the rollup's specific contracts.

5. Where Reth fits

Reth is the execution layer for the sequencer. The sequencer runs Reth as its EL, calling Engine API to:

• forkchoiceUpdated with the new L2 head
• getPayload to fetch the built L2 block
• newPayload to validate (typically a no-op since the sequencer built it)

For OP Stack specifically: op-reth provides the OP-aware execution layer. It used to be reth's crates/optimism/; reth commit 372802d06d (PR #21532, 2026-02-06) moved it out, and it now lives in ethereum-optimism/optimism under rust/op-reth/. The sequencer's consensus process (op-node) is separate and drives it via the Engine API.

Tempo is not a rollup: it is an L1 whose validators run Simplex BFT consensus (via Commonware) on top of a Reth-based execution node (tempoxyz/tempo). The "consensus process drives Reth through an engine interface" split is the same, but there is no single sequencer and no L1 to post batches to.

6. The decentralization spectrum

Rollups exist on a spectrum:

Most chains are at position 1. Position 4 is the architectural frontier — covered in Lesson 6.

7. For your projects

Tempo (mainnet, testnet Moderato) — the L1 contrast

• No sequencer: validators propose and finalize blocks with Simplex BFT consensus (via Commonware); nodes verify finalization certificates against BLS threshold public keys built into the node (tempoxyz/tempo README)
• So there is no "centralized sequencer → decentralized" path to walk; validator-set changes play that role
• Your soltempo / mppsol code talks to Tempo RPC nodes and should treat finalized blocks as the source of truth

Tempo Zones — the anchored-confidential pattern

Worth knowing as a sequencer-architecture variant. Zones (tempoxyz/zones, now archived; zone code also lives under crates/zones/ in tempoxyz/tempo) are private blockchains anchored to Tempo: per the README, a Zone processes transactions every 250ms, keeps balances confidential, and submits batches of withdrawals to Tempo (where blocks are produced every ~500ms); once a batch is accepted and its attached proof is validated, the withdrawals are processed. TIP-403 compliance policies are mirrored from Tempo and enforced inside the Zone. The architectural takeaway: a "rollup-like" privacy chain that lives on top of an L1 you also control, with anchored finality and inherited compliance — a pattern most L2 designs don't have a name for yet.

Hypothetical "your own L2"

If you spin up a chain on OP Stack:

• You operate the sequencer (op-node + op-geth or op-reth, optionally op-rbuilder behind rollup-boost)
• You operate the batcher
• You operate the proposer
• Users trust you for liveness, L1 contracts for safety

Building this from scratch is the next 4 lessons.

8. Reading list

• Optimism docs - Sequencer architecture
• Vitalik on rollups — the foundational essay
• Astria docs — shared sequencer intro — the design write-up (the Astria network itself halted in December 2025)

9. Practice

For each chain, identify (a) sequencer position on the spectrum, (b) how a user can recover from sequencer downtime:

1. Optimism mainnet
2. Arbitrum One
3. Linea
4. Base (an OP Stack chain)
5. Contrast: Tempo and Hyperliquid are L1s with BFT validator sets. What plays the role of the sequencer there, and what is the user's recourse if validators censor?

Final check: in one sentence, why does "centralized sequencer" not mean "centralized rollup"? If your answer doesn't reference "trust for UX, not for funds," re-read §1.

Summary (3 lines)

• A sequencer = an L2 block producer + an L1 batch poster. Three components: mempool + builder + batcher. Rollups inherit L1 security but execute off-chain → far more throughput than L1.
• Most production rollups run centralised sequencers (faster, monetisable). Force-include via L1 escape-hatch preserves censorship resistance even with one sequencer.
• Decentralisation paths: sequencer sets and shared sequencers (Astria ran one until December 2025). Flashbots' op-rbuilder is the main Rust block builder for OP Stack sequencers; Lesson 3 reads it. Next: batch posting + DA.