Sequencers: The Trust Assumption Inside On-Chain Trading

A rollup executes transactions off the base chain and posts the results to it, inheriting the base chain's security for settlement. Someone has to decide which transactions are included and in what order, and on most rollups that someone is a single operator called the sequencer, usually run by the team behind the chain.

What a sequencer can do

It can order transactions as it chooses, which is the same power that makes transaction ordering valuable anywhere — with the difference that here it belongs to one party by default rather than being contested.

It can delay or refuse to include a transaction. Not permanently, if the design includes an escape hatch, but for as long as that hatch takes to use.

It can stop entirely. A sequencer outage halts the chain: no trades, no liquidations, no withdrawals through the normal path, for the duration.

What it cannot do is forge state. It cannot take your funds or produce an invalid result, because settlement is verified against the base chain — by fraud proofs in optimistic designs or by validity proofs in others. That constraint is real and it is the reason rollups are meaningfully different from a database with an audit log.

Forced inclusion, and why it is the number that matters

Well-designed rollups let a user submit a transaction directly to the base chain, bypassing the sequencer, which must then include it within a defined window or the chain is considered invalid.

That mechanism is what turns censorship from a permanent risk into a bounded delay. Its value depends entirely on the length of the window, and the windows are long — long enough that a leveraged position can be liquidated several times over before a forced transaction lands.

So for a trader the honest reading is: your funds cannot be taken and your ability to act can be suspended for a period measured in hours. Whether that is acceptable depends on what you are holding while it happens.

Why a leveraged venue is the worst case

A sequencer outage on a chain used for payments is an inconvenience. On a leveraged trading venue it is a specific hazard, because positions continue to exist while the mechanism for managing them does not.

You cannot add margin. You cannot close. Liquidations may not execute either, which sounds protective and is not — the venue emerges from the outage with positions that should have been closed and prices that have moved, and the resulting shortfalls are exactly the ones the insurance fund and its fallbacks are for.

This is why the sequencer question belongs in a venue assessment rather than in a chain assessment. The same architecture is a minor consideration for one use and the dominant one for another.

What decentralised sequencing changes

Several designs distribute sequencing across multiple parties, so no single operator can censor or halt the chain alone.

This removes the single point of failure and adds coordination overhead, which usually costs latency — and latency is what a trading venue is optimising for. That tension is why the fastest venues tend to have the most centralised sequencing, and it is a genuine engineering trade rather than negligence.

The useful question is not whether sequencing is decentralised but whether the venue is honest about the arrangement, and whether the escape hatch works and has been tested.

• Who operates the sequencer, and is it a single party.
• Does forced inclusion via the base chain exist, and what is the window before a bypassed transaction must be included.
• What is the outage record, and how did the venue handle positions during it.
• Are proofs validity-based or fraud-based, and what is the challenge period for withdrawals.
• For a leveraged position specifically: what happens to margin calls and liquidations during a halt.