A sequencer is the component of a Layer 2 network responsible for receiving user transactions, deciding their order, and batching them together before submitting to Layer 1. It is the traffic controller of an L2: without it, there is no canonical ordering and therefore no reliable state progression on the rollup.
​

Most rollups today run a single sequencer operated by the team that built the network. This design keeps things simple and fast, but it introduces meaningful trust assumptions that the broader Ethereum ecosystem is actively working to reduce. Understanding what a sequencer does, why centralization is the default right now, and what the alternatives look like is essential context for anyone building or transacting onchain at the L2 layer.
​

For a broader introduction to how rollups bundle computation, see What Is a Rollup: Optimistic vs ZK Rollups. For a technical overview of the sequencer's role in the broader L2 ecosystem, see the Ethereum Foundation's Layer 2 explainer.
​

The sequencer sits at the ingress point of an L2. Users broadcast signed transactions to it the same way they would broadcast to an Ethereum node, but the sequencer rather than a decentralized mempool decides what happens next. Understanding the full pipeline clarifies both the performance advantages and the trust surface that sequencers introduce.
​

Transaction receipt and soft confirmation. When a user submits a transaction, the sequencer validates it, checks the nonce and balance, and issues a "soft confirmation" almost immediately, often within one to two seconds. This soft confirmation is an informal promise: the sequencer says it will include the transaction at a specific position. At this point the transaction is not yet final, but wallets and dapps treat it as effectively settled for most UX purposes because walking back a soft confirmation would be a reputational disaster for the sequencer operator.
​

Transaction ordering and MEV. The order in which transactions are included determines who captures value from price-sensitive actions like arbitrage or liquidations. A sequencer can, in principle, reorder transactions within a batch to extract maximal extractable value (MEV) before submitting the batch onchain. Some sequencers explicitly prohibit front-running and run first-come-first-served (FCFS) ordering; others use priority fee auctions similar to Ethereum's EIP-1559 model. The specific policy is a design choice made by the sequencer operator, not enforced by the rollup protocol itself unless the smart contracts explicitly encode it.
​

Batching. Rather than posting each transaction individually to Ethereum, the sequencer aggregates hundreds or thousands of transactions into a single batch. This is the fundamental reason L2s are cheaper than L1: the fixed cost of an Ethereum transaction (calldata or blob gas) is amortized across every transaction in the batch. Batch size is a tunable parameter that sequencers balance against latency: larger batches are cheaper per transaction but introduce more delay before the data lands onchain.
​

Data compression. Before posting, the sequencer compresses the batch using schemes like zlib or zstd. Rollup transaction data is highly compressible because it strips out fields Ethereum already knows (the chain ID, for example) and because similar transactions repeat patterns. Compression ratios of 4x to 10x are common, meaning the actual Ethereum footprint of a batch is much smaller than the raw transaction data.
​

Blob posting via EIP-4844. Since March 2024, rollups post batch data as blobs under EIP-4844 rather than as calldata. Blobs are cheaper, have a separate fee market, and are pruned from Ethereum full nodes after roughly 18 days. The sequencer is responsible for constructing the blob transaction, paying the blob base fee, and ensuring the data is available long enough for verifiers and fraud-proof challengers to access it. For ZK rollups, the sequencer also coordinates with the prover network to generate validity proofs for each batch before or shortly after posting.
​

For a deep look at how Optimism's specific implementation handles this pipeline, see What Is the OP Stack: Architecture and Superchain Explained.
​

External reference: Ethereum Foundation documentation on optimistic rollup transaction flow covers the data availability layer in detail.
​

Every major rollup deployed today, including Arbitrum, Optimism, Base, zkSync Era, and Starknet, runs a single sequencer controlled by its founding team. This is not an oversight or philosophical choice in favor of centralization. It is the pragmatic outcome of constraints in latency, coordination overhead, and time-to-market that dominated the early rollup deployment window.
​

Latency requirements. Running a decentralized sequencer requires consensus among multiple nodes before a soft confirmation can be issued. Even fast BFT consensus protocols like Tendermint or HotStuff add 200 to 600 milliseconds of round-trip latency per block. For a rollup competing on user experience, that overhead is significant. A single sequencer can issue a soft confirmation in under 100 milliseconds because no coordination is needed: it decides unilaterally and signs the response immediately.
​

Engineering simplicity. Decentralized sequencing requires a sequencer selection protocol, a mechanism for sequencer nodes to post bonds and be slashed for misbehavior, and an upgraded bridge contract that can recognize commitments from a rotating set of signers rather than a single trusted key. Building this correctly without introducing new attack surfaces takes significant engineering time. Most rollup teams shipped a centralized sequencer first as a known-safe baseline with the intention of decentralizing later.
​

Economic model. The sequencer earns the difference between the fees users pay and the L1 posting cost. For a startup-operated rollup, this is a meaningful revenue stream that funds protocol development. Decentralizing the sequencer distributes that revenue to a validator set and requires designing a token or fee-split mechanism that aligns incentives correctly, another layer of complexity that teams deferred.
​

Upgrade flexibility. A centralized sequencer means the team can push upgrades, roll back unexpected behavior in emergencies, and respond to protocol bugs without waiting for governance votes. During the early life of a rollup, when the code is still being battle-tested, this agility has genuine safety value even if it also represents a trust trade-off.
​

See What Is Arbitrum: Ethereum's Largest L2 Explained for how Arbitrum specifically documents its current sequencer trust assumptions and its roadmap toward decentralization.
​

External reference: L2Beat's rollup summary dashboard tracks which rollups still rely on a centralized sequencer and rates each chain's decentralization progress across multiple dimensions.
​

Running a single sequencer controlled by one entity compresses several distinct failure modes into one point. The risks are not hypothetical: censorship, downtime, MEV extraction, and regulatory seizure have all produced real incidents or credible attack scenarios across live rollup deployments.
​

Censorship. A centralized sequencer can choose not to include specific transactions. It might exclude addresses sanctioned under OFAC, competitor protocol transactions, or transactions from specific users. Because the sequencer controls inclusion, a user whose transaction is being censored has no immediate recourse within the rollup itself. Most rollups provide a "force inclusion" path that allows users to submit transactions directly to the L1 bridge contract, bypassing the sequencer, but this fallback typically takes hours or days to execute and costs L1 gas fees. During the time window before force inclusion settles, the user is effectively frozen.
​

Downtime and liveness failure. If the sequencer goes offline, the entire rollup stops processing transactions. This has happened: Arbitrum's sequencer went offline for roughly 45 minutes in December 2021 after a surge in transaction volume overwhelmed its infrastructure. During that window no transactions were processed, DeFi positions could not be managed, and users were exposed to price movements they could not hedge. A single point of failure at the sequencer layer means rollup uptime equals sequencer uptime.
​

MEV extraction by the sequencer operator. The sequencer sees every pending transaction before they are committed. A malicious or profit-maximizing operator can insert its own transactions before or after known profitable trades, capturing arbitrage or liquidation value that would otherwise go to searchers or users. This is a stronger position than an Ethereum validator occupies, because the rollup sequencer sees the entire unfiltered mempool with zero competition for ordering priority within a given block.
​

Reorg and soft-confirmation revocation. Because soft confirmations are promises made by a single entity rather than cryptographically enforced commitments, the sequencer can in principle revoke or reorder a transaction it has already soft-confirmed. This would violate the trust users place in soft confirmations and could enable sophisticated attacks against protocols that accept sequencer pre-confirmations as inputs. Most sequencers have strong incentives not to reorg, but the technical ability exists and is not prevented by the protocol.
​

Regulatory seizure. A sequencer operator is a legal entity subject to jurisdiction. Regulators could compel the operator to censor specific addresses or shut down sequencer operations entirely, with immediate effect on the rollup's liveness and neutrality.
​

Understanding fault proofs is relevant here: even when sequencers misbehave at the state-transition level, fraud-proof systems provide a backstop. See What Are Fault Proofs in Blockchain for how that mechanism works.
​

External reference: The Block's coverage of Arbitrum sequencer downtime incidents documents the real-world liveness risk.
​

Based sequencing is an architectural approach where L1 validators, specifically Ethereum proposers, take over the sequencing function entirely. Instead of an L2-specific sequencer deciding transaction order, the next Ethereum block proposer sequences the rollup's transactions as part of building the L1 block. The rollup inherits Ethereum's sequencer-selection mechanism directly.
​

The concept was articulated by Justin Drake in early 2023 and has since attracted serious attention from protocol researchers. The central insight is that Ethereum already has a decentralized, credibly neutral, economically bonded set of block proposers. Rather than building a separate decentralized sequencer network, a rollup can simply route its sequencing through a network that already exists and already has strong security properties.
​

How it works mechanically. Users submit transactions to Ethereum's public mempool or to a dedicated rollup transaction pool. When an Ethereum proposer builds a block, it includes rollup transaction bundles alongside regular L1 transactions. The order of rollup transactions is determined by the same auction mechanism that determines L1 transaction order: priority fees and builder APIs like MEV-Boost. The rollup's smart contracts on L1 read the transaction bundle from the block and update the rollup's state root accordingly.
​

Liveness guarantee. A based rollup cannot experience sequencer downtime independently of Ethereum. If Ethereum is producing blocks, the rollup is sequencing. The 12-second Ethereum slot time becomes the rollup's block time, which is slower than the sub-second soft confirmations a centralized sequencer can provide, but the liveness guarantee is much stronger.
​

Censorship resistance. Ethereum's proposers are bound by its inclusion lists and OFAC compliance debates, but the network's geographic and operator diversity makes sustained censorship significantly harder than censoring a single-entity sequencer. Any proposer can include rollup transactions; no single party controls inclusion.
​

MEV characteristics. Based sequencing does not eliminate MEV; it routes MEV to Ethereum validators and builders rather than to an L2 sequencer operator. Whether this is preferable depends on perspective, but it does align the rollup's MEV with the broader Ethereum validator economy rather than siloing it with a startup.
​

Tradeoffs. The 12-second slot time means no sub-second soft confirmations from the rollup itself, which is a real UX regression for applications that rely on near-instant confirmations. Proposed preconfirmation schemes, where Ethereum validators issue signed promises to include a transaction in the next slot, are being researched as a mitigation, but they add protocol complexity.
​

Taiko is the most prominent production-deployed based rollup as of 2026. Puffer UniFi and Gwyneth are also based rollup projects in various stages of development.
​

External reference: Justin Drake's original "Based Rollups" post on ethresear.ch remains the canonical technical reference for this design space.
​

A shared sequencer is a decentralized network of nodes that orders transactions across multiple rollups simultaneously. Rollups outsource ordering to a shared external service, which posts batches to each chain's L1 contracts and enables atomic cross-rollup bundles that no single-rollup sequencer can produce.
​

The most developed shared sequencer projects as of 2026 are Espresso Systems, Astria, and SUAVE (Single Unified Auction for Value Expression, proposed by Flashbots). Each takes a somewhat different approach to consensus, MEV policy, and rollup integration, but all share the core goal of separating sequencing from rollup execution and making it a shared public utility.
​

Espresso Systems. Espresso runs HotShot, a BFT consensus protocol designed for high-throughput block production. Rollups integrate with Espresso by replacing their sequencer with an Espresso commitment: rather than trusting a single sequencer, a rollup trusts the Espresso validator set, which is economically bonded and geographically distributed. Espresso has been integrated with OP Stack chains and Arbitrum Orbit chains in testnet environments. The validator set can be permissioned initially and progressively decentralized as the network matures.
​

Astria. Astria takes a modular approach: it is a pure sequencing layer that does not attempt to be a settlement or execution layer. It uses CometBFT consensus and is designed to be execution-environment agnostic. Rollups using Astria keep their own execution environments and state machines; they simply route ordering through the Astria sequencer network. Astria raised Series A funding in 2024 and has active integrations with several OP Stack rollups.
​

SUAVE. SUAVE is a more radical proposal from Flashbots that treats the sequencer as a specialized execution environment for MEV-related computation. Rather than just ordering transactions, SUAVE allows users to express preferences and partial transaction intents that get matched and executed optimally. It is designed to decentralize the block-building supply chain rather than just replace the sequencer with a slightly less centralized version.
​

Atomic cross-rollup transactions. The most compelling capability shared sequencers unlock is atomicity across rollups. Today, moving assets from Optimism to Arbitrum requires a bridge transaction with a delay. With a shared sequencer, a bundle that executes on both rollups simultaneously can be submitted as a single atomic unit: either both sides execute or neither does. This is the foundational primitive for native cross-rollup DeFi, where a protocol can have liquidity split across multiple L2s but users interact with it as a single application. Stablecoin automation platforms operating across multiple chains would benefit directly from this; see 10 Best Stablecoin Automation Platforms 2026 for context on why cross-chain atomicity matters for yield routing.
​

Integration complexity. Adopting a shared sequencer requires rollup teams to modify their node software to submit to and receive from the external sequencing network rather than their own sequencer. For rollups built on standardized frameworks like the OP Stack or Arbitrum Orbit, this integration surface is well-defined; for custom stacks, it requires more bespoke work.
​

External reference: Espresso Systems documentation provides a detailed technical overview of the HotShot consensus mechanism and rollup integration patterns.
​

Centralized, based, and shared sequencers each make different trade-offs across censorship resistance, MEV policy, confirmation latency, liveness, and current production adoption. The table below maps those five dimensions so you can evaluate which model fits a given rollup's design goals.
​

For live per-chain decentralization scoring, see L2Beat's rollup summary dashboard.
​

Common questions about how sequencers fit into the broader rollup stack, what happens when they fail, how they relate to validators and provers, and where the ecosystem is heading on decentralization. Answers are kept to the core mechanics; deeper context lives in the related articles listed at the bottom.
​

For background on the proof systems that work alongside sequencers, see What Are Fault Proofs in Blockchain. Ethereum researchers' preconfirmation notes cover the open problem of fast finality in based rollup designs.
​

No. A sequencer orders and batches transactions; validators (or provers in ZK rollups) check that the sequencer's claimed state transitions are correct. On optimistic rollups, anyone can become a validator by running a node and submitting fraud proofs if the sequencer posts an invalid state root. The roles are separate and can be operated by different parties.
​

Yes, but with delay and cost. Every major rollup includes a force-inclusion mechanism that lets users submit transactions directly to the L1 bridge contract. The transaction is then included in the rollup's state after a protocol-defined delay, typically 24 hours on Optimism and Arbitrum. This bypass costs L1 gas fees and is not practical for time-sensitive DeFi actions, but it does mean censorship cannot be permanent.
​

They queue in the user's wallet or the local node's mempool and are not processed. The rollup's state freezes at the last committed batch. No transactions can be included until the sequencer comes back online, though users can still exit via the L1 bridge using the last valid state root. This liveness gap is the primary motivation for decentralizing the sequencer function.
​

The sequencer's ordering and batching function is structurally the same in both rollup types. The difference is downstream: after the sequencer posts a batch, an optimistic rollup waits for a fraud-proof challenge window before finalizing state, while a ZK rollup requires a validity proof to be generated and verified onchain before the state root is accepted. The sequencer does not generate the ZK proof itself; that work is delegated to a separate prover network. For a full comparison of these two approaches, see What Is a Rollup: Optimistic vs ZK Rollups.
​

Most major rollup teams have committed to sequencer decentralization on their public roadmaps. Arbitrum has outlined a path to decentralized sequencing via its BOLD protocol and BoLD validator set. Optimism's decentralization roadmap includes sequencer rotation as a milestone. The timeline is uncertain, but economic and regulatory pressure makes centralized sequencers an increasingly uncomfortable long-term position for rollups that market themselves as decentralized infrastructure.
​

Articles covering the protocols, proof systems, and L2 architectures that interact most directly with sequencer design. The pieces below form the core conceptual cluster around how rollups execute, verify, challenge, and settle transactions onchain across both optimistic and ZK paradigms.
​

Ethereum's danksharding roadmap explains the long-term data availability changes that will affect how sequencers post blobs.