When the Sequencer Stops: Shared vs Based Rollup Security
Most rollups run on a single machine that orders every transaction, and when it fails your funds are safe but frozen. Here's how shared and based sequencing change that, and what you give up in return.
Key takeaways
- →A centralized sequencer going down doesn't steal your funds, but it can freeze them for hours, including mid-trade.
- →Force inclusion through Ethereum is the escape hatch, but its built-in delay can be far longer than the outage you're trying to escape.
- →Shared sequencers spread ordering across a network, but they add their own consensus and liveness assumptions on top of Ethereum.
- →Based rollups let Ethereum's own block proposers order transactions, which gives the rollup Ethereum's liveness at the cost of MEV revenue and native speed.
- →Before parking leveraged positions or bankroll on an L2, check who runs the sequencer and how long forced inclusion actually takes.
Most Layer 2 rollups lean on one company-run server to order transactions. When that server stops, the chain stops with it. Your funds don't vanish. They sit there, out of reach, while prices keep moving on every other venue. If you trade with leverage or keep a gambling bankroll on an L2, the gap between funds that are safe and funds that are usable is the risk this lesson is about.
Here's the plan. We'll look at what a sequencer does, why a centralized one is a single point of failure, how shared sequencers and based rollups try to fix that, and what each one costs you. Then there's a checklist you can run against any L2 before you move money onto it.
What a sequencer actually does
A rollup executes transactions off Ethereum and posts compressed data and proofs back to it. Someone has to decide the order those transactions run in. That's the sequencer.
It handles three jobs:
- Accepts transactions from users, usually through the rollup's public RPC endpoint.
- Orders them into L2 blocks and gives you a near-instant confirmation, often within a second.
- Batches and posts that data to Ethereum, where it becomes final.
That fast confirmation is a promise, not a guarantee. People call it a soft confirmation. The sequencer is telling you it will include your transaction in this order. Real finality arrives later, once the batch lands on Ethereum and the rollup's proof or challenge process settles.
On most rollups today, a single operator, usually the team behind the chain, runs the sequencer. It's simple and fast. It's also fragile.
Safety versus liveness
Two words carry most of the weight here.
Safety means nobody can take your funds or forge a state you didn't authorize. On a well-built rollup, safety comes from Ethereum. The sequencer can't post an invalid state, because fraud proofs or validity proofs will reject it.
Liveness means the chain keeps processing transactions. You can trade, withdraw, add margin, cash out a bet.
A centralized sequencer is mostly a liveness problem. It can't steal from you. It can stop serving you. And it can choose to ignore you, which is censorship, a targeted liveness failure.
How centralized sequencer failures halt execution
Say the single sequencer crashes, gets overloaded, hits a software bug, or loses its connection to Ethereum. New transactions stop getting ordered. The L2 block number freezes. Wallets show pending transactions that never confirm. Rollups have had real outages, lasting anywhere from minutes to several hours, for exactly these reasons.
During that window:
- Perp DEX positions can't be closed or topped up.
- Lending positions can't be repaid.
- On-chain casino bets and withdrawals sit in limbo.
- Bridges out of the L2 stop accepting new withdrawals through the normal path.
Meanwhile, centralized exchanges and Ethereum mainnet keep trading. When the sequencer returns, oracle prices jump to catch up, and positions that were healthy before the outage can be underwater instantly.
The escape hatch: force inclusion
Good rollups give you a way around a dead or hostile sequencer. You submit your transaction directly to the rollup's contract on Ethereum. After a set delay, the rollup has to include it, whether the sequencer likes it or not.
That's the theory. The catch is the delay. Designs vary, but force-inclusion windows of many hours, up to a day, are common, because the delay gives the sequencer time to work through the queue normally and avoids reorg chaos. For a short outage, the hatch opens after the problem's already fixed. It protects you from permanent censorship. It does nothing for a leveraged position stuck in a three-hour freeze.
Some rollups have weaker hatches, or none that work without the operator's cooperation. Know that before you deposit, not after.
Option one: shared sequencers
A shared sequencer is a decentralized network of nodes that orders transactions for several rollups at once. Rather than one company's server, a set of operators runs a consensus protocol and agrees on ordering.
What you get:
- No single machine to fail. If one node dies, others keep producing blocks.
- Harder censorship. One operator can't quietly drop your transaction.
- Cross-rollup coordination. Because one network orders several chains, it can promise that a transaction on rollup A and one on rollup B land together. That's useful for arbitrage and cross-chain apps.
What you give up: a shared sequencer is its own system, with its own consensus, validator set and failure modes. If its validators go offline or collude, every rollup using it takes the hit at once. Your liveness now depends on that network plus Ethereum, not Ethereum alone. Better than one server. Not Ethereum-grade.
Option two: based rollups
A based rollup goes further. It doesn't run its own sequencer at all. Ethereum's L1 block proposers, the same validators building mainnet blocks, include and order the rollup's transactions as part of building Ethereum blocks.
The consequence is tidy. If Ethereum is producing blocks, the rollup is producing blocks. Liveness and censorship resistance come straight from Ethereum. There's no separate operator, no separate network, and no force-inclusion delay to wait out, because the normal path already runs through L1.
The price: MEV and speed
Ordering transactions is valuable. Whoever controls it can capture MEV (maximal extractable value): arbitrage, liquidations, sandwiching trades. A centralized sequencer keeps that value for the rollup, which funds the team and its token. A based rollup hands that ordering power, and most of the MEV, to Ethereum's proposers and block builders.
That's the core trade. The rollup gives up a revenue stream and control over ordering, and in return it gets Ethereum's liveness guarantees.
Speed takes a hit too. A centralized sequencer confirms in under a second. A pure based rollup confirms at Ethereum's block time, roughly 12 seconds. Preconfirmation schemes, where L1 proposers commit early to including your transaction, aim to close that gap. They also add complexity and their own trust assumptions.
For users, the MEV shift is concrete. Your trades face the same builder market as Ethereum mainnet. A large swap without slippage protection is a sandwich target.
Side-by-side comparison
| Property | Centralized sequencer | Shared sequencer | Based rollup |
|---|---|---|---|
| Who orders transactions | One operator | Decentralized network | Ethereum L1 proposers |
| Confirmation speed | Sub-second | Seconds | About one L1 block, faster with preconfirmations |
| Liveness depends on | Operator plus Ethereum | Shared network plus Ethereum | Ethereum |
| Censorship resistance | Force inclusion, after a delay | Better, depends on validator set | Same as Ethereum |
| Who captures MEV | Rollup operator | Shared network or rollups, depending on design | Mostly L1 proposers and builders |
| Main failure mode | Single-server outage | Network-wide consensus failure | Ethereum itself stalling |
Worked example: a leveraged position during an outage
All numbers here are hypothetical, for illustration only.
Maya opens a 5x long on a perp DEX running on an L2. She posts $2,000 of collateral for a $10,000 position. The protocol's maintenance margin is 5% of notional, so she's liquidated when her equity drops below $500. She can absorb $1,500 of losses, a 15% drop in the asset.
The asset falls 7%. Her equity is $1,300. She plans to add $1,000 of margin. Right then, the L2's centralized sequencer goes down.
For the next four hours, nothing she submits confirms. The rollup's force-inclusion delay is 24 hours, so the escape hatch is no help. On other venues the asset keeps sliding, and it's down 17% from her entry by the time the sequencer comes back.
On restart, the oracle updates in one jump. Her loss is $1,700, so her $2,000 collateral is down to $300, under the $500 threshold. She's liquidated in the first blocks, likely before her top-up processes, and loses the remaining $300 to the liquidation process. Total damage: her full $2,000, on a move she'd planned to survive.
Run the same scenario on a based rollup. Ethereum kept producing blocks, so the rollup did too. Her top-up lands within a block or two. Her equity goes to $2,300 and her liquidation point moves far lower. The 17% drop leaves her with $600 of equity, still above $500, so she survives. Her extra cost is a higher priority fee, say a few dollars, plus some MEV exposure if she'd been swapping instead of depositing.
Some protocols soften centralized outages with a sequencer uptime oracle and a grace period that pauses liquidations right after a restart. That helps. It's also a protocol-level patch you have to verify, not assume.
How to check an L2's sequencer risk
- Find out who runs the sequencer. Read the rollup's docs and check an independent risk tracker such as L2BEAT. Look for whether it's a single operator, a shared network, or based.
- Find the force-inclusion delay. Search the docs for force inclusion, delayed inbox or sequencing window. Write the number down in hours.
- Confirm the escape hatch works without the operator. Can you force a withdrawal using only Ethereum? Is there an upgrade key that could disable it? Risk trackers usually flag this.
- Check how your app handles downtime. For perps or lending, look for a sequencer uptime check and a post-restart grace period before liquidations resume.
- Size positions for the worst outage, not the average. Ask how far the price could move in several hours, and whether your liquidation price survives it with no chance to add margin.
- Keep ETH on L1. Force inclusion means sending a transaction on Ethereum. You'll need gas there.
- Bookmark the force-inclusion route ahead of time. Find the contract or bridge UI that submits L1 transactions to the rollup, and save it while things are calm.
- Watch block production when things feel off. If the L2 block explorer's latest block stops advancing, the sequencer is down. Stop submitting transactions that may confirm later at a worse price.
Common mistakes
- Treating soft confirmations as final. A sequencer confirmation is a promise. Until the batch is on Ethereum, a faulty or malicious sequencer can, in some designs, reorder or drop it.
- Assuming decentralized means Ethereum-secure. A shared sequencer with a small validator set runs on a different trust model from Ethereum. Check who the validators are.
- Thinking force inclusion is fast. It's a censorship guarantee, not an outage fix. A 24-hour window does nothing for a 4-hour freeze.
- Running max leverage on a chain with a single sequencer. High leverage demands constant access. A single point of failure and thin margin don't mix.
- Ignoring MEV on based rollups. Inheriting Ethereum's liveness means inheriting its builder market too. Set tight slippage limits.
- Spamming retries during an outage. Queued transactions can all execute after restart, at prices you no longer want.
FAQ
Can a centralized sequencer steal my funds?
On a rollup with working fraud or validity proofs, no. It can't post an invalid state. It can delay, reorder or censor your transactions, and it can extract MEV from your trades. The bigger theft risk usually sits elsewhere, in upgrade keys that let a team change the contracts.
Are based rollups always slower?
Without extra machinery, confirmations follow Ethereum's block time, roughly 12 seconds. Preconfirmation designs let L1 proposers commit to your transaction earlier, which brings the experience closer to a centralized sequencer. They come with added complexity and their own trust assumptions.
If I only gamble small amounts, does any of this matter?
Less, but not zero. A frozen sequencer can strand a withdrawal or a pending bet for hours. If you need funds at a specific time, say to cover a bet elsewhere or to move during a volatile event, liveness is the property you're actually relying on.
Every rollup ends up answering the same question: who gets paid for ordering transactions, and who carries the risk when ordering stops? Centralized sequencers keep the revenue and hand you the downtime risk. Based rollups give the revenue away to buy Ethereum's uptime. Which bargain you take should depend on how badly you need your money to move in the next five minutes.
