What Is a Sequencer in Layer 2 Rollups?

A sequencer is the component of a layer 2 rollup responsible for receiving incoming transactions, ordering them, executing them against the rollup's current state, and batching the results before posting the data back to the base layer, making it one of the most operationally important, and most centralized, parts of most rollups running today.

Understanding what a sequencer does, and who controls it, is essential for assessing the real-world trust assumptions behind any rollup you use, regardless of how decentralized its underlying base layer is.

What a sequencer actually does

When you submit a transaction to a rollup like Arbitrum or zkSync Era, it typically first goes to that rollup's sequencer rather than directly to Ethereum. The sequencer's job includes:

• Ordering: deciding the sequence in which submitted transactions are processed, which can matter a great deal for time-sensitive activity like arbitrage or liquidations.
• Execution: running transactions against the rollup's current state to compute the resulting balances and contract state changes.
• Batching: grouping many transactions together so their data can be posted to the base layer efficiently, spreading the fixed cost of an Ethereum transaction across many rollup transactions.
• Providing fast confirmations: giving users a quick "soft confirmation" that their transaction was received and ordered, well before the underlying batch is finalized on the base layer.

Why most sequencers today are centralized

Building a fully decentralized, permissionless sequencer network that can't be gamed for value extraction (through unfair transaction ordering, a subset of MEV) or censorship is a genuinely hard distributed-systems problem, and most rollup teams have prioritized shipping a working, performant rollup first, with sequencer decentralization as a subsequent roadmap item.

As a result, a single entity, often the founding team or foundation behind a given rollup, currently operates the sequencer for most major L2s, including Arbitrum, Optimism, Base, and most zk-rollups covered in our Layer 2 guide.

The risks of a centralized sequencer

Censorship. A malicious or coerced sequencer operator could, in theory, refuse to include specific transactions or addresses, though most rollups include a fallback mechanism letting users submit transactions directly to the base-layer contract if the sequencer refuses to cooperate, albeit typically with significantly higher friction and delay.

Downtime. If the sequencer goes offline, the rollup can effectively halt new transaction processing until it's restored, since users generally have no alternative fast path for submitting transactions during an outage.

Unfair ordering (MEV extraction). A sequencer that controls transaction ordering could, in principle, prioritize its own or affiliated parties' transactions ahead of others, extracting value at ordinary users' expense, a specific instance of the broader MEV problem.

What decentralized sequencing would look like

Various proposals aim to address this, including rotating sequencer duties among a permissioned or staked set of operators, using auction mechanisms to select sequencers, or adopting "shared sequencer" networks that serve multiple rollups at once and are designed with more robust decentralization and censorship-resistance guarantees from the outset. None of these approaches has yet become the clear industry standard, and most major rollups remain centralized in practice today.

Soft confirmations and their limits

When a sequencer accepts your transaction, it typically returns a "soft confirmation" almost instantly, letting applications show users a fast, responsive experience. It's important to understand this soft confirmation isn't the same as final settlement, it reflects the sequencer's own promise about ordering and inclusion, which only becomes fully binding once the corresponding batch (and, for optimistic rollups, its challenge window) is finalized on the base layer. In the rare case a sequencer misbehaves or reorganizes its own pending queue before finalization, a soft-confirmed transaction could theoretically be affected, though this would be considered a serious breach of expected behavior for any established rollup.

What to watch for as a user

Users concerned about sequencer risk can watch for a few signals: whether a rollup documents and has actually exercised its forced-inclusion fallback mechanism, whether the sequencer has a track record of extended downtime, and whether the project has published concrete, funded milestones toward decentralizing the role rather than vague long-term intentions. None of these guarantee safety, but they offer meaningfully more signal than assuming all L2s carry identical sequencer risk simply because they're all labeled "layer 2."

Sequencer risk in context

Risk	Centralized sequencer	Fully decentralized sequencing (aspirational)
Censorship resistance	Limited, relies on fallback L1 submission	Higher, no single point of control
Uptime dependency	Single operator	Distributed across multiple parties
MEV/ordering fairness	Operator discretion	Governed by protocol rules
Current adoption	Standard across most major L2s	Still largely experimental/in development

Bottom line

The sequencer is the operational heart of a rollup, and the fact that most major L2s still run centralized sequencers is one of the most underappreciated risks in the current layer-2 landscape, distinct from and in addition to the specific fraud-proof or validity-proof security model each rollup uses. Before treating any rollup as equivalently trust-minimized to its base layer, check whether it has a fallback path for censorship resistance and understand who currently controls its sequencer, a topic explored further in our sequencer decentralization guide.