Live prices are currently unavailable — the exchange feed could not be reached and no recent cached reading is held.

Bitcoin Data GuideBitcoin Reference

Research · Ethereum

L2 sequencers

A sequencer is the component that orders transactions inside a rollup. It is the part of a rollup that is most often centralised, and the mechanism that limits its power is forced inclusion — a path that lets a user bypass it.

Last reviewed 2026-09-21Source: ethereum.org scaling documentation and the L2BEAT risk frameworkArchitecture descriptions only; no claim is made about the current centralisation of any specific rollup.

What a sequencer does

A rollup needs someone to decide which transactions go into the next batch and in what order. That is the sequencer's job. It receives transactions from users, executes them against the rollup's state, produces the resulting state commitment, and posts the batch to the base layer. In most rollups today a single sequencer performs this role, which makes it the component that determines how quickly a transaction is confirmed and whether it is included at all.

The role is valuable because ordering is valuable. A sequencer sees every pending transaction before it is ordered, which means it can place its own transactions ahead of others. That is the same advantage a block producer has on the base layer, and it is the reason the MEV discussion applies to rollups as well as to Ethereum itself. A sequencer that also operates a trading operation has an informational advantage over every user of the rollup, and nothing in the rollup's design prevents it from using that advantage.

The sequencer is also the component that gives a rollup its user-facing speed. Because it executes transactions as they arrive and can confirm them immediately, a rollup can offer a confirmation time far shorter than the base layer's block time. That confirmation is a promise rather than a settlement: the transaction is not final until the batch containing it is posted and, depending on the rollup's design, until the batch is proved or the challenge window closes. A user who treats a sequencer confirmation as final is trusting the sequencer.

Forced inclusion and the limits on a sequencer

The powers a sequencer holds and the mechanisms that limit each one.
PowerWhat it enablesWhat limits it
OrderingPlacing its own transactions ahead of users'None in a single-sequencer design; mitigated by decentralising the role
InclusionRefusing to include a user's transactionForced inclusion: a user can post the transaction to the base layer and have it included
DelayHolding a transaction without rejecting itA forced-inclusion path with a deadline, after which the sequencer is penalised or bypassed
ConfirmationPromising a confirmation it later does not honourThe base layer's state commitment, which the sequencer cannot alter once posted

Last reviewed 2026-09-21Source: L2BEAT, Stages frameworkThe framework describes the properties a rollup can have; individual rollups differ in which they have reached.

Forced inclusion is the mechanism that keeps a sequencer from censoring a user indefinitely. The idea is that a user can submit a transaction directly to a contract on the base layer, and the rollup is obliged to include it in a subsequent batch. If the sequencer refuses, the contract can penalise it or allow the user to bypass it entirely. The mechanism converts censorship from an absolute power into a delay, which is a meaningful difference: a user who can eventually force a transaction through is not at the sequencer's mercy, even if they have to wait.

The design of a forced-inclusion path is where the details matter. The path must be usable without the sequencer's cooperation, which means it must be a base-layer transaction that the rollup's contract recognises. It must have a deadline, so that a sequencer cannot simply ignore the request forever. And it must be cheap enough to be a realistic option, because a forced-inclusion path that costs more than the transaction is worth is not a real remedy. Rollups differ in how far they have gone on each of those points.

The framework the ecosystem uses to describe a rollup's maturity treats these properties as stages rather than as a binary. A rollup that posts state commitments to the base layer but retains full control over sequencing is at an earlier stage than one whose sequencing is open and whose proofs are permissionless. The distinction matters to a user because it decides what happens if the operator disappears: a user of a mature rollup can exit using the base layer alone, while a user of an early-stage rollup may have to wait for the operator to return.

Decentralising the role

The obvious fix for a centralised sequencer is to have several of them, and the difficulty is agreeing on an order without reintroducing the coordination cost the rollup exists to avoid. If a set of sequencers must reach consensus on every batch, the rollup has rebuilt the base layer's problem inside itself, and the throughput advantage shrinks accordingly. That is the tension every decentralisation proposal has to resolve.

The approaches under discussion take different routes. One is to rotate the sequencer role among a set of participants, so that no single one can censor indefinitely even though each batch is ordered by one party. Another is to auction the role, so that the right to sequence is sold and the proceeds accrue to the rollup's users or treasury. A third is to let anyone post a batch and rely on the base-layer proof or challenge mechanism to reject an invalid one, which makes sequencing permissionless at the cost of latency.

None of these is a solved problem, and the honest position is that sequencing is the least decentralised part of most rollups today. That is not a reason to dismiss rollups; it is a reason to describe them accurately. A rollup with a single sequencer and a working forced-inclusion path offers a user a real guarantee — the ability to exit without the operator's permission — and a weaker one than a rollup whose sequencing is open to anyone. The distinction belongs in the description rather than in a footnote.

Sources and references

The sequencer's role, the forced-inclusion mechanism and the maturity framework described above are taken from Ethereum's scaling documentation and the ecosystem's public risk framework.

  • Rollups and how they are structured. ethereum.org, Scaling: the rollup model and the components a rollup is made of.
  • The risk framework for rollup properties. L2BEAT, Stages: the properties a rollup can have, including who can sequence and whether a user can exit without the operator.
  • Optimistic rollups and the challenge mechanism. ethereum.org, Optimistic rollups: how a batch is posted and how a bad one is challenged.
  • Zero-knowledge rollups and validity proofs. ethereum.org, Zero-knowledge rollups: how a batch is proved rather than disputed.

Related reading