Sequencer Centralization and Forced Inclusion

Most rollups run on a sequencer: a single operator that receives user transactions, decides their order, and batches them for settlement on the base chain. Concentrating this role in one party is efficient — it can order and confirm transactions in milliseconds — but it creates a single point of control. A malicious or compromised sequencer could reorder transactions for its own profit, or simply refuse to include someone's transaction at all, effectively censoring them.

The standard defense is a forced-inclusion mechanism: if the sequencer ignores a user's transaction for too long, the user can submit it directly to the base chain's smart contract, and the rollup's rules require that transaction be processed within a set window regardless of what the sequencer wants. This doesn't make the sequencer decentralized, but it caps the damage a censoring sequencer can do.

Worked example. A rollup sets a forced-inclusion window of 24 hours. If a user's swap sits unprocessed by the sequencer for that long, they submit it directly on the base layer; the rollup's contract then requires it be included in the very next batch, overriding the sequencer's discretion.

Forced inclusion is deliberately made slow and clunky compared to the normal sequencer path, so it functions as an emergency exit rather than a routine option — most users never need it, and its mere existence is what keeps the sequencer honest day to day. Several rollup teams have publicly committed roadmaps toward sharing or rotating the sequencer role among multiple parties, precisely to reduce how much users need to rely on that fallback in the first place.