Every major Layer 2 rollup today, from Arbitrum to Base, hands transaction ordering to a single operator called a sequencer, even though decentralized alternatives exist. A sequencer is the component that decides the order of incoming transactions, builds blocks from them, and posts batches to Ethereum. That single design choice shapes everything about how a Layer 2 behaves, including downtime risk, who captures transaction fees, and whether anyone can censor your transaction.

What Is a Sequencer and Why Does It Matter?

When you submit a transaction on Arbitrum or Base, it does not go directly to Ethereum. Instead, it goes to the sequencer first. The sequencer decides when your transaction gets included, in what order it sits relative to other transactions, and when the resulting batch gets committed to Layer 1. That ordering decision determines whether your transaction gets included at all, whether someone can front-run or sandwich your trade, and whether the network stays online if the sequencer fails.

Because Layer 2s are designed for speed, most of them hand this responsibility to a single operator rather than running it through a slow consensus process. That operator is usually the Layer 2's own development team, running a single piece of software that handles all transaction ordering unilaterally, without involving any external consensus mechanism.

How Do Centralized Sequencers Work Versus Decentralized Ones?

In a centralized sequencer setup, when a user submits a transaction, it arrives at a single node. The sequencer places it in a queue, assigns it a position relative to other pending transactions, builds a block, and issues a soft confirmation back to the user, typically within milliseconds. Later, it batches multiple blocks together and posts them to Ethereum Layer 1.

A decentralized sequencer replaces the single-operator model with a rotating set of nodes that reach consensus on transaction ordering before any block is finalized. Instead of one server accepting and ordering transactions, a decentralized sequencer network runs a consensus protocol, typically a Byzantine Fault Tolerant variant, among multiple independent operators. A leader is selected for each block, proposes the ordering, and the remaining nodes attest to it. If the leader fails or behaves maliciously, the network elects a new one and continues.

The Real Tradeoffs: Speed, Censorship, and Outages

Centralized and decentralized sequencers make opposite tradeoffs across every meaningful dimension. Neither model is strictly superior; the right choice depends on which risks matter most to the users and applications relying on that rollup.

Censorship resistance illustrates the core tension. A single operator can exclude any transaction it chooses, whether due to regulatory pressure, a security response, or arbitrary preference. In June 2024, Linea paused its sequencer and censored specific wallet addresses in response to an exploit. The decision was defensible in context, but it demonstrated that one team held the power to freeze addresses on the network entirely. Users can technically bypass a censoring sequencer by submitting transactions directly to Layer 1, but the gas cost and latency make this impractical for everyday use.

Excluding a transaction from a decentralized sequencer requires collusion among a majority of independent node operators. This is structurally harder to coordinate and publicly observable in a way that a single operator's internal decisions are not.

Liveness failures pose another critical risk. If a centralized sequencer goes offline, the entire rollup stops processing transactions. This is not a theoretical risk. Arbitrum One experienced a hardware failure in January 2024 that caused approximately 78 minutes of downtime. OP Mainnet suffered a configuration error during an upgrade in June 2024 that caused a 22-minute halt. Base, operated by Coinbase, experienced a downtime event in February 2025 that interrupted transaction processing. In each case, recovery was relatively quick and user funds were safe, but the pattern is clear: single-operator infrastructure means rollup uptime equals sequencer uptime.

Node failures in a decentralized system are expected and handled by the protocol. The network continues as long as a sufficient quorum of nodes remains online. This is meaningfully more resilient for any application that requires consistent availability.

How Sequencers Extract Value Through MEV

The sequencer sees every pending transaction before it is committed. This gives it an information advantage it can use to reorder transactions, running sandwich attacks around large trades, front-running liquidations, or extracting arbitrage between blocks. On most Layer 2s today, there is no external audit of the mempool and no equivalent of Ethereum's Proposer-Builder Separation to contain this behavior.

The revenue at stake is substantial. Base generated over $75 million in sequencer revenue through 2025, according to Orochi Network. On Base alone, transaction-priority fees and MEV-adjacent revenue run an estimated $4 to $8 million monthly.

In a decentralized sequencer, MEV still exists and transaction ordering still has economic consequences, but no single entity captures it all. Revenue is distributed across operators, and coordinating MEV extraction requires collusion among multiple independent parties, which is harder to execute and more visible if it occurs. Arbitrum's TimeBoost mechanism, which introduces an explicit sequencer auction for priority inclusion, is a step in this direction even for centralized sequencers.

Speed Versus Resilience: The Core Tension

Centralized sequencers deliver soft confirmations within milliseconds. There is no consensus round, no leader election, no attestation delay. This speed is a major reason why every major Layer 2 still runs a centralized sequencer despite the risks.

A decentralized sequencer adds latency because a consensus round among multiple nodes is required. This typically adds tens to hundreds of milliseconds. For standard decentralized finance interactions, this difference is negligible. For high-frequency trading or latency-sensitive applications, it is a meaningful cost.

Key Tradeoffs Between Centralized and Decentralized Sequencers

• Censorship Risk: Centralized sequencers can exclude transactions unilaterally; decentralized sequencers require majority collusion, making censorship structurally harder but not impossible.
• Liveness and Uptime: Centralized sequencers create a single point of failure; decentralized sequencers continue operating as long as a quorum of nodes remains online, improving resilience.
• MEV Extraction: Centralized sequencers capture all MEV revenue; decentralized sequencers distribute it across operators, reducing monopolistic extraction but not eliminating MEV entirely.
• Transaction Latency: Centralized sequencers deliver millisecond confirmations; decentralized sequencers add tens to hundreds of milliseconds for consensus rounds, a negligible cost for most applications but meaningful for high-frequency trading.
• Implementation Complexity: Centralized sequencers are simple to operate; decentralized sequencers require Byzantine Fault Tolerant consensus protocols and careful incentive design.

Vitalik Buterin noted in a 2025 AMA that centralized sequencers can help mitigate certain frontrunning behaviors because the operator controls the queue and can implement ordering policies that reduce MEV opportunities for external actors. The trade-off, however, is that all of this control rests with one entity.

The persistence of centralized sequencers across the Layer 2 ecosystem reflects a pragmatic choice: speed and simplicity today, with the understanding that decentralization remains a longer-term goal. As Layer 2 networks mature and competition intensifies, the pressure to address censorship, MEV extraction, and liveness risks will likely drive more projects toward decentralized sequencer architectures, even if the latency cost remains a barrier to adoption.