> For the complete documentation index, see [llms.txt](https://docs.lumia.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lumia.org/ecosystem/lumia/chain-security/zkprovers.md).

# 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](https://app.gitbook.com/s/chmhPiVNAafGw48c4oU2/ecosystem/lumia/chain-security/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.

```mermaid
flowchart LR
  SEQ["Sequencer<br/>produces a batch"] --> BATCH["Batch"]
  BATCH --> PROVER["Prover<br/>generates a proof"]
  PROVER --> VER["L1 verifier contract"]
  VER -->|"valid proof"| ACC["Accepted as settled"]
  VER -->|"no valid proof"| REJ["Not accepted"]
```

### 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.