LibraryScaling2022Design paperCorpus record
The Espresso Sequencer
Espresso. Espresso Systems.
A shared sequencer orders transactions for many rollups. Each rollup still executes its own state. The sequencer sells order, not execution.
A reading of the public document. Not a copy of it, and not a claim about a later network that reused the name.
Ask what a rollup does when the shared sequencer stops. If the answer is 'it waits', the sequencer is a dependency, not a convenience.
The five-minute read
The defect
Every rollup that runs its own sequencer rebuilds the same leader, the same liveness risk, and a separate place to extract order.
The rule
A shared sequencer orders transactions for many rollups. Each rollup still executes its own state. The sequencer sells order, not execution.
How it is put together
Order is a service. Execution stays with the rollup. A shared leader is also a shared censorship point, unless the design says otherwise.
Where the claim stops
The note is not a claim that the sequencer is decentralised on day one.
One action, walked through
- Rollups submit transactions to the sequencer.
- The sequencer publishes an order.
- Each rollup executes that order and settles or proves on its own.
- Can a rollup escape the sequencer?
The argument, unpacked
Why it is still on the desk
Ask what a rollup does when the shared sequencer stops. If the answer is 'it waits', the sequencer is a dependency, not a convenience.
After the text
Astria and others proposed variants. The split between order and execution is the part worth keeping.
What has to be true
- The note is not a claim that the sequencer is decentralised on day one.
- Sharing a sequencer does not share security of execution.
- A rollup can still publish its own data elsewhere.
What happened after the paper
Astria and others proposed variants. The split between order and execution is the part worth keeping.
What to check before you use the idea
- Can a rollup escape the sequencer?
- Does the sequencer see the contents?
- Who pays if the order halts?
Terms
- Shared sequencer
- One ordering service used by more than one rollup.
- Execution
- Applying transactions to a rollup's own state.
The problem the paper names
Every rollup that runs its own sequencer rebuilds the same leader, the same liveness risk, and a separate place to extract order.
What the design proposes
- Order is a service.
- Execution stays with the rollup.
- A shared leader is also a shared censorship point, unless the design says otherwise.
How the mechanism is specified
- Rollups submit transactions to the sequencer.
- The sequencer publishes an order.
- Each rollup executes that order and settles or proves on its own.
What this page does not treat as proven
- The note is not a claim that the sequencer is decentralised on day one.
- Sharing a sequencer does not share security of execution.
- A rollup can still publish its own data elsewhere.
Why a venture studio still reads it
Ask what a rollup does when the shared sequencer stops. If the answer is 'it waits', the sequencer is a dependency, not a convenience.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.