Ethereum L2 sequencers — covered for each major chain in the L2 comparison guide — order transactions, build blocks, and post batches to L1 — and as of April 2026, every major L2 still runs a centralized sequencer operated by a single entity. Arbitrum, Base, OP Mainnet, zkSync Era, Linea, and Scroll each rely on one operator (or one organization's cluster) to handle ordering. This is the largest unresolved decentralization gap in rollup design, and the roadmaps for fixing it diverge sharply across teams.
This article explains what sequencers actually do, why decentralization is hard, what decentralization roadmaps look like across major L2s, and what the practical implications are for builders. The TL;DR: centralized sequencing cannot steal funds (the proof system prevents that), but it can censor or delay transactions. For most applications this is acceptable today; for treasury-grade or compliance-sensitive flows, it deserves explicit handling.
What Does an L2 Sequencer Do?
A sequencer performs four functions in a typical rollup:
Transaction ordering. Receives transactions from users via JSON-RPC, decides their order in the next block, and produces a soft confirmation within milliseconds to seconds. The order is significant — it determines MEV, gas pricing, and contract execution outcomes.
Block building. Assembles ordered transactions into blocks, executes them against the L2 state, and produces a new state root. This happens off-chain, with no L1 interaction yet.
Batch posting. Compresses recent blocks into a batch and posts them to Ethereum L1 as EIP-4844 blob data, typically every 60–120 seconds. This is the data-availability commitment — once posted, the batch is publicly readable.
State root proposal. Submits a Merkle root of the new L2 state to the rollup's L1 contracts. For optimistic rollups, this starts the 7-day fraud-proof window. For ZK rollups, the prover then generates a validity proof to attach.
The first three are real-time critical. If the sequencer goes offline, users cannot submit transactions and the chain effectively halts. State root proposal can lag without immediate user impact.
Why Decentralization Is Hard
Decentralizing sequencing has three challenges that each L2 team handles differently.
Latency. Centralized sequencers achieve sub-second confirmation because one operator decides ordering in one place. A multi-operator system needs consensus on order, which adds round-trip latency. Most L2 users have come to expect 1–2 second confirmations; degrading to 5–15 seconds (typical for early decentralized sequencing designs) is a UX regression.
MEV capture. The sequencer earns transaction-priority fees and any MEV from ordering decisions. On Base, this revenue runs $4–8M monthly; on Arbitrum, several million per month. Distributing this revenue fairly across multiple operators while preventing collusion is non-trivial.
Liveness guarantees. A centralized sequencer can be paused with one decision. A decentralized set requires Byzantine-fault-tolerance assumptions — can the system tolerate operators going offline, equivocating, or being attacked? Most BFT systems require 2/3 honest participation, which means at least 4 operators in a 7-node set or similar.
Decentralization Roadmaps by Chain
Arbitrum. Offchain Labs has shipped timeboost, an MEV-aware sequencer auction live on Arbitrum One. Validators auction priority transaction inclusion via a sealed-bid mechanism. The next step is multi-party sequencing with shared revenue, targeted for late 2026 per public statements. Arbitrum's BOLD upgrade already decentralized validation — anyone can post fraud proofs — so the chain has a permissionless safety layer if the sequencer misbehaves.
Optimism Superchain. The Superchain plans a shared sequencer across all member chains, likely operated by Espresso Systems. Espresso uses HotShot, a BFT consensus protocol, to sequence transactions across multiple Superchain members atomically. Production rollout is expected in 2026 alongside the native interop launch. Until then, each Superchain member runs its own centralized sequencer (Coinbase for Base, OP Labs for OP Mainnet, etc.).
zkSync Era. Matter Labs has signaled a "based rollup" mode where Ethereum L1 validators handle L2 ordering. Public discussions describe a model where users submit transactions to L1 mempool with a special tag; L1 proposers include them in L2 blocks via the rollup's contracts. Based sequencing avoids running a separate L2 validator set entirely.
Linea. ConsenSys has stated permissionless sequencing is on the roadmap but has not committed to a public timeline or design. The chain currently runs a single sequencer operated by ConsenSys.
Scroll. Similar to Linea — Scroll Foundation operates the sole sequencer with no published decentralization timeline. The team has discussed multi-party prover networks but not multi-party sequencing specifically.
Base. Base will participate in the Optimism Superchain's shared sequencer when it launches. Until then, Coinbase operates the only Base sequencer.
Censorship Risk
The most concrete user-facing impact of centralized sequencing is censorship risk. A sequencer can decline to include a transaction, regardless of the user's gas price.
Public statements vary by operator. Coinbase has published that the Base sequencer respects OFAC SDN list filtering — sanctioned addresses are excluded from sequencer-included blocks. Offchain Labs has not committed to similar filtering on Arbitrum. Optimism has stated that its sequencer follows L1 censorship norms (post-merge MEV-Boost data shows ~30% of L1 blocks exclude OFAC addresses on average).
The mitigation is L1 force-inclusion. Every major rollup has a mechanism to force a transaction's inclusion via L1 after a delay (typically 12–24 hours). For Arbitrum, the delayed inbox contract accepts transactions on L1 that the sequencer must include within 24 hours or be slashed. For Optimism's stack, the OptimismPortal contract serves a similar role.
Force-inclusion is a fallback, not a daily-use mechanism — it costs L1 gas and adds delay. But its existence means users are not entirely captive to sequencer policy. For protocols that handle transactions on behalf of users in compliance-sensitive jurisdictions, having a force-inclusion path documented in the user-facing app is a meaningful security property.
MEV and Sequencer Revenue
Sequencers capture MEV through ordering decisions. On L1 Ethereum, MEV is auctioned via MEV-Boost; on L2s, MEV historically went directly to the centralized sequencer with no auction. Arbitrum's timeboost is the first production system to auction L2 MEV explicitly.
L2 MEV is generally smaller than L1 MEV per transaction but flows in higher volume. Estimated 2025 MEV on the top L2s totaled $180M+ across Arbitrum, Base, and OP Mainnet. Compared to L1 MEV of roughly $1B+ per year, L2 MEV is meaningful but not dominant.
For builders, MEV exposure on L2s shows up most in DEX trading and liquidations. Arbitrum's timeboost auction reduces sandwich-attack opportunities but does not eliminate them. Base, OP, and the ZK rollups have less active MEV mitigation today.
Real-World Sequencer Outages
Sequencer outages are rare but not unprecedented. Documented incidents:
Arbitrum One — January 2024. A sequencer hardware failure caused a roughly 78-minute outage. Transactions were not processed during the window; user funds remained safe but UX impact was significant. The chain resumed normal operation after Offchain Labs restored the sequencer.
OP Mainnet — June 2024. A configuration error during a planned upgrade caused a 22-minute halt. No funds lost; resolved by reverting the configuration change.
zkSync Era — March 2024. A prover failure (separate from sequencer) caused L1 finality to lag by several days. Sequencer continued processing transactions normally; only L1-bound withdrawals were delayed.
The pattern across incidents: centralized infrastructure means single-point-of-failure exposure, but recovery has been quick and no losses to user funds have occurred from sequencer issues directly. Fund losses on L2s have come from bridge hacks and protocol exploits, not sequencer behavior.
Shared Sequencing Designs
Three designs for decentralized L2 sequencing are in active development:
Espresso Systems. Uses HotShot consensus across a permissioned validator set. Espresso targets the Optimism Superchain initially. Cross-chain atomicity is a first-class feature — multiple Superchain members can include linked transactions in the same epoch.
Astria. Built on CometBFT (Tendermint-derived). Astria is chain-agnostic; any rollup can opt in. Production rollouts have been smaller in TVL than Espresso's pipeline so far.
Based rollups. Don't run a separate sequencer at all — let L1 Ethereum validators handle ordering. Conceptually the simplest but trades L2-native confirmation latency for the inherited L1 latency (12 seconds per slot). Mostly in research/testnet phase.
Each design accepts different trade-offs around latency, MEV capture, and trust assumptions. None has dominant production traction yet.
What Builders Should Do Today
Three patterns worth implementing for production applications:
Document a force-inclusion path. For applications that handle stablecoin payments or transfers on user behalf, ensure the contract architecture supports L1 force-inclusion if the sequencer pauses or censors. This usually means using the rollup's standard inbox/portal contract directly rather than relying on third-party relayers exclusively.
Monitor sequencer policy changes. Coinbase published its Base sequencer filtering policy. Other operators may change policies without public announcements. For compliance-sensitive flows, periodic policy review is warranted.
Diversify across chains. If your application can route across multiple L2s, exposure to any single sequencer is bounded. Stablecoin orchestration networks naturally provide this diversification — a transaction can route through Arbitrum, Base, or OP Mainnet depending on which sequencer is healthy.
Eco's Role and Sequencer Risk
Eco is a stablecoin execution network whose Eco Routes (CLI + API) abstracts chain selection across 15 chains, including all major L2s. Production teams using Routes get implicit sequencer-risk diversification: if one L2's sequencer pauses or censors, the network can route through another. The trade-off is that Routes adds an orchestration layer on top of the underlying chains; for applications that need to commit to a single L2, sequencer policy on that chain remains the operative consideration.
FAQ
Can a centralized sequencer steal my funds?
No. The rollup's proof system (fraud proofs for optimistic, validity proofs for ZK) prevents the sequencer from posting invalid state. The sequencer can reorder, delay, or censor transactions but cannot mint or transfer assets that the underlying execution wouldn't allow.
What happens if a sequencer goes offline?
The L2 stops processing new transactions until the sequencer comes back online. State doesn't roll back, but users can't submit new transactions through normal RPCs. Force-inclusion via L1 remains available with 12–24 hour delay. Most operators have monitoring and automatic failover within their internal infrastructure.
Which L2 has the most decentralized sequencer?
None are fully decentralized today. Arbitrum is the only chain with a production MEV auction (timeboost) and permissionless validators. The Optimism Superchain has the most concrete shared-sequencer plan via Espresso. Base, Linea, Scroll, and most other L2s run single-operator sequencers without published decentralization timelines.
Can I pay a sequencer to include my transaction faster?
Yes — most L2 sequencers respect priority fees similar to L1. On Arbitrum, the timeboost auction lets users bid for the front of the block. On Base and other OP Stack chains, higher priority fees move transactions earlier. Sequencer-side ordering policies vary, so the exact mechanism differs per chain.
Is L1 force-inclusion practical for normal users?
Not for daily use — it costs L1 gas ($4–18) and adds 12–24 hours of delay. Force-inclusion is a fallback for when the sequencer is offline or actively censoring. For protocols that handle high-stakes flows (large treasury operations, time-sensitive trades), having force-inclusion documented in the operational runbook is good practice.
Will all L2s eventually decentralize their sequencers?
The technical roadmaps point that direction. Whether and when each chain ships depends on engineering capacity and economic incentives. Arbitrum and the Optimism Superchain have the most active decentralization work. zkSync's based-rollup model is a different approach. Linea, Scroll, and others are further behind. Realistic horizon for production decentralized sequencing across all major L2s is late 2026 to 2027.
Does sequencer centralization affect rollup security?
It affects liveness and censorship-resistance, not asset security. The proof system (validity or fraud) prevents invalid state transitions regardless of sequencer behavior. A malicious sequencer can stall the chain or refuse specific transactions but cannot steal assets. For applications, this means UX and compliance risk; not asset risk.
How does sequencer revenue compare to validator rewards on L1?
L1 validator rewards run roughly $2.5B per year across Ethereum's validator set. L2 sequencer revenue across the top chains runs $150–250M per year combined, mostly captured by the operator (Coinbase, Offchain Labs, etc.). As L2 activity grows, sequencer revenue is expected to scale, increasing the economic incentive for decentralization designs that share that revenue across more participants.
What is a "based" rollup in the sequencing context?
A based rollup uses Ethereum L1 validators (proposers) for transaction ordering rather than running a separate L2 sequencer. Users submit transactions to L1 with a special tag; whichever L1 proposer is selected for the next slot includes them in the L2's state-transition. Trade-off: L2 confirmation latency drops to L1's 12-second slot time, but operational complexity decreases and trust assumptions collapse to L1's set.

