> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nullark.com/llms.txt
> Use this file to discover all available pages before exploring further.

# What a Groth16 proof proves

Understand what an accepted Nullark Groth16 proof tells you and where artifact, setup, and deployment evidence enters.

Nullark uses Groth16 to show that a private witness satisfies a circuit relation for an ordered public statement. Verification is concise, but you still have to trust the circuit semantics, setup provenance, proving files, verifier identity, and deployment state.

## What acceptance means

Given a fixed circuit, verification key, proof, and set of public inputs, acceptance means that a witness exists for the encoded relation under Groth16 security assumptions.

For a withdrawal, that relation is intended to fix bundle membership, selected-child authority, nullifier, destination, amount, fee, chain, verifying contract, proof context, and encrypted payload hash.

## Trust chain

```mermaid
flowchart TB
  subgraph Relation["Reviewed relation and setup"]
    SRC["Circuit source"] -->|compile constraints| CS["Constraint system"]
    CS -->|compile witness code| WASM["WASM witness generator"]
    CS -->|run relation-specific ceremony| SETUP["Trusted setup"]
    SETUP -->|produce proving key| ZKEY["zkey"]
    SETUP -->|produce verification key| VKEY["Verification key"]
    VKEY -->|generate and deploy| BYTECODE["Verifier bytecode"]
  end

  subgraph Client["Trusted client"]
    INPUT["Private witness + public intent"] -->|provide inputs| PROVER["Browser prover"]
    WASM -->|hash-checked code| PROVER
    ZKEY -->|hash-checked proving key| PROVER
    PROVER -->|produce| PACKAGE["Proof + ordered public inputs"]
  end

  subgraph Chain["MegaETH verification"]
    CHECK{"Deployed verifier accepts?"}
    CHECK -->|yes| SETTLE["Pool state transition"]
    CHECK -->|no| REVERT["Revert: state unchanged"]
  end

  BYTECODE -->|defines verifier| CHECK
  PACKAGE -->|submit| CHECK
```

Each edge needs its own evidence. Artifact identity comes from independent pins and reviewed bindings around the proof.

## Trusted setup

Groth16 uses relation-specific setup material. Compromised toxic-waste handling or a setup for another circuit can invalidate soundness assumptions even when local verification passes.

Nullark checks browser proving files against an independently bundled SHA-256 pin, the setup record, verifier identity, public-input order, and byte limits. The independent pin anchors manifest trust.

## Evidence beyond proof acceptance

The surrounding system still needs evidence for:

- Circuit source and product intent
- Source-to-constraint compilation
- Trusted setup ceremony
- Authorized proving-artifact release
- Deployed verifier identity and pool routing
- Browser, dependency, wallet, RPC, relayer, and operator integrity
- Transaction privacy properties
- Pool availability and relayer funding

## Public-input discipline

Public inputs are positional. Correct values in the wrong order define a different verifier statement. Integrations must freeze count, names, order hash, and field encoding with the exact verifier and artifacts.

See [Withdrawal public inputs](/reference/public-inputs.md) and [Authenticate proving artifacts](/developers/proving-artifacts.md).

## How to read the evidence

Tests cover reviewed behavior. Hashes identify exact files. Formal theorems establish stated properties under their assumptions. Read [Formal verification](/security/formal-verification.md) and [Security status](/security/status.md).