A sequencer is the node or system on a layer-2 rollup that receives users’ transactions, puts them in order, builds the rollup’s blocks and posts the data back to the layer-1 chain, usually Ethereum. On most large rollups today one operator runs it, which makes confirmations fast but creates a single point of failure. You are not fully at its mercy: on Arbitrum One and Base you can force a transaction in through Ethereum, with a delay of up to 1 day and up to 12 hours respectively (L2BEAT, checked 14 October 2026). Shared sequencers and based rollups are the main attempts to remove that single operator.
Search “what is a sequencer” and most results are about synthesizers and drum machines. This guide is about the blockchain sense: the component that decides the order of transactions on a layer-2 rollup such as Arbitrum or Base. It covers what a sequencer does step by step, how it fits into optimistic and ZK rollups, what happens when it censors you or goes offline, real outages with dates, and the designs trying to replace the single operator. All figures and statuses were checked on 14 October 2026.
What is a sequencer?
A sequencer is the part of a layer-2 rollup that collects users’ transactions, decides their order, turns them into L2 blocks and submits enough data to the layer-1 chain for anyone to rebuild those blocks. Because it sets the order, it also decides when your transaction lands and which transactions go first.
Arbitrum’s documentation sums up the job as to “receive, admit, and order transactions” and then publish the resulting blocks. Base’s protocol overview lists the same duties: the sequencer accepts transactions directly from users, watches for deposit transactions made on Ethereum, merges both streams into ordered L2 blocks, and posts the data to L1. Base adds that the sequencer “is not a trusted actor”: its main job is to make ordering faster and cheaper than sending every transaction to Ethereum directly.
In music, a sequencer stores and plays back notes in a set order, and in biology a sequencer reads the order of DNA or amino acids. The blockchain sequencer borrows the same idea: it fixes the order of events.
First, what are layer 1, layer 2 and rollups?
Layer 1 is the base blockchain that settles everything and provides security, such as Ethereum. Layer 2 is a network built on top of it that runs transactions somewhere else and relies on the layer 1 for security and data. So “Ethereum layer 2” means a chain that executes transactions off Ethereum but anchors its results and data to Ethereum.
A rollup is the main type of layer 2. It “rolls up” many transactions into batches, runs them off-chain and posts the data and the resulting state back to the layer 1. There are two families:
| Optimistic rollup | ZK rollup | |
|---|---|---|
| How results are checked | Assumed valid unless someone proves fraud during a challenge window | Each batch comes with a validity proof that Ethereum verifies |
| Withdrawal to Ethereum | Generally waits about seven days for the challenge window, per ethereum.org | No challenge delay once the proof is verified |
| Sequencer’s role | Orders transactions and posts batches | Orders transactions and produces blocks; a prover makes the proof |
| Examples (as of 14 October 2026) | Arbitrum One; Base (L2BEAT lists fraud proofs with ZK and TEE proof arms) | Taiko Alethia (L2BEAT lists it as a ZK rollup) |
Sources: ethereum.org optimistic rollups (last updated 23 June 2026) and ZK rollups (last updated 7 October 2026) pages; L2BEAT project pages (checked 14 October 2026).
Base is a useful reminder that the line is blurring. L2BEAT reports that Base’s state proposals need a TEE attestation or ZK proof, and that a game resolves after 5 days with one proof, or 1 day if both proof types commit (checked 14 October 2026). That is shorter than the classic seven-day window.
Is layer 1 or layer 2 better? Neither in general. Layer 2 transactions are usually cheaper and faster to confirm, while layer 1 gives you the base chain’s security directly, without an extra operator, bridge contracts or upgrade keys in between. The sequencer is one of the main things you trade for that speed. For how Ethereum scales its base layer for rollups instead, see what sharding is and why Ethereum shards only data.
What does a sequencer do? Step by step
- Receives transactions. Your wallet sends the transaction to the rollup’s RPC endpoint, which forwards it to the sequencer rather than to a public mempool. Arbitrum describes its mempool as private.
- Picks up L1 deposits. Deposits and messages sent from Ethereum enter through a contract on L1 (Arbitrum calls it the delayed inbox; Base’s deposits go through the OptimismPortal contract). The sequencer adds them to L2 blocks.
- Orders them. This is the core job. The ordering policy decides who goes first: arrival time, fee paid, or an auction (see the MEV section below).
- Builds blocks and gives a fast confirmation. The sequencer executes and streams the ordered transactions so wallets and apps see them almost at once. Arbitrum calls this soft finality, a sub-second provisional confirmation that “depends on the Sequencer behaving honestly”. Base says its sequencer produces Flashblocks every 200 milliseconds, committing to the order within a block as it is built.
- Posts the data to L1. The sequencer, or a batcher it runs, compresses the transactions and posts them to Ethereum as calldata or blobs. Arbitrum calls the point where those batches are final on the parent chain hard finality.
- Someone else proposes the state. A separate role, the proposer (or validator), posts state roots that the bridge uses for withdrawals. In ZK rollups a prover also generates the proof. Sequencer and proposer can fail independently.
That last point matters when you read incident reports. L2BEAT recorded that Base posted no state updates for 23 hours 21 minutes on 8 to 9 October 2026, which delays withdrawals to Ethereum, while blocks on Base itself kept being produced. That was a proposer problem, not a sequencer one.
Centralised sequencers: how the big rollups run today
Most large rollups use a single sequencer. That gives you fast, predictable confirmations and makes upgrades simple, but it means one operator can delay or skip your transaction and one bug can stop the chain. Here is how three different designs look on L2BEAT and in their own documentation.
| Rollup | Who sequences | If the sequencer fails or censors you | L2BEAT stage |
|---|---|---|---|
| Arbitrum One | One logical sequencer; Arbitrum’s docs say several sequencer nodes run behind it with an elected leader | “Self sequence”: force the transaction in through L1, with up to a 1 day delay | Stage 1 |
| Base | A single sequencer; Base Multisig 1, a 3-of-12 Safe that L2BEAT says Coinbase controls, can change it | “Self sequence”: force the transaction in through L1, with up to a 12 hour delay | Stage 1 |
| Taiko Alethia | Based design, but proposing is whitelisted: one active operator per epoch | You can queue a transaction on L1 but cannot force it; inclusion is due after 9 minutes 36 seconds, yet operators can stop processing the queue entirely | Stage 0 |
Source: L2BEAT project pages for Arbitrum One, Base and Taiko Alethia (checked 14 October 2026).
The L2BEAT stages are a maturity scale. Stage 0 means the rollup still depends heavily on its operators. Stage 1 requires, among other things, that the only way (other than bugs) to block a withdrawal indefinitely is to compromise at least 75% of a Security Council, and that upgrades from outside that council give users at least 7 days to exit. Stage 2 raises the exit window to 30 days (L2BEAT stages page, last updated 23 July 2025). Arbitrum One and Base both pass L2BEAT’s “walkaway test”: you can still exit if the Security Council disappears.
Can a sequencer censor you? Forced inclusion explained
A single sequencer can ignore your transaction. The defence is forced inclusion, sometimes called the escape hatch: you send the transaction to the rollup’s contract on Ethereum, and if the sequencer does not include it within a set window, the rules let it in anyway. ethereum.org describes the same mechanism for both optimistic and ZK rollups.
On Arbitrum One, the Arbitrum sequencer documentation gives the details (checked 14 October 2026):
- Messages from L1 enter the delayed inbox. The sequencer normally includes them once their L1 block is safe.
- If it does not, anyone can push them through after
delayBlocks, set to 7,200 L1 blocks, about 24 hours. - A newer Censorship Timeout feature makes the window the lesser of
delayBlocksand adelayBufferthat ranges from 30 minutes to 48 hours, so repeated delays shrink the time a sequencer can stall users.
On Base, L2BEAT puts the worst case at up to 12 hours. The catch in both cases: forcing a transaction through costs you Ethereum gas and needs some technical skill, so it is a backstop, not a normal way to use the chain.
What happens if the sequencer goes down?
New L2 blocks stop. Your funds stay where they are, but you cannot trade, repay a loan or move assets on the L2 until it recovers, except through the slow L1 route above. Some recent incidents, from the rollups’ own status pages:
| Date | Rollup | What happened | Source |
|---|---|---|---|
| 15 December 2023 | Arbitrum One | Sequencer and feed stalled from 15:29 to 16:57 UTC (about 88 minutes) during a surge of inscription transactions; the incident was closed at 21:04 UTC after gas prices normalised | Arbitrum status page |
| 5 August 2025 | Base | Block production halted for about 33 minutes; Base’s status page called it an “unsafe head delay” and a spokesperson blamed “an unexpected issue during an automated system switch” | Base status page, via Blockworks |
| 25 to 26 June 2026 | Base | Chain stall; Base said it had “isolated a consensus problem that caused an invalid block to be sequenced”. A second halt began 26 June at 15:33 UTC and blocks resumed at 15:47 UTC; node operators had to restart | Base status page |
Sources: Arbitrum status history and Base status history (checked 14 October 2026). Arbitrum’s page lists the December 2023 incident as 4 hours 7 minutes, which matches the period from restart to resolution rather than the stall itself.
The August 2025 outage shows the knock-on effects. Blockworks reported that Aave and Moonwell markets on Base were temporarily frozen because Chainlink’s Sequencer Uptime Feed paused price updates, which prevented liquidations at stale prices. Lending apps on L2s rely on feeds like that precisely because the sequencer can stop.
Sequencers, MEV and revenue
Whoever orders transactions can profit from the order. That value is called MEV (maximal extractable value): front-running a large trade, arbitrage between pools, or liquidations. On a centralised rollup the sequencer’s ordering policy decides who can capture it.
- First come, first served. Arrival time sets the order. Timeboost was built as a modified version of this policy.
- Timeboost. Arbitrum’s auction policy sold a 60-second “express lane” in a sealed-bid, second-price auction, while every other transaction waited an extra 200 milliseconds.
- Priority gas auction (PGA). Arbitrum’s sequencer documentation now says “PGA replaces Timeboost on Arbitrum One”: transactions are sorted by the priority fee they pay in rounds several times per block, ties go to the earlier arrival, and the 200 millisecond delay is gone. The same page says PGA does not let anyone see or reorder other users’ transactions. Arbitrum’s separate Timeboost page still describes Timeboost as live, so check the current notices if this matters to you.
The sequencer also collects the fees users pay on the L2 and pays for posting data to Ethereum, so running one is a business. RockawayX, an investor in a shared-sequencer project, argued in July 2024 that sequencing is highly profitable, which gives rollup teams little incentive to hand it over. If you build on an L2, your RPC provider is your route into the sequencer; see our comparison of blockchain API and RPC node providers.
Decentralised sequencers: shared, based and rotating
Three broad designs aim to remove the single operator. None has yet replaced it on the largest rollups as of 14 October 2026.
Shared sequencing
A shared sequencer is one network that orders transactions for several rollups at once, which can also let a transaction on one rollup depend on another. Espresso’s documentation now describes its network as settlement infrastructure: each chain runs its own sequencer, streams its ordered transactions to Espresso, and Espresso finalises that stream with proof-of-stake consensus without executing anything. Its docs list Offchain Labs (Arbitrum), Celo, Yuga Labs (ApeChain), Bitget (Morph Chain), Rarible (Rari Chain) and Litecoin (LitVM) among users, without saying how each uses it. Astria, another shared sequencer highlighted in 2024, gives no current mainnet status on its site; treat it as unconfirmed.
Based rollups
A based rollup hands sequencing to Ethereum itself. Taiko’s documentation says Taiko Alethia “is a based rollup, meaning its sequencing is driven by Ethereum (L1)”, with Ethereum’s block proposers selecting the next rollup block. In practice, L2BEAT shows that Taiko Alethia currently gates proposing through a whitelist that picks one active operator per epoch to give preconfirmations, and that users cannot force inclusion (checked 14 October 2026). The design goal and today’s setup are not the same thing, and that gap is common across the industry.
Rotating or staked sequencer sets
The third approach is a set of sequencers that take turns, chosen by stake, governance or election, with penalties for misbehaving. Several rollups have published research and proposals along these lines. The trade-off that Espresso and others point out is liveness: more operators remove the single point of failure but add coordination that can itself stall or slow confirmations.
What this means for you
If you use an L2, the sequencer is why your transaction confirms in under a second, and also why the chain can stop for half an hour. Check a rollup’s L2BEAT page before you park large sums there: look at the sequencer failure row, the force-inclusion delay and the stage. If you run a protocol on an L2, plan for sequencer downtime: use a sequencer uptime feed for anything with liquidations, and test what your users can do through L1 when the sequencer is down. If you are choosing an L2 to build on, ask who can change the sequencer, how long forced inclusion takes, and what the published roadmap says about decentralising it, and judge the answer by what is live, not by what is planned.
More infrastructure guides are in Node & RPC Infrastructure. For how Ethereum’s own governance works underneath all of this, read who owns Ethereum, and for the applications that run on these networks, what DeFi is. How this site sources and dates its facts is set out in the methodology.
