What Is a Sequencer? How L2 Transactions Get Ordered

When you send a transaction on Ethereum mainnet, a decentralized set of validators decides which block it lands in and in what order. When you send the same transaction on Arbitrum, Base, or Optimism, that decision is made by a single piece of software run by the rollup operator: the sequencer. It's the component that takes incoming L2 transactions, puts them in an order, and produces the blocks you read back over RPC.

If you build on L2s, the sequencer is quietly responsible for a lot of behavior you've probably noticed without naming it: why an L2 transaction confirms in ~250ms instead of 12 seconds, why "confirmed" on an L2 doesn't mean the same thing as "final," and why an entire chain can occasionally stop producing blocks for an hour. This post explains what the sequencer does and why it matters when you're reading chain state.

The problem a sequencer solves

A rollup's whole pitch is: execute transactions cheaply off-chain, then post the results to Ethereum so they inherit Ethereum's security. But "execute off-chain" raises an immediate question — in what order? Transaction ordering determines outcomes (which trade fills first, who wins the arbitrage), so somebody or something has to decide it.

On L1, ordering emerges from a decentralized auction among block proposers. Rollups, at least today, take a shortcut: they hand ordering to one trusted component. That's the sequencer. Centralizing ordering is what lets an L2 feel instant — there's no consensus round-trip, just one party saying "your transaction is number 4,812,003" and immediately producing a block.

What the sequencer actually does

Walk a transaction through it:

1. Receive. You submit a transaction to the L2's RPC endpoint. It goes to the sequencer's mempool, not Ethereum's.
2. Order. The sequencer picks an order for the pending transactions. Most run simple first-come-first-served by arrival time (Arbitrum) rather than a priority-fee auction, which changes the MEV dynamics versus L1.
3. Execute and produce a block. It runs the transactions through the L2's EVM and produces an L2 block — usually within a few hundred milliseconds. This is the "soft confirmation" you get back almost instantly.
4. Batch and post to L1. Periodically the sequencer compresses many L2 blocks into a batch and posts that batch as calldata (or a blob) to a contract on Ethereum. This is the step that gives the rollup its security: once the data is on L1, anyone can reconstruct and verify the L2 state.

Steps 1–3 are fast and centralized. Step 4 is slower and is where Ethereum's guarantees actually attach. The gap between them is the single most important thing to understand as a developer.

Soft confirmation vs. real finality

When your RPC call returns a receipt from an L2, the transaction has a soft confirmation: the sequencer has promised it's included at a specific position. That promise is good enough for most UX — it's why L2 apps feel snappy. But until the batch is posted to L1 and that L1 block itself finalizes, the ordering is only as trustworthy as the sequencer.

For a low-value action, trusting the soft confirmation is fine. For settling something high-value — a large withdrawal, a bridge, anything where a sequencer reversal would cost real money — you wait for the stronger guarantee. (We'll go deeper on the exact finality stages in a later post on L2 finality.)

"Centralized sequencer" — the part people skip

Nearly every major rollup today — Arbitrum, Optimism, Base, Zora, and others — runs a single, operator-controlled sequencer. This is the honest asterisk on rollup decentralization. It has two practical consequences:

The sequencer can reorder or delay, but not steal. Because every batch is ultimately verified against L1, a sequencer can't forge a transaction or take your funds. What a centralized sequencer can do is censor (refuse to include your transaction) or reorder for MEV. To bound that power, rollups ship a force-inclusion escape hatch: if the sequencer ignores you, you can submit your transaction directly to the L1 contract, and the rollup is obligated to include it after a delay (often ~24 hours). It's slow, but it means the sequencer can't censor you permanently.

If the sequencer goes down, the chain stops. A single sequencer is a single point of failure. Real incidents bear this out: Arbitrum, Optimism, and others have each had sequencer outages lasting tens of minutes to a couple of hours, during which no new L2 blocks were produced — RPC reads still worked, but writes simply queued. This is why production L2 apps need to handle "the chain isn't accepting transactions right now" as a real state, not an impossible one.

Decentralizing the sequencer (shared sequencers, based sequencing that defers ordering back to L1 proposers, PoS sequencer sets) is an active area of work, but as of now you should assume the L2 you're building on has one operator deciding order.

What this means when you read L2 state over RPC

The sequencer shapes how you should treat RPC results on an L2:

• latest is a soft-confirmed head. When you query the latest block on an L2, you're reading the sequencer's view — fast, but pre-L1. For high-value logic, key decisions off blocks that have been posted to L1, not just the freshest L2 head.
• Reorgs happen at the sequencer level. Under normal operation L2 reorgs are rare, but a sequencer restart or a reorg of the L1 batch can roll back soft-confirmed blocks. If you're indexing L2 logs, build in the same reorg handling you'd use on L1 — track block hashes, not just numbers.
• Writes can stall independently of reads. During a sequencer outage your eth_call and eth_getLogs reads keep working against the last produced state, but eth_sendRawTransaction effectively queues. Surface that to users rather than spinning.

A reliable RPC endpoint matters here precisely because the sequencer is already a centralization point you don't control — you don't want your provider to be a second one. Point your L2 reads and writes at endpoints with failover so a single upstream hiccup doesn't compound a sequencer event. SwiftNodes serves the major L2s — Base, Arbitrum, Optimism, Zora — over HTTP and WebSocket under one key:

https://rpc.swiftnodes.io/rpc/base?key=YOUR_API_KEY
wss://rpc.swiftnodes.io/ws/base?key=YOUR_API_KEY

If you're working with WebSocket subscriptions on an L2, the soft-confirmation behavior above is also why reconnect handling matters — see handling WebSocket reconnections without losing events.

The short version

The sequencer is the component that orders transactions and produces blocks on an L2. Today it's almost always a single operator-run service: that's what makes L2s fast, and it's also why "confirmed" on an L2 is a soft promise until the batch hits Ethereum, why a force-inclusion escape hatch exists, and why a chain can briefly stop. Build with that gap in mind — treat the soft-confirmed head as fast-but-provisional, handle reorgs and write stalls, and wait for L1-backed finality when the value justifies it.

Building on an L2? Start free and point your Base, Arbitrum, Optimism, or Zora RPC at SwiftNodes — flat-rate, HTTP and WebSocket, one key across 75+ chains.