Every major Ethereum L2 uses a centralized sequencer. Arbitrum One, Base, Optimism, zkSync Era, Starknet, Scroll, Linea: all of them rely on a single entity to order and batch transactions. Arbitrum has had 8+ sequencer outages since its Nitro upgrade in August 2022, ranging from 30 minutes to several hours. Linea experienced a 5-hour outage. These are the largest L2s with $34B+ in combined TVL.
When the sequencer goes down, your L2 stops processing transactions. No trades, no liquidations, no withdrawals. Your funds are on-chain and technically safe, but inaccessible until the sequencer comes back. For DeFi protocols, the consequences go beyond inconvenience.
This article covers what happens during sequencer downtime, what the escape hatches look like in practice, and what your protocol needs to handle.
What a Sequencer Does
The sequencer collects incoming transactions, orders them, executes them in the L2 environment, and periodically batches the results for submission to Ethereum L1. It is the single component that determines transaction ordering, execution speed, and liveness of the L2.
On Arbitrum, the sequencer is operated exclusively by Offchain Labs. On Base, by Coinbase. On Optimism, by the Optimism Foundation. On zkSync, by Matter Labs. On Starknet, by StarkWare. There is no permissionless fallback sequencer on any major L2 in production today.
If the sequencer stops, the L2 stops. Existing state is preserved (it's already committed to L1), but no new state transitions occur until the sequencer resumes.
What Goes Wrong During Downtime
Transactions halt
No deposits, withdrawals, swaps, or contract interactions. Users see pending transactions that never confirm. Wallets show balances but cannot move funds. For most users this feels identical to the chain being "down," because functionally it is.
Oracle prices freeze
Price feeds dependent on L2 execution stop updating. Chainlink explicitly recommends that all protocols on optimistic L2s check the Sequencer Uptime Feed before using oracle data. If your protocol reads a Chainlink price on Arbitrum without checking sequencer status, you may execute trades or liquidations against stale prices when the sequencer resumes.
// Chainlink's recommended pattern for L2 protocols
(, int256 answer, uint256 startedAt, , ) = sequencerUptimeFeed.latestRoundData();
bool isSequencerUp = answer == 0;
if (!isSequencerUp) {
revert SequencerDown();
}
// Check grace period after sequencer comes back up
uint256 timeSinceUp = block.timestamp - startedAt;
if (timeSinceUp <= GRACE_PERIOD_TIME) {
revert GracePeriodNotOver();
}
// Only now safe to use price data
(, int256 price, , , ) = priceFeed.latestRoundData();
Chainlink provides Sequencer Uptime Feed contracts on Arbitrum, Base, Optimism, Scroll, zkSync, and other L2s. If your protocol uses Chainlink on an L2 and does not check this feed, that is an audit finding.
Liquidations fail
Lending protocols cannot execute liquidations during sequencer downtime. If prices move significantly while the sequencer is offline, positions that should be liquidated accumulate. When the sequencer resumes, a wave of liquidations hits simultaneously. This can create cascading liquidations, oracle front-running, and bad debt for the protocol.
In December 2023, Arbitrum's sequencer went down for approximately 2 hours during a surge in inscription traffic. The Arbitrum Discord filled with traders worried about what would happen to their leveraged positions when the network came back online. GMX, Aave, and other DeFi protocols on Arbitrum were effectively frozen.
Withdrawals blocked
Users cannot initiate withdrawals to L1 during downtime. For optimistic rollups, the 7-day challenge period doesn't start until the withdrawal transaction is processed by the sequencer. For protocols that need rapid L1 settlement (bridges, exchanges), sequencer downtime creates operational risk proportional to the capital at stake.
The Escape Hatch: Force Inclusion
Arbitrum's "delayed inbox" allows users to submit transactions directly to L1, bypassing the sequencer. When the sequencer comes back online, it must process all delayed inbox messages before accepting new transactions. This is the theoretical escape hatch.
In practice:
It requires technical knowledge. Users need to construct L1 calldata that interacts with Arbitrum's inbox contracts. There is no simple wallet UI for this. You need CLI tools or custom scripts.
It requires L1 gas. Submitting a transaction through the delayed inbox costs L1 gas prices, which can be 10-100x higher than normal L2 transaction costs.
It has a delay. On Arbitrum, delayed inbox messages are processed with a ~24 hour delay (configurable). This is to prevent the delayed inbox from being used to front-run the sequencer. Your "escape" takes a day.
It only works for simple operations. Complex DeFi interactions that depend on current L2 state (liquidations, swaps at specific prices) cannot be meaningfully executed through force inclusion because the L2 state is frozen.
Optimism's force inclusion works similarly through its L1 "OptimismPortal" contract. zkSync and Starknet have their own L1 fallback mechanisms, but practical documentation and tooling for end users is sparse.
The escape hatch exists. It works. It is not practical for most users in most situations.
What Your Protocol Should Do
Check the Sequencer Uptime Feed
If your protocol uses Chainlink oracles on any L2, integrate the Sequencer Uptime Feed. Reject stale prices during and immediately after sequencer downtime. Implement a grace period (30-60 minutes) after the sequencer resumes before accepting price data. This prevents front-running with stale oracle prices.
Design for downtime scenarios
Answer these questions for your protocol:
What happens to open positions if the sequencer is down for 6 hours? For 24 hours? For a week?
Can liquidations backlog create bad debt? If yes, implement a grace period after sequencer restart where liquidations are throttled or positions are given time to add collateral.
Are there time-sensitive operations (auctions, vesting cliffs, governance deadlines) that break if the chain freezes? If yes, measure time in L1 blocks when it matters, not L2 blocks.
Can users' funds be permanently locked if the sequencer never comes back? If yes, implement emergency withdrawal mechanisms that rely only on L1 state.
Implement circuit breakers for post-downtime
When the sequencer resumes after an outage, a burst of pending transactions hits simultaneously. This creates MEV opportunities, oracle arbitrage, and liquidation cascades. Your protocol should detect sequencer recovery and impose temporary limits: reduced position sizes, paused liquidations for a grace period, or delayed execution of large orders.
Monitor sequencer status
Integrate Chainlink's Sequencer Uptime Feed into your monitoring stack. Alert your operations team when any L2 your protocol depends on has a sequencer outage. If you operate across multiple L2s, have a plan for which operations to pause and which to reroute.
The Decentralization Question
Decentralized sequencer networks are on every major L2's roadmap. Arbitrum's documentation mentions a "distributed committee of sequencers." Optimism discusses shared sequencing through the Superchain. In practice, no major L2 has deployed a permissionless sequencer in production as of early 2026.
The challenges are real: transaction ordering in a decentralized sequencer introduces MEV extraction problems, consensus overhead reduces throughput, and economic security of the sequencer set needs bootstrapping. These are solvable problems, but they're unsolved today.
For now, sequencer centralization is the trade-off every L2 makes for performance. If your protocol depends on an L2, plan accordingly: the sequencer will go down, and when it does, your protocol needs to handle it gracefully.
At BugBlow, we audit protocols deployed on L2s for sequencer-related risks: oracle integration without uptime checks, liquidation logic that fails during downtime, time-sensitive operations measured in L2 blocks, and missing emergency withdrawal mechanisms. See our methodology →
FAQ
Can I lose funds during a sequencer outage?
Your funds remain on-chain and are secured by L1. You will not lose funds from the sequencer going offline. However, you can lose value: positions may become undercollateralized during downtime (and get liquidated when the sequencer resumes), time-sensitive opportunities are missed, and oracle-dependent operations may execute at stale prices after restart. The risk is indirect but real.
How often do L2 sequencers go down?
Arbitrum has experienced 8+ outages since its Nitro upgrade (August 2022), ranging from 30 minutes to several hours. Most were caused by software bugs or traffic surges, not attacks. Linea had a 5-hour outage. Other L2s have had similar incidents. Outages are infrequent (months between them) but they happen.
Does force inclusion protect me during downtime?
Force inclusion lets you submit transactions to the L2 through L1. On Arbitrum, messages through the delayed inbox have a ~24 hour processing delay and cost L1 gas. It's a functional escape hatch for simple operations (withdrawals), but impractical for complex DeFi interactions that depend on current L2 state (liquidations at specific prices, swaps). Most users lack the technical knowledge to use it.
Should I build on multiple L2s to reduce sequencer risk?
For critical operations where availability matters (bridges, exchanges, institutional settlement), multi-L2 deployment provides redundancy. If one L2's sequencer goes down, the protocol can route operations through another. For most protocols, this complexity is unnecessary. A simpler approach: integrate Chainlink's Sequencer Uptime Feed, implement post-downtime grace periods, and ensure emergency withdrawal mechanisms exist.
When will L2 sequencers be decentralized?
Every major L2 has decentralized sequencing on its roadmap. None have deployed it in production. The challenges (MEV, consensus overhead, economic security) are real and unsolved at scale. Practical decentralization of sequencers is likely 2-3 years away for major L2s. Plan for centralized sequencers as the current reality.
Next Step
Sequencer downtime is a when, not an if. If your protocol runs on an L2, oracle integration, liquidation logic, and time-sensitive operations all need to account for sequencer unavailability.
BugBlow audits L2-deployed protocols for sequencer-related risks. Request an audit →