Shared Sequencing & Based Rollups

The Sequencer Problem

Most rollups today run a single 'sequencer' — one operator that receives your transactions, decides the order they go in, and batches them down to the base layer (Ethereum). That sequencer is usually run by the rollup's own team. It is fast and cheap, but it is also a point of centralisation: a single sequencer can, in principle, censor transactions (refuse to include yours), extract value by reordering trades (MEV), or simply go offline and halt the chain. The security guarantees people associate with rollups mostly protect against the sequencer stealing funds — not against it censoring, front-running, or stalling. Decentralising the sequencer is one of the open frontiers of rollup design.

Two Answers: Shared Sequencing and Based Rollups

Two approaches aim to fix this. A shared sequencer is a separate, decentralised network that many rollups plug into to order their transactions, instead of each running its own solo operator — spreading the trust and, as a bonus, enabling coordinated ordering across rollups. A based rollup takes a different route: it hands sequencing back to Ethereum's own validators (the base layer, hence 'based'), so the rollup inherits Ethereum's existing decentralisation and censorship resistance rather than bootstrapping its own. Both are attempts to remove the single-operator bottleneck; they make different trade-offs about speed, revenue, and complexity.

• A sequencer orders a rollup's transactions and batches them to the base layer
• A solo sequencer can censor, reorder for profit (MEV), or halt the chain
• Shared sequencers: a decentralised network many rollups share for ordering
• Based rollups: sequencing done by Ethereum's own validators (L1-sequenced)

How Shared Sequencing Works

A shared sequencer is its own network of nodes that runs consensus over transaction ordering and offers that ordering as a service to multiple rollups (Espresso and Astria are prominent examples). Rollups outsource the 'decide the order' step to this shared layer, gaining decentralisation they would otherwise have to build alone. The headline extra feature is atomic cross-rollup composability: because one network orders transactions for several rollups, it can guarantee that a bundle of actions across different rollups either all execute in the intended order or none do — something impossible when each rollup sequences in isolation. The cost is a new external dependency and trust in the shared network's liveness and honesty, plus questions about how MEV and revenue are shared.

How Based Rollups Work

A based rollup delegates sequencing to Ethereum L1: the next Ethereum block proposer (or a delegated party) also sequences the rollup's transactions, so the rollup's ordering is embedded directly in L1 block-building. The rollup inherits Ethereum's decentralisation and censorship resistance 'for free' and needs no separate sequencer network or token to secure ordering. The trade-offs are real: naively, confirmations arrive only as fast as Ethereum blocks (~12 seconds), and the rollup gives up the sequencer fee revenue a solo operator would keep. Much of the active research on based rollups is about restoring fast user experience on top of L1 sequencing — which is where preconfirmations come in.

Preconfirmations

Preconfirmations ('preconfs') are promises, made before a block is final, that a transaction will be included and ordered a certain way — letting users get a fast, credible 'yes' in milliseconds while final settlement still happens at base-layer speed. In based-rollup designs, L1 proposers (or delegated preconfers) stake something and issue signed preconfirmations they are penalised for breaking, giving users near-instant soft confirmation without a centralised sequencer. Preconfs are how based rollups aim to combine L1-inherited decentralisation with the snappy UX people expect. They are an active, unfinished area: the exact staking, slashing, and delegation mechanics are still being designed and tested.

• Shared sequencers order transactions for many rollups, enabling atomic cross-rollup composability
• Based rollups let Ethereum's own proposers sequence, inheriting L1 censorship resistance
• Based rollups trade away fast solo confirmations and sequencer fee revenue
• Preconfirmations restore fast UX via staked, slashable inclusion promises

The Trade-off Space: Revenue, Latency, and Trust

The choice between solo, shared, and based sequencing is a three-way tension between revenue, latency, and trust-minimisation. Solo sequencing maximises revenue capture and speed but concentrates trust. Based sequencing maximises trust-minimisation (Ethereum-level) but naively sacrifices latency and hands MEV/fee revenue to L1 proposers rather than the rollup. Shared sequencing sits in between, distributing trust across a dedicated network while introducing dependency on that network's liveness and its own MEV/revenue-sharing politics. There is no free lunch: every design that decentralises ordering must answer where sequencing revenue and MEV flow, how fast users get credible confirmations, and what new liveness assumptions are introduced. Reading a rollup's architecture means locating it in this space rather than accepting 'decentralised' as a binary.

MEV, Cross-Rollup Atomicity, and New Attack Surface

Decentralised sequencing reshapes MEV rather than eliminating it. Shared sequencers can enable cross-domain MEV (value extracted across the rollups they serve) and must decide how ordering rights and MEV are auctioned and redistributed. Atomic cross-rollup composability is a genuine new capability — bundles that span rollups executing all-or-nothing — but it also creates new coordination and failure modes. Based rollups push sequencing into L1 block-building, entangling rollup ordering with Ethereum's own proposer-builder dynamics and preconfirmation markets. Each design closes the solo-operator attack surface while opening new ones (shared-network liveness, preconf slashing correctness, cross-domain MEV), so the honest analysis is about which trust assumptions you prefer, not whether trust has been removed.

How to Read the Landscape

For a sophisticated observer, sequencing decentralisation is a spectrum with concrete questions at each point: Is there one operator or many? Can it censor, and is there an L1 forced-inclusion or escape hatch? Where do sequencing fees and MEV go? What new liveness or network dependencies does the design add, and are they live in production or still testnet? Shared sequencing and based rollups are promising directions that attack a genuine centralisation gap, but the field is early, standards are unsettled, and most 'rollup security' marketing still glosses over who controls ordering today. The mature stance is to evaluate the current, shipped state of a chain's sequencing — not its roadmap — and to weigh the specific trust assumptions each design substitutes for the solo-operator risk it removes.