Sequencer

Who this is for: developers who want to understand what determines transaction order and finality timing on Lumia before they build something order-sensitive (an AMM, an auction, a liquidation flow).

What the sequencer does

The sequencer is the component that receives submitted transactions, orders them, and groups them into batches. On a validity-proof L2 like Lumia, the sequencer's output is what everything downstream operates on: zkProvers prove the batches it produces, and the resulting proofs are what eventually get settled back to Ethereum L1.

At any given time, transaction ordering on Lumia comes from a single sequencer. A single sequencer means fast, predictable ordering under normal operation, but it also means ordering liveness depends on that one component staying up; this design is common to CDK-based L2s generally, not unique to Lumia.

Batching

Transactions are grouped into batches rather than proven one at a time: batching is what makes proof generation economical, since a proof's cost doesn't scale linearly with how many transactions it covers.

Relation to zkProvers

The sequencer only orders and batches: it does not itself prove anything. Batch correctness is established by zkProvers, which generate the proofs that let a batch be accepted as valid. A batch existing is not the same as a batch being proven; see the zkProvers page for what "proven" means on Lumia specifically.

The role split above, from a submitted transaction to L1 settlement: