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. 10 K+ TPS becomes feasible.
• 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.
• Decentralisation roadmaps (Espresso / Astria / Aori). Shared sequencers — a single sequencer set serves multiple rollups. Trade-off: more validators to coordinate; shared MEV auctions become possible.
• Reth's op-rbuilder is the canonical Rust sequencer. Built by Flashbots on top of Reth SDK, powers OP-Reth nodes. 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-rbuilder (or op-geth): the execution + ordering
• 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 to the L1 inbox contract (e.g., OptimismPortal). The sequencer is forced (by protocol rules) to include that tx within a deadline (~1 hour for OP Stack). After that deadline, anyone can force the inclusion. So censorship has a finite cost — at most a 1-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.

Tempo Moderato (Tempo's testnet) is centralized today. Hyperliquid is centralized as well. Both will likely decentralize eventually, but not at launch.

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 it ignores deposits or force-included txs for more than the deadline (~1 hour), the sequencer is falling behind and can be challenged.

On the other direction, the sequencer submits state roots to the OutputOracle. These start a challenge period (7 days for optimistic rollups, instant for ZK rollups).

The L2 chain halts (no new blocks). User funds are safe (no state changes happening). After 2 hours: depositors who submitted via Inbox can force their txs once any "escape hatch" mechanism kicks in. The exact recovery 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: crates/optimism/ in reth provides the OP-aware execution layer. The sequencer is a separate process that drives Reth via Engine API.

For Tempo: similar pattern. Reth runs as execution; a Paradigm-built sequencer drives it.

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 Moderato → Tempo mainnet

• Today: centralized sequencer (Paradigm operates it)
• Decentralization path likely: multi-operator → PoS → eventually maybe shared
• Your soltempo / mppsol code interacts with the sequencer's RPC, treats it as the chain's source of truth

Tempo Zones — the anchored-confidential pattern

Worth knowing as a sequencer-architecture variant. tempoxyz/zones are private blockchains anchored to Tempo: a Zone runs its own sequencer with 250ms block time, processes confidential transactions (encrypted balances and recipients), and submits batched withdrawals back to Tempo every Tempo block (~500ms). Compliance policies (TIP-403) are inherited from Tempo L1 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 (cargo run op-rbuilder)
• 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 future direction

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. Polygon zkEVM
4. Tempo Moderato (per public info)
5. Hyperliquid

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 → 10 K+ TPS.
• Most production rollups run centralised sequencers (faster, monetisable). Force-include via L1 escape-hatch preserves censorship resistance even with one sequencer.
• Decentralisation paths: shared sequencers (Espresso / Astria / Aori). Reth's op-rbuilder (built by Flashbots) is the canonical Rust sequencer; Lesson 3 reads it. Next: batch posting + DA.