Sequencer Failure and Forced Exit
A rollup relies on one operator to order transactions, so if that operator stops or censors, users need a working escape hatch to the settlement layer.
仕組み
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.
実際に観測できるもの
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.
先例
Major rollups have experienced sequencer outages lasting hours during which no new transactions were processed, while balances remained recoverable on the settlement layer.
重要性を左右する要因
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.
関連要因
この対象となる資産
このファクターが適用されるカテゴリに分類される、最大規模の資産。ここへの掲載は、そのファクターが当該種類の資産に関連することを意味するのであり、それが発生したことを意味するものではない。