Fundamentals of Sequencers and Rollups

What Is a Sequencer?

A sequencer is the component responsible for ordering incoming transactions before they are batched and committed to a rollup’s publishing layer. Rather than executing state transitions, a sequencer primarily manages the write‑lock of ordering: it collects user transactions, arranges them into blocks or batches, and submits them to the underlying data availability or base layer. This ordering is critical because it determines how the rollup’s state machine evolves when execution occurs on rollup nodes. The sequencer thus serves as a gatekeeper for transaction ordering and timing, and its design decisions influence liveness, censorship resistance, and fee extraction.

Centralized Versus Decentralized Sequencers

In most existing rollups today, sequencers are centralized—typically operated by the project team. This offers fast throughput and simple governance but introduces a single point of control and failure. Centralized sequencers can censor transactions, suffer outages, or change policies unilaterally. Decentralization in sequencing, by contrast, distributes ordering authority across multiple independent nodes or validators. A decentralized sequencer network increases resistance to censorship and improves availability. Shared sequencer networks take this further by offering a common ordering layer across multiple rollups, providing economies of scale and stronger reliability guarantees without each rollup needing to build its own set of sequencers.

Rollups 101

Rollups are layer‑2 scaling solutions that execute smart contracts and transactions off‑chain while posting compressed data or proofs to a layer‑1 blockchain. There are two main types: optimistic rollups and zero‑knowledge (zk) rollups.

Optimistic rollups assume transactions are valid and rely on fraud proofs submitted after execution, whereas zk‑rollups compute validity proofs cryptographically and post succinct proofs to the base layer.

Both rely on sequencers to order and batch transactions. In optimistic rollups, the sequencer includes transactions in batches that are later verified by challenge games, while in zk‑rollups the sequencer orders transactions that are immediately finalized upon proof verification.

Sequencing Versus Execution

Sequencing and execution are distinct stages in rollup architecture. Sequencing is the off‑chain ordering phase where transactions are aggregated and tagged with block position before they are submitted for finalization. Execution happens later, once rollup nodes fetch ordered data and apply it to the state machine to compute new states. Some sequencer designs also execute transactions, meaning the sequencer knows transaction outcomes in advance; this allows atomic execution. Other architectures intentionally separate sequencing and execution to support more rollups without requiring the sequencer to maintain each rollup’s state machine. This “lazy sequencing” avoids state bloat and simplifies onboarding for new rollups.

The Emergence of Shared Sequencer Networks

Shared sequencer networks allow multiple rollups to plug into a single ordering service. Instead of each rollup maintaining its own sequencer, orthogonal rollups share a common decentralized network for ordering transactions. This enables atomic cross‑rollup inclusion: transactions destined for different rollups can be bundled into a single batch, guaranteeing that they are included together. Projects like Astria, Espresso Systems, Radius, NodeKit and Rome Protocol are actively building this infrastructure. Astria and Rome, for example, enable atomic inclusion without executing transactions in the sequencer itself (lazy sequencing), while capitalizing on higher censorship resistance, faster ordering, and MEV efficiencies.

Atomic Inclusion Versus Atomic Execution

Atomic inclusion ensures that related transactions targeting different rollups are included in the same batch; either all or none are included together. This is weaker than atomic execution, which requires the sequencer or block builder to simulate or guarantee that all included transactions succeed if executed. In shared sequencer networks that only sequence but not execute, atomic execution is not guaranteed. For instance, a lock on Rollup A and a mint on Rollup B might be bundled together, but if one reverts, the other might still succeed. True atomic execution requires awareness of each rollup’s state machine or block builders that enforce “top-of-block” conditions. Current designs typically support atomic inclusion and defer execution guarantees to rollup-level logic.

Challenges and Trade‑Offs in Sequencer Design

Implementing shared sequencers at scale introduces several challenges. Sequencers that avoid execution remain agnostic to rollup state and scale easily, but cannot guarantee execution success. Sequencers that do execute transactions must maintain full state machines for each rollup, which becomes impractical as rollups proliferate. Economic bootstrapping also poses a challenge: shared networks require substantial economic stake to secure them credibly. Projects must design tokenomics or leverage existing validators to provide sufficient collateral. Latency performance is another consideration, as shared sequencer networks must offer high availability and low delay comparable to centralized sequencers in order to be viable alternatives.