L2 sequencer outages: distinguish delay from asset loss
A sequencer outage is first an interruption to a particular transaction path. It does not by itself prove that settled assets have disappeared. Research should distinguish accepting a request, ordering transactions, publishing data, establishing a settlement claim and withdrawing assets. Each stage needs its own evidence and clock.
Ethereum’s optimistic-rollup overview describes sequencers and the relationship between offchain execution and settlement. Implementations vary. Use the actual rollup’s current contracts and documentation before making a claim about forced submission, withdrawal timing or recovery.
Draw the transaction-state timeline
Begin with the last known healthy point. Record the submitted transaction identifier, any sequencer acknowledgment, the relevant L2 block, the batch or data publication on the base layer, and the state commitment used by the settlement system. An application showing a transaction as pending is not evidence that all later stages occurred.
Keep provider availability separate from sequencer availability. A wallet may fail because its RPC endpoint is down while the sequencer continues processing requests from other sources. Conversely, a responsive RPC can serve old state during a sequencing interruption. Compare more than one relevant observation before assigning the fault.
The research question is operational continuity: which actions are delayed, which existing states can still be verified, and which alternative paths are documented? It is not an instruction to move assets during an incident. An untested emergency procedure should remain a research dependency rather than an implied recommendation.
Hypothetical interrupted sequence
Assume a fictional rollup acknowledges a transfer at 10:00. The interface displays it, but the researcher cannot find the containing batch on the settlement layer. At 10:05 the normal sequencer stops responding. The acknowledgment establishes receipt by that service; it does not establish settlement.
A second, earlier transfer already appears in published data and the relevant committed state. Its research status differs from the newer request. Combining both as simply stuck loses the distinction between delayed submission and a later withdrawal dependency. The times are illustrative, not recovery estimates.
Suppose the rollup documents a base-layer inclusion route with prerequisites. Record the contract, eligibility conditions and evidence needed to verify that route. Do not promise immediate execution or a fixed end-to-end withdrawal duration merely because an alternative entry point exists.
Continuity worksheet
| Stage | Evidence | What remains unproven |
|---|---|---|
| Request acknowledged | Service receipt | Inclusion and settlement |
| L2 block observed | Block and transaction data | Base-layer publication |
| Batch published | Base-layer transaction | Applicable settlement completion |
| State committed | Commitment and protocol context | Withdrawal readiness |
| Withdrawal available | Implementation-specific state | Future service availability |
For every row, add observation time, source endpoint and a status such as observed, unavailable or not yet applicable. Do not infer missing stages from the fact that later website text sounds reassuring. Match transaction identity across stages, especially where an application uses internal request identifiers.
Separate recovery claims from evidence
An incident report may describe the cause and operator response. Preserve it as the operator’s account, then compare it with the transaction timeline. The report may explain a delay without proving that every user’s request reached the same stage. Avoid using one successful transaction as a complete population test.
After service resumes, check whether formerly pending requests were included, replaced, rejected or remained unresolved. A responsive status page is not the same as reconciliation of the original requests. Retain the earlier observations so the recovery review does not rewrite the incident history.
Common mistakes include equating wallet display with finality, calling all outages asset loss, and treating an alternative path as instant recovery. A sound spot-asset memo describes the blocked stage, verified prior state and remaining dependencies. It leaves unknown outcomes visible instead of filling the gaps with either alarm or reassurance.
FAQ
Does a working RPC prove the sequencer is healthy?
No. It may return historical state. Check evidence of new processing and the specific service being tested.
Does sequencer downtime prove assets are lost?
No. Determine the relevant transaction stage and implementation-specific recovery or withdrawal conditions before making that claim.