Lesson 6 — Decentralization paths — shared sequencers and MEV-aware auctions

Question

Most production rollups (OP / Arbitrum / Base) run a single centralised sequencer. Decentralisation roadmaps exist, but the design space is contested. What are the shared-sequencer designs, what trade-offs do they make, and what does MEV-aware auctioning look like in this world?

Principle (minimum model)

• Three decentralisation paths. (1) PoS sequencer rotation (sequencer set rotates every N blocks, like L1 validators). (2) Shared sequencers (one sequencer set serves multiple rollups — Espresso / Astria / Aori). (3) Sealed-bid sequencer auctions per-block.
• Espresso. Multi-chain shared sequencer with HotShot consensus. Several L2s use it for ordering; each L2 still executes independently. Cross-rollup atomicity becomes possible.
• Astria. Similar to Espresso but with Tendermint consensus. Focused on simpler integration with existing rollups.
• Aori. Sealed-bid order-flow auctions. The sequencer right is auctioned per block; the highest bidder gets to order txs. MEV is monetised explicitly.
• Shared sequencer benefits. Censorship resistance (multiple operators); cross-rollup atomic execution; MEV redistribution; simpler decentralisation (re-use the validator set).
• Shared sequencer trade-offs. More coordination overhead; new trust assumption (the shared sequencer set); potential for shared sequencer to censor specific rollups.
• MEV-aware design. The sequencer can choose tx ordering; MEV-aware sequencing makes this explicit (bidding on inclusion order). PBS (Proposer-Builder Separation) decouples block ordering from block proposing, like Ethereum L1.
• The reality check. Most decentralisation roadmaps are 12-36 months out. Centralised sequencers remain dominant in 2026; force-include via L1 is the working compromise.

Worked example + steps

Decentralization paths — shared sequencers and MEV-aware auctions

Optimism announced "we will decentralize the sequencer" in 2023. Three years later, the sequencer is still one box at OP Labs. Arbitrum says the same. So does Base. The decentralization roadmap is real — and it's the second half of the L2's life. Two architectural patterns are competing to be the destination: decentralized sequencer set (chain runs its own validators) and shared sequencer (multiple rollups outsource ordering to a common set).

This lesson is the map. Why is decentralization stuck? What does each path actually look like? Which one are Espresso, Astria, Polygon zkEVM, and Linea betting on, and why?

1. The decentralization stages

The path is not strictly linear — some chains skip stages. Some adopt shared sequencers directly from centralized. Some stay centralized indefinitely.

2. Why decentralization is hard

Five real problems:

2.1 Latency

Centralized: 100ms block production possible. Decentralized: minimum 2-3 round trips for consensus → 200-500ms even at best.

Users feel this. Centralized sequencer offers pre-confirmations in <100ms. Decentralized struggles to do this.

2.2 MEV coordination

Centralized: one MEV strategy. Decentralized: who gets MEV? Random rotation? Bidding? Each design has trade-offs.

2.3 Liveness

Centralized: 1 operator = single failure point but easy to monitor. Decentralized: N operators = no single failure but coordination overhead. Liveness during network issues is genuinely harder.

2.4 Cost

Centralized: ~1 server. Decentralized: ~N servers + consensus protocol + slashing infrastructure.

2.5 Economic security

Centralized: trust the operator. Decentralized: need staking, slashing, dispute resolution.

Each barrier has been solved separately, but integrating all 5 is the systems challenge.

3. PoS sequencer set — the natural extension

The first decentralization step: replicate Ethereum-style PoS on L2.

flowchart TB
    Stake["Validators stake L2 token"] --> Set["Active validator set (M-of-N)"]
    Set -->|each block| Leader["Designated leader (rotation)"]
    Leader -->|build block| Reth["Reth EL"]
    Reth -->|signed block| Others["Other validators"]
    Others -->|2f+1 votes| Final["Block finalized"]
    Final -->|periodic batch| L1["L1"]

This is what Polygon zkEVM is moving toward (Hermez-style validator set), what Linea is approaching (Consensys-coordinated), what most "Stage 3" rollups end up doing.

The trade-off: you go from 1 operator to ~10-30 operators. Increment in trust minimization; massive increment in operational complexity.

4. Shared sequencers — the architectural bet

What if N rollups didn't each need their own decentralized sequencer set — what if they all shared one? That's the shared sequencer bet: a single sequencer set serves multiple rollups. Each L2 keeps its own Reth execution layer, but the ordering happens in a shared validator set.

flowchart TB
    Rollup1["L2 A<br/>(Reth-based)"] -.->|outsource ordering| Shared["Shared Sequencer<br/>(Espresso / Astria)"]
    Rollup2["L2 B<br/>(another OP Stack)"] -.->|outsource ordering| Shared
    Rollup3["L2 C<br/>(yet another)"] -.->|outsource ordering| Shared
    Shared -->|signed block| Reth1["Reth EL A"]
    Shared -->|signed block| Reth2["Reth EL B"]
    Shared -->|signed block| Reth3["Reth EL C"]

Why this matters:

1. Cross-rollup atomicity: a tx on L2 A can atomically depend on a tx on L2 B (because the same sequencer orders both)
2. Lower decentralization cost: 1 validator set serves N rollups instead of N validator sets
3. MEV unification: cross-rollup MEV can be captured (helping rollups, hurting traders)
4. Faster Decentralization: rollups can outsource the hard problem

Production attempts:

Shared sequencers sacrifice:

• Sovereignty: your chain depends on an external party for ordering
• Speed of upgrades: shared sequencer must support your chain's needs
• Custom MEV strategy: harder to extract chain-specific MEV
• Operational independence: if shared sequencer goes down, your chain stops

Single sequencer keeps these. The trade is: you control more, but you trust yourself more.

5. The MEV-aware decentralized future

The endgame: decentralized sequencer with MEV auctions.

How it could work:

1. Multiple sequencers compete to build the next block
2. Builders construct proposed blocks with extracted MEV
3. Sequencer set votes/auctions on best block
4. Winner pays sequencer set for blockspace; sequencer set distributes MEV

This is MEV-Boost for L2s. Not deployed in production yet (2026), but designs from Flashbots, Espresso, and others target this.

For Tempo: if it decentralizes, the MEV question is interesting because merchant payments have low MEV opportunity (mostly genuine txs, not arbitrage). Tempo could decentralize without much MEV-extraction complexity.

For Hyperliquid: the orderbook is essentially MEV — they likely keep centralized sequencer indefinitely.

6. Reading Astria — production shared sequencer

astriaorg/astria is the production shared sequencer with Reth integration. Key components:

• Sequencer network: CometBFT-based validator set
• Composer: aggregates rollup txs for inclusion
• Rollup nodes: Reth-based, consume sequencer outputs

The flow:

1. User submits tx to L2 A's RPC
2. RPC forwards to Astria sequencer
3. Astria sequences (with txs from L2 B, C, etc.)
4. Astria emits ordering; each Reth rollup picks its own txs

This is the most-tested shared sequencer architecture in production. Worth reading for the patterns.

🔍 Find in repo. Open Astria's docs.astria.org and trace what an L2 needs to do to "subscribe" to Astria sequencing.

7. The pre-confirmation race

A new direction (2025-2026): pre-confirmations from sequencers, allowing instant UX even before full sequencing.

Multi-sequencer pre-conf models:

• TACo (Threshold): requires majority of sequencers to commit
• Lighthouse-style: one sequencer commits, others verify before finality
• Speculative: sequencer commits, fraud-proof if violated

This is the active R&D area in 2026 — solving the "decentralized but fast" problem.

8. For my projects

Tempo Moderato → Tempo mainnet

Path:

• Today: centralized
• 1 year: PoS sequencer set (~20-30 validators)
• 2-3 years: maybe shared sequencer (if economics work)
• Always: ZK proofs eventually for fast withdrawals

mppsol / soltempo

Interacting with Tempo's sequencer is your interface point. As Tempo decentralizes:

• Pre-confirmations become harder (multi-party)
• Liveness alarms become more nuanced
• Your code needs to handle "sequencer changed" events

Hyperliquid

Likely stays centralized for the foreseeable future. Their MEV model doesn't suit decentralization. Their bridge will probably decentralize before their sequencer.

9. Practice

1. Read Astria's sequencer documentation
2. Compare to Espresso's design — what's different?
3. Identify: what makes shared sequencers harder for chains with custom MEV models?
4. Sketch: how would Tempo eventually decentralize?

10. Reading list

• Astria docs — shared sequencer intro — design philosophy
• Espresso docs
• Astria

Final check: in one sentence, what's the fundamental architectural choice between decentralized sequencer set (your chain owns it) and shared sequencer (outsource it)? If your answer doesn't reference "sovereignty vs efficiency," re-read §4.

Summary (3 lines)

• Three decentralisation paths: PoS rotation (like L1 validators) + shared sequencers (one set / multiple rollups — Espresso / Astria / Aori) + sealed-bid sequencer auctions (Aori).
• Shared sequencers enable cross-rollup atomicity + MEV redistribution; trade-off is coordination overhead and new trust set. Most are 12-36 months out.
• In 2026, centralised sequencers remain dominant. Force-include via L1 is the working compromise. Final quiz tests recall across all six lessons.