zkProvers

Who this is for: developers who want to know what actually makes a Lumia transaction "final" and trust-minimized, rather than just "included in a block."

What a prover does

A sequencer can order and batch transactions, but ordering alone doesn't establish that a batch's resulting state is correct: a malicious or buggy sequencer could produce an invalid batch. The prover is what closes that gap: it generates a cryptographic proof over a batch, and only a batch with a valid proof behind it can be accepted as settled. This is the standard model for a validity-proof (zk) rollup or validium generally, not something unique to Lumia's implementation of it.

Two proof models

There are at least two different things a proof can attest to, and they imply very different trust assumptions:

• Execution proofs: the proof attests that re-executing the batch produces the claimed state transition. This is the strongest guarantee: Ethereum L1 verifies the batch's actual execution.

• Pessimistic proofs: a lighter proof that attests to a narrower claim (for example, that a chain cannot withdraw more from a shared bridge than was deposited into it), without L1 re-verifying full execution.

What this means for developers

Regardless of which specific proof model is active, the guarantee a valid proof gives you is narrower than "the entire history of the chain is correct" unless it's an execution proof. Under a pessimistic-proof model, the proof's scope may be limited to specific properties (like bridge solvency) rather than full-state correctness.