◆Sequencer
Who decides the order
Ordering is power. What the sequencer can do, what it cannot, and what stops it from doing the rest.
The sequencer decides what order transactions execute in. That is real power — it sets who trades first, whose liquidation lands, whose mint succeeds — so the interesting question is not how fast it is but what it is allowed to do and what stops it.
01Powers
What the sequencer can and cannot do
- CanChoose the order of transactions inside a batch
- CanDelay a transaction, or decline to include it
- CanSee transactions before they execute
- CannotForge state — an invalid root is provable once proofs enforce
- CannotTake your funds — it never holds them
- CannotCensor you indefinitely — forced inclusion routes around it
- CannotDeny the order it gave you — its signed receipt fixes your position before execution
Ordering policy
In progressA policy is only meaningful if someone outside can check it was followed. "We order fairly" is not checkable. Today's rule is first-come, first-served by admission, and it is checkable: every accepted transaction gets a signed receipt fixing its batch and position before execution, and the published batch has to match those receipts — a mismatch is a contradiction anyone holding both can prove. The alternatives below remain on the table; whichever is chosen is published in a form that can be verified against published batch data.
First-come, first-served
Ordered by arrival at the sequencer. Simple to state and to check — the current rule — but it rewards proximity to the endpoint and invites latency races.
Priority fee auction
Ordered by fee. Transparent and familiar from the base layer, but it puts ordering up for sale — which is the honest description of what a fee auction is.
Encrypted until ordered
Transaction contents are hidden from the sequencer until order is fixed, which removes the ability to front-run at the cost of complexity and latency.
On MEV
A sequencer that can see transactions before it orders them can extract value from that position. Saying "we do not do this" is not a control — the control is either a policy that can be checked from outside, or an architecture where the sequencer cannot see contents before committing to an order. Solieum will state which one it is using, and will not claim front-running resistance without the second.
One thing worth being exact about, because it is a common misunderstanding: the fraud proof does not protect you here. Fraud proofs catch invalid state. Reordering valid transactions produces a perfectly valid state — in the implementation's own test, shuffling a batch of transfers reaches a byte-identical state root, so the proof system sees nothing wrong, because nothing about the state is wrong. What catches it is the signed receipt: the sequencer commits to your position before executing, and publishing a different order contradicts a signature it already gave. That contradiction is provable by anyone holding the receipt and the published batch. Detection is implemented and tested; turning a proof into a penalty needs a slashing contract that does not exist yet.
02Continuity
What happens when it stops
- Single operator at launch. Honest starting position. It is a liveness and ordering monopoly, and it is why forced inclusion ships alongside it rather than later — the inbox program is on devnet and the node drains it every block.
- Deterministic replay. A replacement sequencer rebuilds exact state from published data, with nothing handed over by the previous operator. The node exercises this on every restart: it keeps no state snapshot, re-executes the published bytes, and refuses to start if any block fails to reproduce its committed root. Measured after a kill and restart: slot, balances, every root and every receipt byte-identical.
- One signer per slot. A sequencer that assigns two different transactions to the same slot has signed a contradiction, and anyone holding both receipts can prove it — that detection is implemented and tested. The penalty exists too: the bond program is deployed on devnet, the sequencer has 0.1 SOL bonded against that key, and a proven double-assignment takes it, half to whoever reports it. So on the devnet chains this is an economic property and not only an accountability one — and a bond outlives its chain: beta's stands, unslashed, after beta stopped on 2026-09-12. What it is not yet is large — a bond of that size prices equivocation for a test chain, and the mainnet figure is a decision still open.
- Staked sequencer set. A rotating set with signed hand-offs, then bonded participation with slashing for provable equivocation. It is a roadmap stage after proofs enforce, with a condition rather than a date, and it decides ordering only: finality stays with Solana, and there will be no validator set of our own deciding state.
03Lifecycle
Life of a transaction inside the sequencer
Between "submitted" and "soft-confirmed" there are five distinct moments. Naming them makes the powers and limits above concrete.
- 01
Admission: the transaction arrives and is checked — signature valid, fee payable, not a duplicate. Failures here are instant and explicit.
- 02
Mempool: it waits, briefly, with everything else admitted and not yet ordered. This is where ordering policy matters — what may the sequencer see, and what may it do with what it sees?
- 03
Ordering: the policy assigns it a position and the sequencer signs a receipt for that position before executing anything. Under the published rule this is mechanical; the receipt is what turns any later deviation into a provable contradiction.
- 04
Execution: it runs against current L2 state in its assigned order. Success or failure is now deterministic — any honest re-execution of the batch reproduces it exactly.
- 05
Acknowledgement: the soft confirmation returns. From here its fate is bound to the batch: published, committed, and eventually final, with no further sequencer discretion involved.
What a soft confirmation is worth
It is the sequencer promising "you are in this batch, at this position, with this result." For a game action or a social post, that is plenty — act on it. For anything that leaves the system (a withdrawal, an exchange credit), it is worth nothing until the batch is published and the root is final, because until then the promise is revocable by exactly the party that made it. The network page's three-numbers section is this same point, generalised.
Building something the base layer can't hold?
Tell us the workload. If Solieum is the wrong answer for it, we would rather say so early than have you find out at launch.