Skip to content
Financial Context Wiki

What to do when an L2 sequencer is down

A practical response plan for L2 sequencer downtime: verify the outage, avoid duplicate transactions, check the rollup's L1 fallback, and allow for recovery and liquidation risks.

Updated

For educational purposes only; not investment advice. Investing may result in loss.

Direct answer

Treat a sequencer outage as a loss of normal L2 access, not as proof that the rollup or your assets have failed. Stop time-sensitive actions, verify the incident through the chain’s official status page and independent RPC or explorer data, and learn the exact L1 fallback for that rollup before signing anything.

  1. Record the chain, wallet address, pending transaction hashes, last observed block, and time of failure.
  2. Do not repeatedly resubmit or raise fees while the transaction’s status is unknown.
  3. Check whether the unsafe head is moving while the safe or finalized head is stalled; that can indicate a batch-publication outage rather than a total halt.
  4. Use an L1 forced-transaction or withdrawal path only from official documentation and verified contract addresses.
  5. After recovery, wait for the backlog, oracle status, bridge status, and application-specific grace period to normalize before adding leverage or assuming a transaction is final.

How it works

A sequencer normally receives, orders, and rapidly confirms L2 transactions, then publishes the data needed to derive the chain to its data-availability layer. A downtime outage can prevent ordinary RPC submission. A separate submission outage can leave the sequencer producing unsafe blocks while publication to L1, and therefore the safe and finalized heads, stops. Those states have different reorganization and recovery risks.

The fallback is implementation-specific. On OP Stack chains, a user can submit an L2 transaction through the chain’s verified OptimismPortal on L1; the default sequencing window is 12 hours but can differ by chain. Arbitrum Nitro uses an L1 Delayed Inbox, and its published design describes forced inclusion after a 24-hour threshold. These mechanisms provide eventual inclusion, not an instant or universal escape route, and still require L1 gas and the correct chain-specific contracts.

Applications also need their own controls. A sequencer uptime feed can signal downtime, but it is distinct from a price feed. Lending and derivatives protocols can pause sensitive operations during the outage and enforce a recovery grace period so queued oracle updates and user transactions are not immediately turned into unfair liquidations.

Example

A borrower has ETH collateral in an L2 lending protocol. The sequencer is unavailable for 2 hours while ETH falls 15%, so the borrower cannot add collateral through the normal RPC. The protocol detects the outage, pauses liquidations, and keeps them paused for a configured 1-hour grace period after the uptime feed reports recovery.

The borrower records the pending transaction hash, checks the official incident notice and the rollup’s safe head, and does not trust a support message offering an “unfreeze” link. If action is still necessary, the borrower follows that rollup’s official L1 path and verifies the portal or inbox address. After recovery, the borrower waits for the forced transaction, price feed, and account health to be reflected in a safe block before relying on the result.

Risks

  • Recovery liquidations: queued transactions and price updates may be processed close together; without a grace period, users who could not transact during downtime can be liquidated immediately.
  • Unsafe-state reorganization: an RPC may show recent blocks that have not been published to L1 and could be reorganized if the publication window expires.
  • Stale or mismatched signals: a moving price feed does not prove that users can transact, and an uptime feed does not prove that a price is current.
  • Forced-path execution risk: direct L1 calls are more technical and expensive; a wrong network, contract, calldata, nonce, or gas limit can fail or strand funds.
  • Dependent-system delays: bridges, exchanges, keepers, indexers, and front ends can recover on different schedules even after the sequencer resumes.

Common misconceptions

  • “The sequencer is down, so the assets are gone.” The L1-enforced rollup state may remain intact even though normal access is unavailable.
  • “Every rollup has the same force-inclusion delay.” Windows, contracts, and supported actions differ by implementation and chain configuration.
  • “A forced transaction executes immediately.” L1 submission establishes a route to eventual inclusion; it does not remove sequencing, proof, or withdrawal delays.
  • “Once blocks resume, liquidation risk is over.” Backlogs, oracle updates, and keepers can create the highest risk during recovery.
  • “A status-page link from support is safe.” Verify the domain and contract address independently; never disclose a seed phrase or private key.

Sources

Navigation

Search the wiki...