Sequencer

What sequencers do

In a typical Layer 2 rollup:

1. Users submit transactions to the rollup.
2. Sequencer collects pending transactions.
3. Orders them into blocks.
4. Executes the transactions in the chosen order.
5. Computes new state.
6. Posts data and proofs to the underlying L1.

The sequencer is the entity making real-time ordering decisions for L2 transactions.

Why sequencer design matters

Several effects:

• Performance — sequencers handle execution that gives L2s their speed.
• MEV control — sequencers can extract or limit MEV.
• Censorship potential — sequencers can refuse to include transactions.
• Single point of failure when centralized.
• Revenue capture — fee revenue often goes to sequencers.

Sequencer arrangements directly affect L2 user experience and trust assumptions.

Centralized sequencers

The current state of most L2s:

• Single sequencer operated by L2 team.
• Operational reliability has been generally good.
• Censorship hasn't been widely abused.
• Theoretical vulnerability remains.
• Decentralization roadmaps in development.

Major L2s (Arbitrum, Optimism, Base) all currently have centralized sequencers.

Sequencer outages

Some have happened:

• Arbitrum sequencer outages — multiple brief incidents.
• Various L2 outages during stress periods.
• Recovery typically quick — within hours or days.
• Force-include mechanisms allow direct L1 submission as backup.

These outages have demonstrated centralized-sequencer fragility but haven't caused permanent issues.

Sequencer revenue

Economic considerations:

• Transaction fees typically go to sequencer.
• Major revenue source for L2 operators.
• Profitable for active L2s — substantial revenue.
• Affects long-term L2 economics.

This is why sequencer arrangements have economic significance beyond technical operation.

Decentralizing sequencers

Active research:

• Multiple sequencers rotating roles.
• Shared sequencing across multiple L2s.
• Permissionless sequencer markets.
• Sequencer auctions for ordering rights.
• Various proposed designs.

Implementation has been gradual; concrete decentralized sequencer deployments are rare so far.

Sequencer vs. validator

Different roles:

• L1 validators — secure underlying chain through consensus.
• L2 sequencers — order transactions and produce L2 blocks.
• Different security model — sequencer trust is operational; L1 validator trust is cryptographic.

The trust model affects how secure L2 transactions are between submission and L1 finality.

What individuals should know

For users:

• Sequencer is mostly invisible in normal operation.
• Outages can affect L2 usability briefly.
• Withdrawals to L1 typically require sequencer cooperation or fallback mechanisms.

For broader awareness:

• Centralized sequencers are current state but theoretical concern.
• Decentralization is active development direction.
• Different L2s have different sequencer architectures.

Sequencers are critical L2 infrastructure that mostly operates invisibly. Their decentralization remains an active development area; current centralized arrangements have worked operationally but represent legitimate trust assumptions users should understand.