Sequencer Failure and Forced Exit

How it happens

Most rollups today run a single sequencer that receives transactions, orders them, and gives users a fast soft confirmation before the batch is posted to the settlement chain. If the sequencer halts, the chain stops accepting new transactions even though funds remain safe on the layer below, and if it censors, a specific user stops being served. The designed remedy is forced inclusion: submitting the transaction directly to the settlement layer's inbox, after which the rollup must include it within a fixed window. That path only helps if it is actually implemented, exercised, and usable in the conditions where it is needed, which are exactly the conditions where settlement-layer fees tend to be high, and optimistic designs add a challenge period before withdrawals complete.

What you can actually observe

Check whether the sequencer is permissioned and who runs it, whether a forced-inclusion mechanism exists in the deployed contracts, what its delay window is, and whether anyone has demonstrably used it. Read who can upgrade the bridge and the proof system, whether those upgrades pass a timelock, and whether a security council can bypass the timelock. Published uptime records and incident post-mortems show how often the sequencer has stopped and for how long.

Precedent

Major rollups have experienced sequencer outages lasting hours during which no new transactions were processed, while balances remained recoverable on the settlement layer.

What makes it more or less material

Consider whether forced inclusion is implemented and tested, the length of the delay and challenge windows, who holds upgrade keys over the bridge, and whether the proof system is live or still permissioned.