When an L2 sequencer stops, what can still move?

A layer-2 network can have a valid transaction history while its usual transaction service is unavailable. If the sequencer stops accepting or ordering transactions, users may lose the fast path for making new state changes without the earlier history becoming invalid.

That is primarily a liveness question: can the system make progress? It is separate from how firmly a particular transaction is settled and from how soon a withdrawal can complete. Those latter questions are covered in the guide to L2 finality and withdrawals. Here the issue is which paths remain usable when the normal operator is absent.

First locate the unavailable component

A failed wallet request does not by itself prove a sequencer outage. A wallet interface, RPC endpoint, sequencer, batch publisher and withdrawal interface serve different functions. The same visible symptom—an action that appears stuck—can originate at different points.

Optimism's transaction-flow documentation separates execution, batch publication and state-root proposals. That separation supplies a useful diagnostic: distinguish inability to submit a new transaction from delay in publishing already sequenced data or completing a later withdrawal step.

Switching interfaces may solve an interface failure. It does not establish that an independent protocol path exists around the sequencer. That requires the specific chain's mechanism and deployed configuration.

OP Stack: submit through Ethereum, then await derivation

Optimism documents a forced-transaction mechanism using an L1 deposit transaction submitted to the OptimismPortal. “Deposit” here is a protocol transaction type; the mechanism need not involve depositing additional value. Such a transaction can initiate an action on L2, including a withdrawal.

The forced-transaction guide explains an important timing qualification. During extended sequencer downtime, an L1 submission is not equivalent to immediate settled L2 execution. Chain derivation must account for the sequencing window and any admissible sequencer data. After the relevant window expires, nodes can derive deposit-only progress deterministically from L1.

The guide checked on 23 September 2026 describes a 12-hour sequencing window. That is a scoped documentation parameter, not a promise that any named asset will be spendable elsewhere exactly 12 hours after an outage starts. The window is rolling, and a particular submission's timing and withdrawal dependencies still matter. Other OP Stack deployments require their own configuration check.

Arbitrum: delayed messages and force inclusion

Arbitrum documents a non-sequencer submission path through the Delayed Inbox on the parent chain. If the sequencer does not incorporate a message, eligible messages can subsequently be forced into the ordered input. Submission and force inclusion are distinct events; recording a message in the inbox is not the whole process. See the Arbitrum transaction lifecycle.

It would be misleading to turn that into a fixed universal delay. Arbitrum's sequencer documentation describes a Censorship Timeout mechanism that can reduce the force-inclusion threshold when delayed messages remain unprocessed. Chain parameters and the mechanism's state affect the relevant window.

These mechanisms address inclusion despite an unavailable or censoring sequencer. They do not promise that a forced contract call will succeed. It must still satisfy the application's execution conditions.

An exit has dependencies after inclusion

For the OP withdrawal flow, initiating the withdrawal on L2 is followed by proving it on L1 and later finalizing it. The withdrawal documentation says proving requires a proposal covering the withdrawal. Finalization also depends on proof maturity and the relevant dispute game's resolution and finality conditions.

Consequently, a mechanism capable of forcing withdrawal initiation is not automatically an instant exit. Ask how the required proposal, proof and later transactions can be produced and submitted during the outage. Access to L1 and the means to pay its transaction fees are practical dependencies as well.

A worksheet for checking an outage claim

The worksheet tests an operational claim; it is not an emergency transaction tutorial. An alternative bridge or liquidity provider is another service with its own dependencies, as the guide to native tokens and bridge risk explains. Evaluate the entire route from a presently usable account to the desired destination before interpreting “there is an escape hatch” as a complete description.