Sequencer Outages and Liveness Failures

Scroll operates a centralized sequencer that is responsible for ordering user transactions, producing L2 blocks, and providing soft confirmations. Unlike Ethereum L1 where multiple validators can propose blocks, Scroll's sequencer is currently the sole entity authorized to build blocks. If the sequencer process halts—due to a crash, network partition, resource exhaustion, or operational error—the chain stops producing new blocks entirely. No new transactions are accepted, and no state updates occur until the sequencer is restored. This liveness model is a deliberate architectural choice in Scroll's phased decentralization roadmap, prioritizing throughput and simplicity before transitioning to a distributed sequencer set.

During a sequencer outage, users experience immediate transaction submission failures. Wallets, exchanges, and DeFi frontends that rely on the sequencer's RPC will see rejected or dropped transactions. Critically, Scroll's forced transaction mechanism—the escape hatch that allows users to submit L2 transactions directly via L1—is designed to guarantee eventual inclusion even if the sequencer is censoring or unavailable. However, the forced inclusion path introduces a significant delay (often on the order of hours or a full challenge period) before the transaction is executed on L2. This delay is not a bug but a fundamental trade-off in the security model. Operations teams must understand that forced transactions are a censorship-resistance backstop, not a real-time failover for sequencer liveness.

For exchanges, custodians, and high-frequency DeFi protocols, sequencer liveness failures directly impact deposit and withdrawal SLAs. A sequencer halt freezes all L2 state, meaning L1-to-L2 deposits cannot be processed and L2-to-L1 withdrawals cannot be initiated or finalized until block production resumes. Monitoring sequencer health is therefore a critical operational requirement. Teams should track block production intervals, sequencer RPC responsiveness, and the time since the last L2 block. Chainscore Labs can assist with designing comprehensive sequencer liveness monitoring, forced-transaction inclusion testing, and operational playbooks that map failure modes to specific response procedures, ensuring your integration remains resilient during Scroll network outages.

Scroll's architecture relies on a centralized sequencer for transaction ordering and fast pre-confirmations. This design introduces a critical liveness dependency: if the sequencer halts or maliciously censors transactions, the network's ability to process user operations is compromised. To mitigate this, Scroll implements a forced transaction mechanism—an on-chain escape hatch on Ethereum L1 that allows users to submit transactions directly to the rollup contract, bypassing the sequencer entirely. This mechanism is the ultimate backstop for censorship resistance, ensuring that even during a prolonged sequencer outage, users retain the ability to withdraw assets and execute critical state changes.

The forced transaction flow works by allowing users to submit their L2 transaction data directly to Scroll's L1ScrollMessenger or rollup contract on Ethereum. After a defined waiting period, the sequencer is obligated to include this transaction in a future batch. If the sequencer fails to do so, the protocol's smart contracts can advance the chain state without the sequencer's cooperation, effectively forcing the inclusion of the pending transaction. This mechanism is not designed for routine use—it is slower and more expensive than the standard sequencer path—but it is the foundational guarantee that Scroll is a rollup, not a custodial service. For exchanges, custodians, and institutional users managing high-value withdrawals, verifying the operational readiness of this path is a critical security requirement.

The effectiveness of this safety net depends on continuous monitoring and operational preparedness. During a sequencer outage, the forced transaction path can become congested, and gas costs on L1 may spike. Teams that rely on Scroll must have pre-built, tested procedures for submitting forced withdrawal transactions and monitoring their inclusion. Chainscore Labs can assist infrastructure teams in designing and testing these emergency procedures, auditing the forced inclusion path for integration correctness, and building real-time alerting systems that trigger when sequencer liveness deviates from expected SLAs.