{
  "name": "The ZK Field Manual — every option",
  "version": "1.3",
  "dateModified": "2026-09-12",
  "license": "https://creativecommons.org/licenses/by/4.0/",
  "options": [
    {
      "type": "option",
      "name": "Groth16",
      "slug": "groth16",
      "section": {
        "id": "proof-systems",
        "number": "01",
        "title": "Choosing a proof system",
        "url": "https://zkpick.com/proof-systems/"
      },
      "url": "https://zkpick.com/proof-systems/groth16/",
      "markdown": "https://zkpick.com/md/proof-systems/groth16.md",
      "category": "Pairing-based SNARK",
      "summary": "Groth16: Pairing-based SNARK. Setup: Circuit-specific. Proof size: 3 group elements: 128 B compressed, 256 B as EVM calldata. On-chain verification: Cheapest deployed option. PQ: No. Recursion: Via curve cycles; awkward. Maturity: Production since 2016. Prover cost profile: 256-bit-field MSMs and FFTs; roughly linear in constraints with a high constant. Mature GPU provers exist. Peak prover memory: Proving key resident in RAM, growing with circuit size — the usual browser and mobile limit. Off-chain verifier: Milliseconds: three pairings. Implementations and maintainers: snarkjs and rapidsnark (iden3), gnark (Consensys), arkworks, bellman (Zcash lineage), ICICLE GPU backends (Ingonyama). Where it is measured: Delendum zk-benchmarking; wrapper cost inside every zkVM benchmark on ethproofs.org. Choose it when: A stable circuit verified on-chain at high frequency where gas is the binding constraint. Also the standard final compression layer for STARK-based systems.",
      "description": "The 2016 pairing-based preprocessing SNARK over R1CS: the proof is three group elements verified with a single pairing product equation. Requires a per-circuit setup on top of a reusable universal phase one.",
      "notes": [],
      "sections": [],
      "strengths": [
        "The smallest proofs and cheapest verifier of any widely deployed system",
        "The cheapest realistic on-chain verification on Ethereum",
        "Extremely well understood, with many independent implementations and a decade of scrutiny"
      ],
      "tradeoffs": [
        "Circuit-specific trusted setup: any circuit change means a new ceremony, and toxic waste breaks soundness for that circuit permanently",
        "No universality — setup cannot be amortised across circuits",
        "Not post-quantum",
        "Proofs are re-randomisable, which breaks any application treating a proof as a unique object"
      ],
      "bestFit": "A stable circuit verified on-chain at high frequency where gas is the binding constraint. Also the standard final compression layer for STARK-based systems.",
      "maintainers": "Construction by Jens Groth (2016). Implementations: snarkjs and rapidsnark (iden3), gnark (Consensys), arkworks, bellman (Zcash lineage), ICICLE GPU backends (Ingonyama)",
      "maturity": "Production since 2016",
      "license": "n/a (construction)",
      "source": "https://eprint.iacr.org/2016/260",
      "facts": [
        {
          "table": "Proof system selection matrix",
          "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-groth16",
          "name": "Groth16",
          "setup": "Circuit-specific",
          "size": "3 group elements: 128 B compressed, 256 B as EVM calldata",
          "verify": "Cheapest deployed option",
          "pq": "No",
          "recursion": "Via curve cycles; awkward",
          "maturity": "Production since 2016"
        },
        {
          "table": "Prover profile, implementations and benchmarks",
          "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-groth16",
          "name": "Groth16",
          "prover": "256-bit-field MSMs and FFTs; roughly linear in constraints with a high constant. Mature GPU provers exist.",
          "memory": "Proving key resident in RAM, growing with circuit size — the usual browser and mobile limit",
          "offchain": "Milliseconds: three pairings",
          "impls": "snarkjs and rapidsnark (iden3), gnark (Consensys), arkworks, bellman (Zcash lineage), ICICLE GPU backends (Ingonyama)",
          "bench": "Delendum zk-benchmarking; wrapper cost inside every zkVM benchmark on ethproofs.org"
        }
      ],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "Groth16 — On the size of pairing-based non-interactive arguments",
          "url": "https://eprint.iacr.org/2016/260",
          "kind": "paper"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "PLONK and the PLONKish family",
      "slug": "plonk",
      "section": {
        "id": "proof-systems",
        "number": "01",
        "title": "Choosing a proof system",
        "url": "https://zkpick.com/proof-systems/"
      },
      "url": "https://zkpick.com/proof-systems/plonk/",
      "markdown": "https://zkpick.com/md/proof-systems/plonk.md",
      "category": "Pairing-based SNARK, universal SRS",
      "summary": "PLONK and the PLONKish family: Pairing-based SNARK, universal SRS. Setup: Universal, updatable. Proof size: Sub-kilobyte. On-chain verification: Practical; above Groth16. PQ: No. Recursion: Well-exercised. Maturity: Production; most common deployed family. Prover cost profile: 256-bit-field FFTs dominate; custom gates and lookups trade prover work for constraint count. Peak prover memory: SRS and witness polynomials resident; comparable to Groth16 at equal size. Off-chain verifier: Milliseconds. Implementations and maintainers: Barretenberg / UltraHonk (Aztec), gnark (Consensys), plonky2 (Polygon Zero lineage), Kimchi (o1Labs), Halo2 forks. Where it is measured: Vendor-published only; no neutral cross-implementation suite. Choose it when: General-purpose circuits where churn is expected and a per-circuit ceremony would be painful, and where on-chain verification is required but need not be absolutely minimal.",
      "description": "A permutation-argument-based universal SNARK over a custom-gate arithmetisation — selector columns, copy constraints, optional lookup columns. One SRS serves all circuits up to a size bound. The most frequently occurring family among deployed on-chain verifiers.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Universal, updatable SRS — one ceremony, many circuits, no per-circuit phase two",
        "Flexible arithmetisation: custom gates and lookups express non-arithmetic operations efficiently",
        "Verifier cost close to Groth16 and still practical on-chain",
        "Very large ecosystem with many independent implementations"
      ],
      "tradeoffs": [
        "Larger proofs and higher gas than Groth16",
        "Not post-quantum",
        "Prover requires large-field FFTs, the main bottleneck at scale",
        "Arithmetisation flexibility is also a footgun — custom gates and lookup tables are a common source of underconstrained circuits",
        "'PLONK' names a family, not one artefact: two implementations may share little"
      ],
      "bestFit": "General-purpose circuits where churn is expected and a per-circuit ceremony would be painful, and where on-chain verification is required but need not be absolutely minimal.",
      "maintainers": "Construction by Gabizon, Williamson and Ciobotaru (Aztec, 2019). Implementations: Barretenberg / UltraHonk (Aztec), gnark (Consensys), plonky2 (Polygon Zero lineage), Kimchi (o1Labs), Halo2 forks",
      "maturity": "Production; most common deployed family",
      "license": "n/a (construction)",
      "source": "https://eprint.iacr.org/2019/953",
      "facts": [
        {
          "table": "Proof system selection matrix",
          "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-plonk-family",
          "name": "PLONK family",
          "setup": "Universal, updatable",
          "size": "Sub-kilobyte",
          "verify": "Practical; above Groth16",
          "pq": "No",
          "recursion": "Well-exercised",
          "maturity": "Production; most common deployed family"
        },
        {
          "table": "Prover profile, implementations and benchmarks",
          "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-plonk-family",
          "name": "PLONK family",
          "prover": "256-bit-field FFTs dominate; custom gates and lookups trade prover work for constraint count",
          "memory": "SRS and witness polynomials resident; comparable to Groth16 at equal size",
          "offchain": "Milliseconds",
          "impls": "Barretenberg / UltraHonk (Aztec), gnark (Consensys), plonky2 (Polygon Zero lineage), Kimchi (o1Labs), Halo2 forks",
          "bench": "Vendor-published only; no neutral cross-implementation suite"
        }
      ],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "PLONK — permutations over Lagrange bases for oecumenical noninteractive arguments",
          "url": "https://eprint.iacr.org/2019/953",
          "kind": "paper"
        },
        {
          "title": "fflonk — a fast-Fourier inspired verifier efficient variant of PLONK",
          "url": "https://eprint.iacr.org/2021/1167",
          "kind": "paper"
        },
        {
          "title": "HyperPlonk — PLONK with linear-time prover and high-degree custom gates",
          "url": "https://eprint.iacr.org/2022/1355",
          "kind": "paper"
        },
        {
          "title": "Plonky3 — polynomial IOP toolkit over small fields",
          "url": "https://github.com/Plonky3/Plonky3",
          "kind": "project"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "FRI-based STARKs",
      "slug": "starks",
      "section": {
        "id": "proof-systems",
        "number": "01",
        "title": "Choosing a proof system",
        "url": "https://zkpick.com/proof-systems/"
      },
      "url": "https://zkpick.com/proof-systems/starks/",
      "markdown": "https://zkpick.com/md/proof-systems/starks.md",
      "category": "Transparent hash-based proof system",
      "summary": "FRI-based STARKs: Transparent hash-based proof system. Setup: None. Proof size: Tens to hundreds of KB. On-chain verification: Impractical directly — wrapper is standard. PQ: Plausibly. Recursion: Well-exercised. Maturity: Heavily production. Prover cost profile: Small-field hashing and NTTs; the fastest bulk provers on CPU and GPU, and the basis of most zkVMs. Peak prover memory: Trace-proportional, but small fields keep it low; continuations bound it. Off-chain verifier: Milliseconds to tens of milliseconds — hashing only. Implementations and maintainers: Stone and Stwo (StarkWare), Plonky3 (Polygon Zero lineage; beneath SP1 Turbo, OpenVM, Ziren, Pico), RISC Zero, Miden, ZKsync Airbender (Matter Labs), Winterfell. Where it is measured: ethproofs.org real-time Ethereum block proving; a16z zkvm-benchmarks. Assumption: Hash (collision resistance). Setup: None. Opening size: Polylogarithmic but large in absolute terms. Verifier cost: Polylogarithmic; expensive on-chain. Field constraint: High two-adicity; extension for challenges. Choose it when: High-throughput server-side proving of large computations, especially zkVM execution, where a final wrapper handles settlement.",
      "description": "AIR or PLONKish arithmetisation committed with Reed–Solomon codewords and Merkle trees, with FRI as the low-degree test. No trusted setup, hash-based, plausibly post-quantum. The workhorse of large-scale transparent proving: StarkWare's Stone and Stwo, the Plonky2 and Plonky3 toolkits, RISC Zero, Miden and ZKsync Airbender are all instances of this family, differing mainly in field, hash and lookup argument.",
      "notes": [],
      "sections": [],
      "strengths": [
        "No trusted setup; security reduces to hash collision resistance plus the FRI soundness analysis",
        "Plausibly post-quantum in the proving layer",
        "Small-field arithmetic gives excellent CPU and GPU throughput; Circle STARK constructions extend this to fields that FRI could not otherwise use",
        "Scales well to very large computations"
      ],
      "tradeoffs": [
        "Proofs are tens to hundreds of kilobytes and verifiers are expensive, so a pairing-based wrapper is standard — which reintroduces a trusted setup and removes post-quantum security",
        "Security parameters are a dial, and deployed systems routinely ship 96–100 bits rather than 128",
        "Requires a field with high two-adicity and enough size, or an extension, for challenges",
        "Parameter tuning across rate, queries, grinding and decoding regime is easy to get wrong"
      ],
      "bestFit": "High-throughput server-side proving of large computations, especially zkVM execution, where a final wrapper handles settlement.",
      "maintainers": "Construction by Ben-Sasson, Bentov, Horesh and Riabzev (StarkWare, 2018). Implementations: Stone and Stwo (StarkWare), Plonky2 and Plonky3 (Polygon Zero lineage), RISC Zero, Miden, ZKsync Airbender (Matter Labs), Winterfell",
      "maturity": "Heavily production",
      "license": "n/a (construction)",
      "source": "https://eprint.iacr.org/2018/046",
      "facts": [
        {
          "table": "Proof system selection matrix",
          "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-fri-based-starks",
          "name": "FRI-based STARKs",
          "setup": "None",
          "size": "Tens to hundreds of KB",
          "verify": "Impractical directly — wrapper is standard",
          "pq": "Plausibly",
          "recursion": "Well-exercised",
          "maturity": "Heavily production"
        },
        {
          "table": "Prover profile, implementations and benchmarks",
          "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-fri-based-starks",
          "name": "FRI-based STARKs",
          "prover": "Small-field hashing and NTTs; the fastest bulk provers on CPU and GPU, and the basis of most zkVMs",
          "memory": "Trace-proportional, but small fields keep it low; continuations bound it",
          "offchain": "Milliseconds to tens of milliseconds — hashing only",
          "impls": "Stone and Stwo (StarkWare), Plonky3 (Polygon Zero lineage; beneath SP1 Turbo, OpenVM, Ziren, Pico), RISC Zero, Miden, ZKsync Airbender (Matter Labs), Winterfell",
          "bench": "ethproofs.org real-time Ethereum block proving; a16z zkvm-benchmarks"
        },
        {
          "table": "Commitment schemes — the layer that decides most of it",
          "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-3-fri",
          "name": "FRI",
          "basis": "Hash (collision resistance)",
          "setup": "None",
          "opening": "Polylogarithmic but large in absolute terms",
          "verifier": "Polylogarithmic; expensive on-chain",
          "field": "High two-adicity; extension for challenges"
        }
      ],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "Scalable, transparent, and post-quantum secure computational integrity (STARKs)",
          "url": "https://eprint.iacr.org/2018/046",
          "kind": "paper"
        },
        {
          "title": "Circle STARKs — making Mersenne-31 usable for FRI-based systems",
          "url": "https://eprint.iacr.org/2024/278",
          "kind": "paper"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Halo2 with IPA, and Halo2 with KZG",
      "slug": "halo2",
      "section": {
        "id": "proof-systems",
        "number": "01",
        "title": "Choosing a proof system",
        "url": "https://zkpick.com/proof-systems/"
      },
      "url": "https://zkpick.com/proof-systems/halo2/",
      "markdown": "https://zkpick.com/md/proof-systems/halo2.md",
      "category": "PLONKish SNARK — two distinct trust models",
      "summary": "Halo2 with IPA, and Halo2 with KZG: PLONKish SNARK — two distinct trust models. As Halo2 + IPA — Setup: None. Proof size: Logarithmic. On-chain verification: Impractical — verifier linear in circuit size. PQ: No. Recursion: Native, via accumulation on a curve cycle. Maturity: Years in production; gadget-layer bug in 2026. As Halo2 + KZG — Setup: Universal, updatable. Proof size: Constant. On-chain verification: Practical. PQ: No. Recursion: Supported. Maturity: Production; central maintenance declining. As Halo2 + IPA — Prover cost profile: MSM-dominated over the Pasta curve cycle; no pairing-curve FFT bottleneck. Peak prover memory: Proportional to circuit size; moderate. Off-chain verifier: Linear in circuit size — tens to hundreds of milliseconds for large circuits. Implementations and maintainers: zcash/halo2 (Electric Coin Company). Where it is measured: Zcash Orchard figures; no neutral suite. As Halo2 + KZG — Prover cost profile: 256-bit-field FFTs over BN254; the largest gadget ecosystem of any PLONKish frontend. Peak prover memory: SRS resident; large circuits need tens of gigabytes. Off-chain verifier: Milliseconds. Implementations and maintainers: privacy-ethereum/halo2 (Ethereum Foundation PSE, maintenance mode), halo2-lib (Axiom), Scroll's fork. Where it is measured: Scroll and Axiom published figures; no neutral suite. Choose it when: IPA: systems verified on a node rather than in a gas-metered contract, where trusted setup is unacceptable. KZG: EVM-verified application circuits and coprocessors needing expressive custom gates.",
      "description": "The same PLONKish frontend with two very different backends. The original uses an inner-product argument over a curve cycle and needs no trusted setup, with recursion via accumulation. The widely used Ethereum-oriented variant replaces IPA with KZG, giving constant-size proofs and a practical Solidity verifier — and a universal trusted setup. These are routinely conflated.",
      "notes": [],
      "sections": [],
      "strengths": [
        "The IPA variant needs no trusted setup and has years of deployment in a value-bearing system",
        "Recursion without pairing-friendly curves, via accumulation on a two-cycle",
        "The KZG variant gives constant-size proofs and EVM-practical verification",
        "Rich, expressive frontend with mature circuit libraries for elliptic-curve and hashing work"
      ],
      "tradeoffs": [
        "IPA verification is linear in circuit size — that variant is not an EVM settlement candidate",
        "The KZG variant reintroduces a universal trusted setup, unlike the original — a frequent source of confusion",
        "Neither is post-quantum",
        "The ecosystem has fragmented into forks that are not drop-in compatible and have uneven maintenance",
        "Maturity of the construction does not transfer to its gadget libraries: a counterfeiting bug in the upstream ECC gadget prompted an emergency response in 2026 — check the current status of any deployment cited as evidence"
      ],
      "bestFit": "IPA: systems verified on a node rather than in a gas-metered contract, where trusted setup is unacceptable. KZG: EVM-verified application circuits and coprocessors needing expressive custom gates.",
      "maintainers": "Halo by Bowe, Grigg and Hopwood (Electric Coin Company, 2019); upstream halo2 maintained by Electric Coin Company. KZG fork by Ethereum Foundation PSE (maintenance mode); halo2-lib by Axiom; further forks at Scroll and others",
      "maturity": "Long production history; forks vary",
      "license": "n/a (construction)",
      "source": "https://eprint.iacr.org/2019/1021",
      "facts": [
        {
          "table": "Proof system selection matrix",
          "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-halo2-ipa",
          "name": "Halo2 + IPA",
          "setup": "None",
          "size": "Logarithmic",
          "verify": "Impractical — verifier linear in circuit size",
          "pq": "No",
          "recursion": "Native, via accumulation on a curve cycle",
          "maturity": "Years in production; gadget-layer bug in 2026"
        },
        {
          "table": "Proof system selection matrix",
          "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-halo2-kzg",
          "name": "Halo2 + KZG",
          "setup": "Universal, updatable",
          "size": "Constant",
          "verify": "Practical",
          "pq": "No",
          "recursion": "Supported",
          "maturity": "Production; central maintenance declining"
        },
        {
          "table": "Prover profile, implementations and benchmarks",
          "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-halo2-ipa",
          "name": "Halo2 + IPA",
          "prover": "MSM-dominated over the Pasta curve cycle; no pairing-curve FFT bottleneck",
          "memory": "Proportional to circuit size; moderate",
          "offchain": "Linear in circuit size — tens to hundreds of milliseconds for large circuits",
          "impls": "zcash/halo2 (Electric Coin Company)",
          "bench": "Zcash Orchard figures; no neutral suite"
        },
        {
          "table": "Prover profile, implementations and benchmarks",
          "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-halo2-kzg",
          "name": "Halo2 + KZG",
          "prover": "256-bit-field FFTs over BN254; the largest gadget ecosystem of any PLONKish frontend",
          "memory": "SRS resident; large circuits need tens of gigabytes",
          "offchain": "Milliseconds",
          "impls": "privacy-ethereum/halo2 (Ethereum Foundation PSE, maintenance mode), halo2-lib (Axiom), Scroll's fork",
          "bench": "Scroll and Axiom published figures; no neutral suite"
        }
      ],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "Halo — recursive proof composition without a trusted setup",
          "url": "https://eprint.iacr.org/2019/1021",
          "kind": "paper"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Nova, SuperNova and HyperNova",
      "slug": "nova-folding",
      "section": {
        "id": "proof-systems",
        "number": "01",
        "title": "Choosing a proof system",
        "url": "https://zkpick.com/proof-systems/"
      },
      "url": "https://zkpick.com/proof-systems/nova-folding/",
      "markdown": "https://zkpick.com/md/proof-systems/nova-folding.md",
      "category": "Folding schemes / IVC",
      "summary": "Nova, SuperNova and HyperNova: Folding schemes / IVC. Setup: None in the folding layer. Proof size: Accumulator, not a proof — needs final compression. On-chain verification: Via the compressing SNARK only. PQ: No. Recursion: This is the whole point. Maturity: Research to early production. Prover cost profile: Two MSMs per step — the cheapest incremental step known. Peak prover memory: Bounded by one step plus the accumulator. Off-chain verifier: Only after final compression. Implementations and maintainers: Nova (Microsoft Research), Sonobe (Ethereum Foundation lineage), arecibo (Argument Computer). Where it is measured: Repository benchmarks only; no neutral suite. Choose it when: Long, repetitive computations and memory-constrained provers, where the final compression step happens once.",
      "description": "Folding reduces checking two instances of a relation to checking one, so each step of a long computation costs a couple of multi-scalar multiplications rather than an in-circuit SNARK verification. Variants add non-uniform steps and generalised constraint systems.",
      "notes": [],
      "sections": [],
      "strengths": [
        "The lowest known per-step recursion overhead for long, near-uniform computations",
        "Memory-friendly: proving is incremental, so peak memory tracks one step rather than the whole trace",
        "No trusted setup in the folding layer itself",
        "Non-uniform variants avoid paying for the union of all instructions at every step"
      ],
      "tradeoffs": [
        "Folding produces an accumulator, not a succinct proof — a final compressing SNARK is still required, and its cost is often omitted from benchmarks",
        "Not post-quantum: security rests on discrete log in the commitment scheme",
        "Real soundness pitfalls have been published in cycle-of-curves constructions — this is subtle territory",
        "Implementation maturity trails the pairing-based and FRI families"
      ],
      "bestFit": "Long, repetitive computations and memory-constrained provers, where the final compression step happens once.",
      "maintainers": "Nova by Kothapalli, Setty and Tzialla (Microsoft Research, 2021); SuperNova and HyperNova from the same lineage. Implementations: Nova (Microsoft Research), Sonobe (Ethereum Foundation lineage), arecibo (Argument Computer)",
      "maturity": "Research to early production",
      "license": "n/a (construction)",
      "source": "https://eprint.iacr.org/2021/370",
      "facts": [
        {
          "table": "Proof system selection matrix",
          "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-nova-folding-schemes",
          "name": "Nova / folding schemes",
          "setup": "None in the folding layer",
          "size": "Accumulator, not a proof — needs final compression",
          "verify": "Via the compressing SNARK only",
          "pq": "No",
          "recursion": "This is the whole point",
          "maturity": "Research to early production"
        },
        {
          "table": "Prover profile, implementations and benchmarks",
          "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-nova-folding-schemes",
          "name": "Nova / folding schemes",
          "prover": "Two MSMs per step — the cheapest incremental step known",
          "memory": "Bounded by one step plus the accumulator",
          "offchain": "Only after final compression",
          "impls": "Nova (Microsoft Research), Sonobe (Ethereum Foundation lineage), arecibo (Argument Computer)",
          "bench": "Repository benchmarks only; no neutral suite"
        }
      ],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "Nova — recursive zero-knowledge arguments from folding schemes",
          "url": "https://eprint.iacr.org/2021/370",
          "kind": "paper"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Binius and binary-field systems",
      "slug": "binius",
      "section": {
        "id": "proof-systems",
        "number": "01",
        "title": "Choosing a proof system",
        "url": "https://zkpick.com/proof-systems/"
      },
      "url": "https://zkpick.com/proof-systems/binius/",
      "markdown": "https://zkpick.com/md/proof-systems/binius.md",
      "category": "Transparent hash-based, binary fields",
      "summary": "Binius and binary-field systems: Transparent hash-based, binary fields. Setup: None. Proof size: Hash-based scale. On-chain verification: Impractical directly. PQ: Plausibly. Recursion: Developing. Maturity: Early production; fast-moving codebase. Prover cost profile: Binary-field arithmetic maps to hardware bit operations; strongest on hashing and bitwise workloads. Peak prover memory: Low — tiny field elements, no embedding overhead. Off-chain verifier: Milliseconds. Implementations and maintainers: Binius64 (Irreducible); the original binius repository is archived. Where it is measured: Irreducible's published figures; few independent measurements. Assumption: Hash over binary fields. Setup: None. Opening size: Hash-based scale. Verifier cost: Polylogarithmic. Field constraint: Binary field towers. Choose it when: Hash- and bitwise-heavy workloads, and client-side proving, for teams able to track a fast-moving codebase.",
      "description": "SNARKs over towers of binary fields, with a commitment that has no embedding overhead for tiny field elements. The current generation computes natively over 64-bit words with built-in bitwise and multiplication constraints, explicitly targeting client-side proving on commodity CPUs.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Binary-field arithmetic maps directly to hardware bit operations — a strong fit for hashing, ciphers and bit manipulation",
        "No trusted setup; hash-based and plausibly post-quantum",
        "Explicitly targets commodity CPUs rather than GPU clusters"
      ],
      "tradeoffs": [
        "The most volatile family here: the original implementation was archived and superseded, with significant features still on the roadmap at the successor's launch — confirm current capability before designing around it",
        "Small implementation and auditor base",
        "Not directly on-chain verifiable"
      ],
      "bestFit": "Hash- and bitwise-heavy workloads, and client-side proving, for teams able to track a fast-moving codebase.",
      "maintainers": "Diamond and Posen (Irreducible, formerly Ulvetanna, 2023). Implementation: Binius64 (Irreducible)",
      "maturity": "Early production; active development",
      "license": "n/a (construction)",
      "source": "https://eprint.iacr.org/2023/1784",
      "facts": [
        {
          "table": "Proof system selection matrix",
          "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-binius-binary-fields",
          "name": "Binius (binary fields)",
          "setup": "None",
          "size": "Hash-based scale",
          "verify": "Impractical directly",
          "pq": "Plausibly",
          "recursion": "Developing",
          "maturity": "Early production; fast-moving codebase"
        },
        {
          "table": "Prover profile, implementations and benchmarks",
          "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-binius-binary-fields",
          "name": "Binius (binary fields)",
          "prover": "Binary-field arithmetic maps to hardware bit operations; strongest on hashing and bitwise workloads",
          "memory": "Low — tiny field elements, no embedding overhead",
          "offchain": "Milliseconds",
          "impls": "Binius64 (Irreducible); the original binius repository is archived",
          "bench": "Irreducible's published figures; few independent measurements"
        },
        {
          "table": "Commitment schemes — the layer that decides most of it",
          "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-3-binius-commitments",
          "name": "Binius commitments",
          "basis": "Hash over binary fields",
          "setup": "None",
          "opening": "Hash-based scale",
          "verifier": "Polylogarithmic",
          "field": "Binary field towers"
        }
      ],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "Binius — succinct arguments over towers of binary fields",
          "url": "https://eprint.iacr.org/2023/1784",
          "kind": "paper"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "STIR and WHIR",
      "slug": "stir-whir",
      "section": {
        "id": "proof-systems",
        "number": "01",
        "title": "Choosing a proof system",
        "url": "https://zkpick.com/proof-systems/"
      },
      "url": "https://zkpick.com/proof-systems/stir-whir/",
      "markdown": "https://zkpick.com/md/proof-systems/stir-whir.md",
      "category": "Hash-based low-degree tests",
      "summary": "STIR and WHIR: Hash-based low-degree tests. Setup: None. Proof size: Markedly smaller than FRI at equal security. On-chain verification: Impractical directly. PQ: Plausibly. Recursion: Inherits FRI approaches. Maturity: Research maturing into implementation. Prover cost profile: Comparable to FRI; the WHIR prover is somewhat heavier. Peak prover memory: As FRI. Off-chain verifier: Sub-millisecond for WHIR in the authors' reported settings. Implementations and maintainers: Reference implementations by the authors; integrations into production hash-based stacks under way. Where it is measured: Authors' comparisons only; measure on your own parameters. Choose it when: Replacing FRI where hash-based proof size or verifier latency is the binding constraint, for teams who will follow the literature.",
      "description": "Two successors to FRI from the same research lineage. STIR reduces query complexity by recursively improving the rate of the tested code; WHIR builds on constrained Reed–Solomon codes to give very fast verification, and doubles as a polynomial commitment.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Concretely smaller proofs than FRI at equal security — roughly half, in the authors' reported comparisons",
        "WHIR verification is reported in hundreds of microseconds where prior hash-based verifiers took milliseconds",
        "Public reference implementations exist and integration into production stacks is under way"
      ],
      "tradeoffs": [
        "Newer analyses and fewer independent implementations than FRI",
        "The most aggressive parameterisation relied on an up-to-capacity conjecture disproved for large fields in late 2025; Johnson-bound parameters are unaffected but the optimistic discount is not available as originally stated",
        "Requires a team able to track fresh cryptanalysis"
      ],
      "bestFit": "Replacing FRI where hash-based proof size or verifier latency is the binding constraint, for teams who will follow the literature.",
      "maintainers": "Arnon, Chiesa, Fenzi and Yogev (2024). Reference implementations by the authors; integrations at several hash-based zkVM teams",
      "maturity": "Research maturing into implementation",
      "license": "n/a (construction)",
      "source": "https://eprint.iacr.org/2024/1586",
      "facts": [
        {
          "table": "Proof system selection matrix",
          "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-stir-whir",
          "name": "STIR / WHIR",
          "setup": "None",
          "size": "Markedly smaller than FRI at equal security",
          "verify": "Impractical directly",
          "pq": "Plausibly",
          "recursion": "Inherits FRI approaches",
          "maturity": "Research maturing into implementation"
        },
        {
          "table": "Prover profile, implementations and benchmarks",
          "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-stir-whir",
          "name": "STIR / WHIR",
          "prover": "Comparable to FRI; the WHIR prover is somewhat heavier",
          "memory": "As FRI",
          "offchain": "Sub-millisecond for WHIR in the authors' reported settings",
          "impls": "Reference implementations by the authors; integrations into production hash-based stacks under way",
          "bench": "Authors' comparisons only; measure on your own parameters"
        }
      ],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "STIR — Reed–Solomon proximity testing with fewer queries",
          "url": "https://eprint.iacr.org/2024/390",
          "kind": "paper"
        },
        {
          "title": "WHIR — Reed–Solomon proximity testing with super-fast verification",
          "url": "https://eprint.iacr.org/2024/1586",
          "kind": "paper"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "GKR-based systems",
      "slug": "gkr",
      "section": {
        "id": "proof-systems",
        "number": "01",
        "title": "Choosing a proof system",
        "url": "https://zkpick.com/proof-systems/"
      },
      "url": "https://zkpick.com/proof-systems/gkr/",
      "markdown": "https://zkpick.com/md/proof-systems/gkr.md",
      "category": "Sumcheck / interactive proofs",
      "summary": "GKR-based systems: Sumcheck / interactive proofs. Setup: None (commitment-dependent). Proof size: Grows with circuit depth. On-chain verification: Wrapper needed. PQ: Commitment-dependent. Recursion: Developing. Maturity: Production via at least one major zkVM. Prover cost profile: Linear-time; commits only to the input layer. Peak prover memory: Low relative to trace size. Off-chain verifier: Grows with circuit depth. Implementations and maintainers: Expander (Polyhedra), Ceno (Scroll), SP1 Hypercube's sumcheck design (Succinct). Where it is measured: ethproofs.org for the zkVMs built on it; Polyhedra's published figures. Choose it when: Wide, shallow, highly parallel workloads — bulk hashing, signature aggregation, inference — and zkVMs using a multilinear arithmetisation.",
      "description": "The GKR protocol proves layered-circuit evaluation using sumcheck, with prover time linear in circuit size. Modern systems combine it with an error-correcting-code commitment, or use GKR to run the lookup argument itself.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Linear-time prover with very low commitment cost — GKR commits only to the input layer, not every intermediate wire",
        "Extremely high throughput on parallel hardware for wide, uniform workloads",
        "Now production-proven via at least one major zkVM"
      ],
      "tradeoffs": [
        "Requires the computation to be expressed as a layered circuit or sumcheck-friendly relation; irregular computation is awkward",
        "Proof size and verifier cost grow with circuit depth — deep circuits are the failure mode",
        "Not EVM-cheap; a wrapper is still needed for settlement",
        "Fewer mature general-purpose frontends"
      ],
      "bestFit": "Wide, shallow, highly parallel workloads — bulk hashing, signature aggregation, inference — and zkVMs using a multilinear arithmetisation.",
      "maintainers": "Goldwasser, Kalai and Rothblum (2008); linear-time prover by Xie et al. (Libra, 2019). Implementations: Expander (Polyhedra), Ceno (Scroll), sumcheck-based zkVM designs at Succinct",
      "maturity": "Production as of 2026",
      "license": "n/a (construction)",
      "source": "https://eprint.iacr.org/2019/317",
      "facts": [
        {
          "table": "Proof system selection matrix",
          "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-gkr-sumcheck-systems",
          "name": "GKR / sumcheck systems",
          "setup": "None (commitment-dependent)",
          "size": "Grows with circuit depth",
          "verify": "Wrapper needed",
          "pq": "Commitment-dependent",
          "recursion": "Developing",
          "maturity": "Production via at least one major zkVM"
        },
        {
          "table": "Prover profile, implementations and benchmarks",
          "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-gkr-sumcheck-systems",
          "name": "GKR / sumcheck systems",
          "prover": "Linear-time; commits only to the input layer",
          "memory": "Low relative to trace size",
          "offchain": "Grows with circuit depth",
          "impls": "Expander (Polyhedra), Ceno (Scroll), SP1 Hypercube's sumcheck design (Succinct)",
          "bench": "ethproofs.org for the zkVMs built on it; Polyhedra's published figures"
        }
      ],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "Libra — succinct zero-knowledge proofs with optimal prover computation (GKR)",
          "url": "https://eprint.iacr.org/2019/317",
          "kind": "paper"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Spartan",
      "slug": "spartan",
      "section": {
        "id": "proof-systems",
        "number": "01",
        "title": "Choosing a proof system",
        "url": "https://zkpick.com/proof-systems/"
      },
      "url": "https://zkpick.com/proof-systems/spartan/",
      "markdown": "https://zkpick.com/md/proof-systems/spartan.md",
      "category": "Transparent SNARK for R1CS",
      "summary": "Spartan: Transparent SNARK for R1CS. Setup: None (commitment-dependent). Proof size: Depends on commitment. On-chain verification: Not a settlement candidate alone. PQ: Commitment-dependent. Recursion: Used inside larger systems. Maturity: Established construction, widely built upon. Prover cost profile: Sumcheck over sparse R1CS; no FFT; linear in non-zero constraint entries. Peak prover memory: Low and streaming-friendly. Off-chain verifier: Sublinear after preprocessing; commitment-dependent. Implementations and maintainers: Spartan (Microsoft Research), inside Jolt (a16z crypto) and Nexus. Where it is measured: Only inside zkVM benchmarks. Choose it when: An intermediate proof layer, or the theoretical core of a zkVM — particularly when you want to change commitment schemes without changing arithmetisation.",
      "description": "A transparent SNARK for R1CS built on sumcheck and a multilinear commitment, with sublinear verification after preprocessing and no FFTs. Its distinguishing property is that the commitment scheme is swappable.",
      "notes": [],
      "sections": [],
      "strengths": [
        "No trusted setup, and the commitment is swappable — so post-quantum posture becomes a separate, independent choice",
        "No FFT in the prover; costs are linear in the number of constraint entries",
        "The sumcheck structure has become the foundation for much newer work"
      ],
      "tradeoffs": [
        "Proof size and verifier cost are worse than pairing-based SNARKs; not an EVM settlement candidate alone",
        "Concrete performance depends almost entirely on the chosen commitment, so 'Spartan is fast' is not a meaningful statement unqualified",
        "The reference implementation is a research artefact rather than a maintained product"
      ],
      "bestFit": "An intermediate proof layer, or the theoretical core of a zkVM — particularly when you want to change commitment schemes without changing arithmetisation.",
      "maintainers": "Srinath Setty (Microsoft Research, 2019). Implementations: Spartan (Microsoft Research), inside Jolt (a16z crypto) and Nexus",
      "maturity": "Established construction, heavily built upon",
      "license": "n/a (construction)",
      "source": "https://eprint.iacr.org/2019/550",
      "facts": [
        {
          "table": "Proof system selection matrix",
          "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-spartan",
          "name": "Spartan",
          "setup": "None (commitment-dependent)",
          "size": "Depends on commitment",
          "verify": "Not a settlement candidate alone",
          "pq": "Commitment-dependent",
          "recursion": "Used inside larger systems",
          "maturity": "Established construction, widely built upon"
        },
        {
          "table": "Prover profile, implementations and benchmarks",
          "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-spartan",
          "name": "Spartan",
          "prover": "Sumcheck over sparse R1CS; no FFT; linear in non-zero constraint entries",
          "memory": "Low and streaming-friendly",
          "offchain": "Sublinear after preprocessing; commitment-dependent",
          "impls": "Spartan (Microsoft Research), inside Jolt (a16z crypto) and Nexus",
          "bench": "Only inside zkVM benchmarks"
        }
      ],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "Spartan — efficient and general-purpose zkSNARKs without trusted setup",
          "url": "https://eprint.iacr.org/2019/550",
          "kind": "paper"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Bulletproofs",
      "slug": "bulletproofs",
      "section": {
        "id": "proof-systems",
        "number": "01",
        "title": "Choosing a proof system",
        "url": "https://zkpick.com/proof-systems/"
      },
      "url": "https://zkpick.com/proof-systems/bulletproofs/",
      "markdown": "https://zkpick.com/md/proof-systems/bulletproofs.md",
      "category": "Transparent discrete-log argument",
      "summary": "Bulletproofs: Transparent discrete-log argument. Setup: None. Proof size: Logarithmic; small for ranges. On-chain verification: Linear in circuit size — not succinct. PQ: No. Recursion: Poor. Maturity: Production for range proofs since 2018. Prover cost profile: Linear MSMs; slow for general circuits. Peak prover memory: Low. Off-chain verifier: Linear in circuit size; batchable. Implementations and maintainers: dalek bulletproofs (Rust), Monero, Bulletproofs+ in several wallets. Where it is measured: Range-proof figures in Monero and dalek benchmarks. Choose it when: Range proofs and small confidential-transaction statements verified by full nodes.",
      "description": "Logarithmic-size zero-knowledge arguments from the inner-product argument, with no trusted setup. Best known for range proofs in confidential transactions; general circuits are supported but not the strength.",
      "notes": [],
      "sections": [],
      "strengths": [
        "No trusted setup and only the discrete-log assumption",
        "Very small proofs for range statements, with cheap aggregation of many range proofs",
        "Batch verification gives real speedups across many proofs",
        "Long production track record in confidential-transaction systems"
      ],
      "tradeoffs": [
        "Verification is linear in circuit size — no succinct verifier, so unsuitable for on-chain verification of large statements",
        "Not post-quantum",
        "General-circuit performance is poor relative to modern SNARKs; the sweet spot is narrow"
      ],
      "bestFit": "Range proofs and small confidential-transaction statements verified by full nodes.",
      "maintainers": "Bünz, Bootle, Boneh, Poelstra, Wuille and Maxwell (Stanford and Blockstream, 2017). Implementations: dalek bulletproofs (Rust), Monero's Bulletproofs+, several confidential-asset wallets",
      "maturity": "Production since 2018 in its niche",
      "license": "n/a (construction)",
      "source": "https://eprint.iacr.org/2017/1066",
      "facts": [
        {
          "table": "Proof system selection matrix",
          "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-bulletproofs",
          "name": "Bulletproofs",
          "setup": "None",
          "size": "Logarithmic; small for ranges",
          "verify": "Linear in circuit size — not succinct",
          "pq": "No",
          "recursion": "Poor",
          "maturity": "Production for range proofs since 2018"
        },
        {
          "table": "Prover profile, implementations and benchmarks",
          "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-bulletproofs",
          "name": "Bulletproofs",
          "prover": "Linear MSMs; slow for general circuits",
          "memory": "Low",
          "offchain": "Linear in circuit size; batchable",
          "impls": "dalek bulletproofs (Rust), Monero, Bulletproofs+ in several wallets",
          "bench": "Range-proof figures in Monero and dalek benchmarks"
        }
      ],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "Bulletproofs — short proofs for confidential transactions and more",
          "url": "https://eprint.iacr.org/2017/1066",
          "kind": "paper"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Lookup arguments: Plookup, LogUp, cq, Lasso/Shout/Twist",
      "slug": "lookup-arguments",
      "section": {
        "id": "proof-systems",
        "number": "01",
        "title": "Choosing a proof system",
        "url": "https://zkpick.com/proof-systems/"
      },
      "url": "https://zkpick.com/proof-systems/lookup-arguments/",
      "markdown": "https://zkpick.com/md/proof-systems/lookup-arguments.md",
      "category": "Cross-cutting — often the real cost driver",
      "summary": "Lookup arguments: Plookup, LogUp, cq, Lasso/Shout/Twist: Cross-cutting — often the real cost driver. Lookup arguments prove that values appear in a table, and are how systems express operations that are expensive as raw arithmetic. Maturity: Plookup and LogUp production; structure-exploiting variants research-stage. Maintained by: Plookup: Gabizon and Williamson (Aztec). LogUp: Haböck (Polygon). cq: Eagen, Fiore and Gabizon. Lasso, Twist and Shout: Setty, Thaler and collaborators (a16z crypto). Choose it when: Evaluate the lookup argument explicitly whenever range checks, bitwise operations or instruction decoding dominate your constraint count.",
      "description": "Lookup arguments prove that values appear in a table, and are how systems express operations that are expensive as raw arithmetic. Plookup is the original and ubiquitous; LogUp uses logarithmic derivatives and is substantially cheaper for wide multi-column lookups; cq makes prover cost independent of table size after preprocessing; Lasso and its successors exploit table structure so huge tables need never be materialised.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Frequently determines prover time more than the choice of headline proof system does",
        "LogUp and its GKR variant dominate modern small-field designs",
        "Structure-exploiting arguments make instruction-set-sized tables tractable at all"
      ],
      "tradeoffs": [
        "Plookup scales poorly with large tables and multi-column lookups",
        "cq requires a KZG SRS and amortised preprocessing — poor fit for changing tables",
        "Structure-exploiting schemes are tied to sumcheck arithmetisations, need decomposable tables to deliver their headline benefits, and their reference implementation is self-declared alpha",
        "Multiplicity handling is a known correctness trap: an unconstrained multiplicity column silently breaks soundness"
      ],
      "bestFit": "Evaluate the lookup argument explicitly whenever range checks, bitwise operations or instruction decoding dominate your constraint count.",
      "maintainers": "Plookup: Gabizon and Williamson (Aztec). LogUp: Haböck (Polygon). cq: Eagen, Fiore and Gabizon. Lasso, Twist and Shout: Setty, Thaler and collaborators (a16z crypto)",
      "maturity": "Plookup and LogUp production; structure-exploiting variants research-stage",
      "license": "n/a (constructions)",
      "source": "https://eprint.iacr.org/2022/1530",
      "facts": [],
      "relatedFailureModes": [
        {
          "name": "Letting the lookup argument be an afterthought",
          "url": "https://zkpick.com/proof-systems/failure-modes/letting-the-lookup-argument-be-an-afterthought/"
        }
      ],
      "sources": [
        {
          "title": "Plookup — a simplified polynomial protocol for lookup tables",
          "url": "https://eprint.iacr.org/2020/315",
          "kind": "paper"
        },
        {
          "title": "Multivariate lookups based on logarithmic derivatives (LogUp)",
          "url": "https://eprint.iacr.org/2022/1530",
          "kind": "paper"
        },
        {
          "title": "cq — cached quotients for fast lookups",
          "url": "https://eprint.iacr.org/2022/1763",
          "kind": "paper"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Circom",
      "slug": "circom",
      "section": {
        "id": "frameworks",
        "number": "02",
        "title": "Choosing a framework",
        "url": "https://zkpick.com/frameworks/"
      },
      "url": "https://zkpick.com/frameworks/circom/",
      "markdown": "https://zkpick.com/md/frameworks/circom.md",
      "category": "Circuit DSL (R1CS)",
      "summary": "Circom: Circuit DSL (R1CS). Kind: Circuit DSL. Arithmetisation / backend: R1CS → Groth16 / PLONK. Setup: Yes (per-circuit for Groth16). Maintained by: iden3. Licence: GPL-3.0. Status: Production-mature. Choose it when: Fixed, small-to-medium, high-volume statements where the verifier must be cheap and the circuit will be audited hard: membership proofs, identity and anonymity sets, signature verification.",
      "description": "A low-level DSL that compiles templates into R1CS, typically proved with Groth16 or PLONK. The developer writes constraints explicitly and assigns witness values separately — the source of both its efficiency and its characteristic bug class.",
      "notes": [],
      "sections": [],
      "strengths": [
        "The largest deployed base of any ZK circuit DSL, and by far the deepest pool of engineers and auditors",
        "The best security tooling coverage of any ZK language — analysers and fuzzers target it first",
        "Very small, cheap on-chain verifiers when paired with Groth16"
      ],
      "tradeoffs": [
        "Highest underconstrained-bug risk of the mainstream options; the assign-versus-constrain distinction is a documented footgun",
        "R1CS only — no custom gates or lookups, so hashing-heavy circuits are expensive relative to PLONKish and AIR systems",
        "Groth16 means a per-circuit trusted setup: changing the circuit means a new ceremony",
        "Licensing differs by layer and is routinely conflated — the compiler and snarkjs are GPL-3.0 while circomlib is LGPL-3.0; get legal review for commercial products"
      ],
      "bestFit": "Fixed, small-to-medium, high-volume statements where the verifier must be cheap and the circuit will be audited hard: membership proofs, identity and anonymity sets, signature verification.",
      "maintainers": "iden3",
      "maturity": "Production-mature",
      "license": "GPL-3.0",
      "source": "https://github.com/iden3/circom",
      "facts": [
        {
          "table": "Framework selection matrix",
          "url": "https://zkpick.com/frameworks/#frameworks-matrix-circom",
          "name": "Circom",
          "kind": "Circuit DSL",
          "arith": "R1CS → Groth16 / PLONK",
          "setup": "Yes (per-circuit for Groth16)",
          "by": "iden3",
          "license": "GPL-3.0",
          "status": "Production-mature"
        }
      ],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "Circom — circuit compiler and language",
          "url": "https://github.com/iden3/circom",
          "kind": "project"
        },
        {
          "title": "Circomspect — static analyser for Circom",
          "url": "https://github.com/trailofbits/circomspect",
          "kind": "tool"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Noir",
      "slug": "noir",
      "section": {
        "id": "frameworks",
        "number": "02",
        "title": "Choosing a framework",
        "url": "https://zkpick.com/frameworks/"
      },
      "url": "https://zkpick.com/frameworks/noir/",
      "markdown": "https://zkpick.com/md/frameworks/noir.md",
      "category": "Circuit DSL (backend-agnostic)",
      "summary": "Noir: Circuit DSL (backend-agnostic). Kind: Circuit DSL. Arithmetisation / backend: ACIR → Barretenberg (UltraHonk). Setup: Yes (universal). Maintained by: Aztec. Licence: Apache-2.0 / MIT. Status: Late beta, pre-1.0 (1.0.0-beta series through 2026). Choose it when: New application circuits where developer velocity and client-side proving matter, and teams uncomfortable with manual constraint discipline.",
      "description": "A Rust-like DSL that compiles to ACIR, an intermediate representation intended to be consumed by several proving backends. The compiler emits constraints for you, removing the manual assign-versus-constrain bug class. Browser and WASM proving are first-class targets.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Substantially better ergonomics than lower-level DSLs, and the compiler emits constraints rather than the developer",
        "Backend-agnostic by design, keeping a future migration architecturally open",
        "Client-side and browser proving are supported paths, not afterthoughts"
      ],
      "tradeoffs": [
        "Still formally pre-1.0 after several years of beta, with routine breaking changes between betas — a real cost for long-lived audited code",
        "In practice one backend — Barretenberg — is the maintained one, so diligence it as carefully as the language itself; treat backend-agnosticism as architectural rather than operational unless you validate an alternative yourself",
        "Smaller auditor pool and thinner static-analysis tooling than Circom"
      ],
      "bestFit": "New application circuits where developer velocity and client-side proving matter, and teams uncomfortable with manual constraint discipline.",
      "maintainers": "Aztec",
      "maturity": "Late beta; used in production by some teams",
      "license": "Apache-2.0 / MIT",
      "source": "https://github.com/noir-lang/noir",
      "facts": [
        {
          "table": "Framework selection matrix",
          "url": "https://zkpick.com/frameworks/#frameworks-matrix-noir",
          "name": "Noir",
          "kind": "Circuit DSL",
          "arith": "ACIR → Barretenberg (UltraHonk)",
          "setup": "Yes (universal)",
          "by": "Aztec",
          "license": "Apache-2.0 / MIT",
          "status": "Late beta, pre-1.0 (1.0.0-beta series through 2026)"
        }
      ],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "Noir — backend-agnostic circuit DSL",
          "url": "https://github.com/noir-lang/noir",
          "kind": "project"
        },
        {
          "title": "Barretenberg — the maintained Noir proving backend",
          "url": "https://github.com/AztecProtocol/aztec-packages/tree/master/barretenberg",
          "kind": "project"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Halo2",
      "slug": "halo2",
      "section": {
        "id": "frameworks",
        "number": "02",
        "title": "Choosing a framework",
        "url": "https://zkpick.com/frameworks/"
      },
      "url": "https://zkpick.com/frameworks/halo2/",
      "markdown": "https://zkpick.com/md/frameworks/halo2.md",
      "category": "Rust eDSL (PLONKish)",
      "summary": "Halo2: Rust eDSL (PLONKish). As Halo2 (upstream) — Kind: Rust eDSL. Arithmetisation / backend: PLONKish + IPA. Setup: None. Maintained by: Electric Coin Company (Zcash). Licence: MIT / Apache-2.0. Status: Production in its home ecosystem. As Halo2 (KZG fork) — Kind: Rust eDSL. Arithmetisation / backend: PLONKish + KZG. Setup: Yes (universal). Maintained by: Ethereum Foundation PSE. Licence: MIT / Apache-2.0. Status: Maintenance mode. Choose it when: Teams needing trusted-setup-free proving with a non-EVM or off-chain verifier, who have cryptography-capable engineers.",
      "description": "PLONKish arithmetisation with custom gates, lookup arguments and explicit region and column layout under developer control. The upstream implementation uses an inner-product argument and needs no trusted setup; a widely used fork swaps in KZG for constant-size, cheaply verifiable proofs.",
      "notes": [],
      "sections": [],
      "strengths": [
        "The upstream IPA instantiation needs no trusted setup, and is deployed in a long-running production shielded protocol",
        "Custom gates and lookups allow far more efficient hashing and range-check circuits than R1CS",
        "Permissive dual licence"
      ],
      "tradeoffs": [
        "The steepest learning curve of any mainstream option — correct circuits require manual reasoning about regions, rotations and selectors",
        "Very easy to underconstrain, in library gadgets as well as user circuits: a query-collision bug affected edge-case circuits across multiple forks, and in 2026 a counterfeiting bug in the ECC gadget of the upstream library prompted an emergency response in its flagship deployment — verify the current status of any Halo2 deployment you are citing as evidence of maturity",
        "IPA proofs are logarithmic in size but the verifier's work is linear in circuit size, so direct L1 verification is impractical without a wrapper",
        "The ecosystem is fragmented across forks with divergent maintenance postures — choose deliberately"
      ],
      "bestFit": "Teams needing trusted-setup-free proving with a non-EVM or off-chain verifier, who have cryptography-capable engineers.",
      "maintainers": "Electric Coin Company (upstream); Ethereum Foundation PSE (KZG fork, maintenance mode); Axiom (halo2-lib)",
      "maturity": "Long production history; verify current status",
      "license": "MIT / Apache-2.0",
      "source": "https://github.com/zcash/halo2",
      "facts": [
        {
          "table": "Framework selection matrix",
          "url": "https://zkpick.com/frameworks/#frameworks-matrix-halo2-upstream",
          "name": "Halo2 (upstream)",
          "kind": "Rust eDSL",
          "arith": "PLONKish + IPA",
          "setup": "None",
          "by": "Electric Coin Company (Zcash)",
          "license": "MIT / Apache-2.0",
          "status": "Production in its home ecosystem"
        },
        {
          "table": "Framework selection matrix",
          "url": "https://zkpick.com/frameworks/#frameworks-matrix-halo2-kzg-fork",
          "name": "Halo2 (KZG fork)",
          "kind": "Rust eDSL",
          "arith": "PLONKish + KZG",
          "setup": "Yes (universal)",
          "by": "Ethereum Foundation PSE",
          "license": "MIT / Apache-2.0",
          "status": "Maintenance mode"
        }
      ],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "Halo2 — upstream implementation (IPA, no trusted setup)",
          "url": "https://github.com/zcash/halo2",
          "kind": "project"
        },
        {
          "title": "Halo2 — KZG fork",
          "url": "https://github.com/privacy-ethereum/halo2",
          "kind": "project"
        },
        {
          "title": "halo2-lib — gadget library for Halo2 circuits",
          "url": "https://github.com/axiom-crypto/halo2-lib",
          "kind": "project"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "gnark",
      "slug": "gnark",
      "section": {
        "id": "frameworks",
        "number": "02",
        "title": "Choosing a framework",
        "url": "https://zkpick.com/frameworks/"
      },
      "url": "https://zkpick.com/frameworks/gnark/",
      "markdown": "https://zkpick.com/md/frameworks/gnark.md",
      "category": "Go eDSL",
      "summary": "gnark: Go eDSL. Kind: Go eDSL. Arithmetisation / backend: R1CS / PLONK, six curves. Setup: Yes (scheme-dependent). Maintained by: Consensys (Linea). Licence: Apache-2.0. Status: Production-mature. Choose it when: Go-based backends, proof aggregation and recursion layers, and wrapper circuits for STARK systems.",
      "description": "A Go SNARK library offering a high-level circuit API over Groth16 and PLONK, instantiable on six curves, with an extensive standard library and in-circuit recursive verifiers.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Two proving schemes and six curves behind one circuit API — genuinely the most swappable backend situation among circuit libraries",
        "Strong, documented recursion support including in-circuit verifiers",
        "The obvious choice if your existing backend is Go",
        "Permissive licence and a documented audit trail"
      ],
      "tradeoffs": [
        "Go sits outside the mainstream of ZK research code, so new proof systems land there later",
        "Still a constraint-writing library: the underconstrained bug class applies, and static analysis is much thinner than for Circom",
        "Corporate stewardship means roadmap priorities follow the sponsor's own chain"
      ],
      "bestFit": "Go-based backends, proof aggregation and recursion layers, and wrapper circuits for STARK systems.",
      "maintainers": "Consensys (Linea)",
      "maturity": "Production-mature",
      "license": "Apache-2.0",
      "source": "https://github.com/Consensys/gnark",
      "facts": [
        {
          "table": "Framework selection matrix",
          "url": "https://zkpick.com/frameworks/#frameworks-matrix-gnark",
          "name": "gnark",
          "kind": "Go eDSL",
          "arith": "R1CS / PLONK, six curves",
          "setup": "Yes (scheme-dependent)",
          "by": "Consensys (Linea)",
          "license": "Apache-2.0",
          "status": "Production-mature"
        }
      ],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "gnark — Go zk-SNARK library",
          "url": "https://github.com/Consensys/gnark",
          "kind": "project"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Plonky3",
      "slug": "plonky3",
      "section": {
        "id": "frameworks",
        "number": "02",
        "title": "Choosing a framework",
        "url": "https://zkpick.com/frameworks/"
      },
      "url": "https://zkpick.com/frameworks/plonky3/",
      "markdown": "https://zkpick.com/md/frameworks/plonky3.md",
      "category": "Proof-system toolkit",
      "summary": "Plonky3: Proof-system toolkit. Kind: Proof-system toolkit. Arithmetisation / backend: AIR / FRI over small fields. Setup: None. Maintained by: Plonky3 org (Polygon Zero lineage). Licence: MIT / Apache-2.0. Status: Widely used downstream; pre-1.0 API. Choose it when: Teams building a zkVM, a custom AIR-based prover, or a domain-specific proving engine.",
      "description": "A toolkit of polynomial IOP primitives — fields, FRI, commitment schemes, DFTs — for building STARK provers over small fields. Not a DSL: you write AIRs against it or build a zkVM on it. It is the shared substrate beneath a large fraction of the modern zkVM landscape.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Improvements propagate broadly because so much of the zkVM landscape sits on it",
        "Field-agnostic design lets the same proof system be retargeted across field choices",
        "Extremely active development; permissive dual licence"
      ],
      "tradeoffs": [
        "Not usable directly by application developers — designing an AIR is a specialist skill",
        "No stable 1.0 API; component crates version independently and downstream projects commonly pin forks",
        "Security depends on parameters you choose; a Plonky3 dependency by itself implies nothing about soundness level"
      ],
      "bestFit": "Teams building a zkVM, a custom AIR-based prover, or a domain-specific proving engine.",
      "maintainers": "Plonky3 organisation (Polygon Zero lineage), with contributors from the zkVM teams built on it",
      "maturity": "Widely used downstream; pre-1.0 API",
      "license": "MIT / Apache-2.0",
      "source": "https://github.com/Plonky3/Plonky3",
      "facts": [
        {
          "table": "Framework selection matrix",
          "url": "https://zkpick.com/frameworks/#frameworks-matrix-plonky3",
          "name": "Plonky3",
          "kind": "Proof-system toolkit",
          "arith": "AIR / FRI over small fields",
          "setup": "None",
          "by": "Plonky3 org (Polygon Zero lineage)",
          "license": "MIT / Apache-2.0",
          "status": "Widely used downstream; pre-1.0 API"
        }
      ],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "Plonky3 — polynomial IOP toolkit",
          "url": "https://github.com/Plonky3/Plonky3",
          "kind": "project"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Cairo and the Stwo prover",
      "slug": "cairo-stwo",
      "section": {
        "id": "frameworks",
        "number": "02",
        "title": "Choosing a framework",
        "url": "https://zkpick.com/frameworks/"
      },
      "url": "https://zkpick.com/frameworks/cairo-stwo/",
      "markdown": "https://zkpick.com/md/frameworks/cairo-stwo.md",
      "category": "Language + VM + prover",
      "summary": "Cairo and the Stwo prover: Language + VM + prover. Kind: Language + VM + prover. Arithmetisation / backend: Circle STARK (Mersenne-31). Setup: None. Maintained by: StarkWare. Licence: Apache-2.0. Status: Production at scale. Choose it when: Applications native to its ecosystem, and any workload wanting a battle-tested, setup-free STARK stack with mature native recursion.",
      "description": "A language for provable programs executed by its own VM and proved by a Circle STARK prover over a small field. Verification is available both natively and as a verifier written in Cairo itself and run on the Cairo VM, which is what makes recursion native.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Among the longest-running production ZK stacks, proving blocks with settlement on Ethereum L1",
        "No trusted setup",
        "Recursive proving is native and well-exercised — the verifier runs on the VM it verifies",
        "Prover fully open-sourced under a permissive licence"
      ],
      "tradeoffs": [
        "Strong gravitational pull toward its own ecosystem; general-purpose use is possible but not the main path",
        "Circle STARK proofs are large, so direct per-transaction L1 verification is impractical — the design intent is per-block aggregation",
        "A bespoke language with its own memory model, so no reuse of an existing toolchain ecosystem"
      ],
      "bestFit": "Applications native to its ecosystem, and any workload wanting a battle-tested, setup-free STARK stack with mature native recursion.",
      "maintainers": "StarkWare",
      "maturity": "Production at scale",
      "license": "Apache-2.0",
      "source": "https://github.com/starkware-libs/cairo",
      "facts": [
        {
          "table": "Framework selection matrix",
          "url": "https://zkpick.com/frameworks/#frameworks-matrix-cairo-stwo",
          "name": "Cairo + Stwo",
          "kind": "Language + VM + prover",
          "arith": "Circle STARK (Mersenne-31)",
          "setup": "None",
          "by": "StarkWare",
          "license": "Apache-2.0",
          "status": "Production at scale"
        }
      ],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "Cairo — language and compiler",
          "url": "https://github.com/starkware-libs/cairo",
          "kind": "project"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "SP1",
      "slug": "sp1",
      "section": {
        "id": "frameworks",
        "number": "02",
        "title": "Choosing a framework",
        "url": "https://zkpick.com/frameworks/"
      },
      "url": "https://zkpick.com/frameworks/sp1/",
      "markdown": "https://zkpick.com/md/frameworks/sp1.md",
      "category": "zkVM (RISC-V)",
      "summary": "SP1: zkVM (RISC-V). Kind: zkVM (RISC-V). Arithmetisation / backend: Multilinear / sumcheck + wrapper. Setup: Wrapper only. Maintained by: Succinct. Licence: MIT / Apache-2.0. Status: Production; deepest assurance evidence. Choose it when: Proving large existing Rust codebases — state transitions, consensus and EVM verification, bridges — where on-chain cost matters and published assurance evidence is a selection criterion.",
      "description": "A RISC-V zkVM proving execution of programs compiled from Rust. The current generation uses a multilinear proof system with sumcheck-based arguments; final proofs are wrapped in Groth16 or PLONK for on-chain verification.",
      "notes": [],
      "sections": [],
      "strengths": [
        "One of the two most substantial public formal-verification efforts among zkVMs, with core chip constraints verified against the official ISA specification",
        "Documented, concrete on-chain proof sizes and gas costs for both wrapper options",
        "Mainnet-deployed, with published security analysis and disclosed findings"
      ],
      "tradeoffs": [
        "Formal verification is scoped, not total: a specification-conformance bug was later found by conformance tests outside the verification effort's scope. Treat 'formally verified' as bounded by its stated hypotheses",
        "Unwrapped proofs are large; reaching on-chain size requires recursion plus a wrapper",
        "The Groth16 wrapper inherits a trusted setup — see §04"
      ],
      "bestFit": "Proving large existing Rust codebases — state transitions, consensus and EVM verification, bridges — where on-chain cost matters and published assurance evidence is a selection criterion.",
      "maintainers": "Succinct",
      "maturity": "Production, mainnet-deployed",
      "license": "MIT / Apache-2.0",
      "source": "https://github.com/succinctlabs/sp1",
      "facts": [
        {
          "table": "Framework selection matrix",
          "url": "https://zkpick.com/frameworks/#frameworks-matrix-sp1",
          "name": "SP1",
          "kind": "zkVM (RISC-V)",
          "arith": "Multilinear / sumcheck + wrapper",
          "setup": "Wrapper only",
          "by": "Succinct",
          "license": "MIT / Apache-2.0",
          "status": "Production; deepest assurance evidence"
        }
      ],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "SP1 — RISC-V zkVM",
          "url": "https://github.com/succinctlabs/sp1",
          "kind": "project"
        },
        {
          "title": "SP1 on-chain verification — Solidity verifier and wrapper options",
          "url": "https://docs.succinct.xyz/docs/sp1/verification/solidity-sdk",
          "kind": "documentation"
        },
        {
          "title": "sp1-contracts — deployed verifier gateways and addresses per chain",
          "url": "https://github.com/succinctlabs/sp1-contracts",
          "kind": "project"
        },
        {
          "title": "SP1 security model — wrapper trusted setup provenance",
          "url": "https://docs.succinct.xyz/docs/sp1/security/security-model",
          "kind": "documentation"
        },
        {
          "title": "On formal verification and a bug in SP1 Hypercube (EF zkEVM)",
          "url": "https://zkevm.ethereum.foundation/blog/sp1-fv",
          "kind": "analysis"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "RISC Zero (R0VM)",
      "slug": "risc-zero",
      "section": {
        "id": "frameworks",
        "number": "02",
        "title": "Choosing a framework",
        "url": "https://zkpick.com/frameworks/"
      },
      "url": "https://zkpick.com/frameworks/risc-zero/",
      "markdown": "https://zkpick.com/md/frameworks/risc-zero.md",
      "category": "zkVM (RISC-V)",
      "summary": "RISC Zero (R0VM): zkVM (RISC-V). Kind: zkVM (RISC-V). Arithmetisation / backend: FRI/STARK + Groth16 wrapper. Setup: Wrapper only. Maintained by: RISC Zero. Licence: Apache-2.0. Status: Production; longest track record; 3.x line in 2026. Choose it when: Teams wanting the most operationally complete RISC-V zkVM today, including off-the-shelf outsourced proving, and who value documentation and stability over peak prover speed.",
      "description": "One of the earliest general-purpose RISC-V zkVMs, based on FRI/STARK with a Groth16 wrapper for on-chain verification. Ships an unusually complete operational surface: local proving, hosted remote proving, and a live decentralised proof market.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Longest continuous production history among RISC-V zkVMs, with a large and mature documentation surface",
        "An end-to-end operational path, including outsourced proving, rather than a prover alone",
        "Runs adversarial analysis tooling as part of its own workflow"
      ],
      "tradeoffs": [
        "Historically slower than the fastest competitor on comparable benchmarks, partly a deliberate security-parameter tradeoff rather than an implementation gap",
        "Major versions turn over quickly — R0VM 2.0 in 2025, a 3.x line in 2026 — and each changes the circuit and the verifier, so pin a release and treat every major upgrade as a re-audit trigger",
        "The Groth16 wrapper inherits a trusted setup"
      ],
      "bestFit": "Teams wanting the most operationally complete RISC-V zkVM today, including off-the-shelf outsourced proving, and who value documentation and stability over peak prover speed.",
      "maintainers": "RISC Zero",
      "maturity": "Production; longest track record",
      "license": "Apache-2.0",
      "source": "https://github.com/risc0/risc0",
      "facts": [
        {
          "table": "Framework selection matrix",
          "url": "https://zkpick.com/frameworks/#frameworks-matrix-risc-zero-r0vm",
          "name": "RISC Zero R0VM",
          "kind": "zkVM (RISC-V)",
          "arith": "FRI/STARK + Groth16 wrapper",
          "setup": "Wrapper only",
          "by": "RISC Zero",
          "license": "Apache-2.0",
          "status": "Production; longest track record; 3.x line in 2026"
        }
      ],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "SP1 — RISC-V zkVM",
          "url": "https://github.com/succinctlabs/sp1",
          "kind": "project"
        },
        {
          "title": "RISC Zero R0VM — zkVM",
          "url": "https://github.com/risc0/risc0",
          "kind": "project"
        },
        {
          "title": "RISC Zero trusted setup ceremony rationale",
          "url": "https://dev.risczero.com/api/trusted-setup-ceremony",
          "kind": "documentation"
        },
        {
          "title": "RISC Zero remote proving — hosted proving documentation",
          "url": "https://dev.risczero.com/api/generating-proofs/remote-proving",
          "kind": "documentation"
        },
        {
          "title": "ZKsync Airbender — RISC-V prover for ZKsync OS, with benchmark harness",
          "url": "https://github.com/matter-labs/zksync-airbender",
          "kind": "project"
        },
        {
          "title": "Zisk — Polygon's RISC-V zkVM",
          "url": "https://github.com/0xPolygonHermez/zisk",
          "kind": "project"
        },
        {
          "title": "Pico — Brevis's modular RISC-V zkVM",
          "url": "https://github.com/brevis-network/pico",
          "kind": "project"
        },
        {
          "title": "Nexus zkVM — source-available RISC-V zkVM",
          "url": "https://github.com/nexus-xyz/nexus-zkvm",
          "kind": "project"
        },
        {
          "title": "RISC-V architectural certification tests",
          "url": "https://github.com/riscv-non-isa/riscv-arch-test",
          "kind": "test suite"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "OpenVM",
      "slug": "openvm",
      "section": {
        "id": "frameworks",
        "number": "02",
        "title": "Choosing a framework",
        "url": "https://zkpick.com/frameworks/"
      },
      "url": "https://zkpick.com/frameworks/openvm/",
      "markdown": "https://zkpick.com/md/frameworks/openvm.md",
      "category": "Modular zkVM framework",
      "summary": "OpenVM: Modular zkVM framework. Kind: Modular zkVM framework. Arithmetisation / backend: Plonky3 AIR, chip extensions. Setup: Wrapper only. Maintained by: Axiom. Licence: MIT / Apache-2.0. Status: Production-recommended; externally audited. Choose it when: Teams needing custom instructions, domain-specific precompiles, or an application-specific VM, who want to build on an audited modular base rather than fork a monolithic zkVM.",
      "description": "A zkVM framework with a no-CPU architecture: rather than one central processing chip, functionality is composed of independent chips and extensions, so custom instructions and precompiles can be added without forking the core.",
      "notes": [],
      "sections": [],
      "strengths": [
        "The strongest extensibility story — custom chips and ISA extensions are a first-class mechanism, not a fork",
        "Explicit production recommendation backed by audit evidence, including an external audit and a public audit competition, alongside its own formal-verification work over the RISC-V instruction set",
        "Built on a widely shared proving substrate"
      ],
      "tradeoffs": [
        "Modularity increases the configuration surface: your deployed security depends on which extensions you enable, so an audit of upstream does not fully cover your instantiation",
        "A critical soundness bug in an optimised pairing routine was assigned a CVE and fixed upstream — evidence the extension surface is where risk concentrates",
        "Younger than the two longest-running RISC-V zkVMs"
      ],
      "bestFit": "Teams needing custom instructions, domain-specific precompiles, or an application-specific VM, who want to build on an audited modular base rather than fork a monolithic zkVM.",
      "maintainers": "Axiom",
      "maturity": "Production-recommended; externally audited",
      "license": "MIT / Apache-2.0",
      "source": "https://github.com/openvm-org/openvm",
      "facts": [
        {
          "table": "Framework selection matrix",
          "url": "https://zkpick.com/frameworks/#frameworks-matrix-openvm",
          "name": "OpenVM",
          "kind": "Modular zkVM framework",
          "arith": "Plonky3 AIR, chip extensions",
          "setup": "Wrapper only",
          "by": "Axiom",
          "license": "MIT / Apache-2.0",
          "status": "Production-recommended; externally audited"
        }
      ],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "OpenVM — modular zkVM framework",
          "url": "https://github.com/openvm-org/openvm",
          "kind": "project"
        },
        {
          "title": "Missing subfield membership check in OpenVM pairing — CVE-2026-46669",
          "url": "https://blog.zksecurity.xyz/posts/openvm-bugs/",
          "kind": "disclosure"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "ZKsync Airbender",
      "slug": "airbender",
      "section": {
        "id": "frameworks",
        "number": "02",
        "title": "Choosing a framework",
        "url": "https://zkpick.com/frameworks/"
      },
      "url": "https://zkpick.com/frameworks/airbender/",
      "markdown": "https://zkpick.com/md/frameworks/airbender.md",
      "category": "zkVM (RISC-V)",
      "summary": "ZKsync Airbender: zkVM (RISC-V). Kind: zkVM (RISC-V). Arithmetisation / backend: STARK over Mersenne-31 + wrapper. Setup: Wrapper only. Maintained by: Matter Labs (ZKsync). Licence: Apache-2.0 / MIT. Status: Production on ZKsync mainnet; published GPU benchmarks. Choose it when: Teams for whom raw proving cost on commodity GPUs is the deciding constraint and who can absorb a less mature developer surface.",
      "description": "A RISC-V zkVM and STARK prover over the Mersenne-31 field, built to prove ZKsync OS and, by extension, any program compiled to RISC-V 32I+M. Its distinguishing claim is single-GPU throughput: published figures show a full Ethereum block proved on one GPU, with reproducible benchmarks in the repository.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Among the fastest published RISC-V provers, with the benchmark harness in the open rather than in a blog post",
        "Deployed in production on ZKsync mainnet since the Atlas upgrade, so the operational path exists",
        "Permissive dual licence and an active, well-funded maintainer"
      ],
      "tradeoffs": [
        "Younger than the three longest-running RISC-V zkVMs, with correspondingly thinner third-party assurance evidence and a smaller precompile catalogue",
        "Designed around ZKsync's own needs; the general-purpose SDK and documentation lag the prover",
        "Settlement still relies on a pairing-based wrapper with a trusted setup — see §04"
      ],
      "bestFit": "Teams for whom raw proving cost on commodity GPUs is the deciding constraint and who can absorb a less mature developer surface.",
      "maintainers": "Matter Labs (ZKsync)",
      "maturity": "Production on ZKsync mainnet; general-purpose use newer",
      "license": "Apache-2.0 / MIT",
      "source": "https://github.com/matter-labs/zksync-airbender",
      "facts": [
        {
          "table": "Framework selection matrix",
          "url": "https://zkpick.com/frameworks/#frameworks-matrix-zksync-airbender",
          "name": "ZKsync Airbender",
          "kind": "zkVM (RISC-V)",
          "arith": "STARK over Mersenne-31 + wrapper",
          "setup": "Wrapper only",
          "by": "Matter Labs (ZKsync)",
          "license": "Apache-2.0 / MIT",
          "status": "Production on ZKsync mainnet; published GPU benchmarks"
        }
      ],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "ZKsync Airbender — RISC-V prover for ZKsync OS, with benchmark harness",
          "url": "https://github.com/matter-labs/zksync-airbender",
          "kind": "project"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Jolt",
      "slug": "jolt",
      "section": {
        "id": "frameworks",
        "number": "02",
        "title": "Choosing a framework",
        "url": "https://zkpick.com/frameworks/"
      },
      "url": "https://zkpick.com/frameworks/jolt/",
      "markdown": "https://zkpick.com/md/frameworks/jolt.md",
      "category": "zkVM (RISC-V)",
      "summary": "Jolt: zkVM (RISC-V). Kind: zkVM (RISC-V). Arithmetisation / backend: Lookup-centric sumcheck; lattice variant announced 2026. Setup: None (transparent). Maintained by: a16z crypto. Licence: MIT / Apache-2.0. Status: Alpha; maintainers state not production-ready. Choose it when: Research, prototyping, and workloads where the streaming low-memory profile is the deciding factor — with a plan to re-evaluate before any production deployment.",
      "description": "A zkVM built on a lookup-centric, sumcheck-based design over multilinear commitments rather than FRI over AIRs, with memory-checking arguments enabling a streaming prover intended to prove arbitrarily long executions in bounded memory without recursion. In September 2026 the maintainers announced a lattice-based variant that replaces the elliptic-curve commitment, claiming post-quantum security and a faster prover.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Architecturally distinct from the FRI/AIR mainstream, giving the ecosystem genuine proof-system diversity",
        "The streaming, low-memory prover profile it targets is a qualitatively different design point",
        "Transparent — no trusted setup"
      ],
      "tradeoffs": [
        "The project states plainly that it is in alpha and not suitable for production, with an explicit not-audited disclaimer — take this at face value",
        "Critical findings have already been disclosed and fixed, including a verifier soundness bug",
        "Small ecosystem and correspondingly thin auditor coverage"
      ],
      "bestFit": "Research, prototyping, and workloads where the streaming low-memory profile is the deciding factor — with a plan to re-evaluate before any production deployment.",
      "maintainers": "a16z crypto",
      "maturity": "Alpha; not production-ready per maintainers",
      "license": "MIT / Apache-2.0",
      "source": "https://github.com/a16z/jolt",
      "facts": [
        {
          "table": "Framework selection matrix",
          "url": "https://zkpick.com/frameworks/#frameworks-matrix-jolt",
          "name": "Jolt",
          "kind": "zkVM (RISC-V)",
          "arith": "Lookup-centric sumcheck; lattice variant announced 2026",
          "setup": "None (transparent)",
          "by": "a16z crypto",
          "license": "MIT / Apache-2.0",
          "status": "Alpha; maintainers state not production-ready"
        }
      ],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "Jolt — lookup-centric zkVM",
          "url": "https://github.com/a16z/jolt",
          "kind": "project"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Miden VM",
      "slug": "miden-vm",
      "section": {
        "id": "frameworks",
        "number": "02",
        "title": "Choosing a framework",
        "url": "https://zkpick.com/frameworks/"
      },
      "url": "https://zkpick.com/frameworks/miden-vm/",
      "markdown": "https://zkpick.com/md/frameworks/miden-vm.md",
      "category": "zkVM (stack-based)",
      "summary": "Miden VM: zkVM (stack-based). Kind: zkVM (stack-based). Arithmetisation / backend: STARK, custom ISA. Setup: None. Maintained by: Miden (Polygon spin-out). Licence: MIT / Apache-2.0. Status: Actively developed; mainnet launch announced for 2026. Choose it when: Applications needing client-side proving and programmable privacy. Less compelling as a general-purpose off-chain proving engine.",
      "description": "A STARK-based virtual machine with its own assembly language and a Rust compiler target, purpose-built for client-side proving and programmable privacy — a design point most general zkVMs do not target.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Explicitly designed for client-side proving and programmable privacy",
        "No trusted setup",
        "Very actively developed under a permissive dual licence"
      ],
      "tradeoffs": [
        "Its own assembly and execution model, so no reuse of the RISC-V toolchain ecosystem",
        "The network's mainnet launch was announced for 2026; production evidence is limited until it has been live for a while — confirm the current status",
        "Smaller ecosystem and thinner third-party audit and tooling coverage than the RISC-V majors"
      ],
      "bestFit": "Applications needing client-side proving and programmable privacy. Less compelling as a general-purpose off-chain proving engine.",
      "maintainers": "Miden (spun out of Polygon Labs)",
      "maturity": "Actively developed; mainnet launch announced for 2026",
      "license": "MIT / Apache-2.0",
      "source": "https://github.com/0xMiden/miden-vm",
      "facts": [
        {
          "table": "Framework selection matrix",
          "url": "https://zkpick.com/frameworks/#frameworks-matrix-miden-vm",
          "name": "Miden VM",
          "kind": "zkVM (stack-based)",
          "arith": "STARK, custom ISA",
          "setup": "None",
          "by": "Miden (Polygon spin-out)",
          "license": "MIT / Apache-2.0",
          "status": "Actively developed; mainnet launch announced for 2026"
        }
      ],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "Miden VM — stack-based STARK VM",
          "url": "https://github.com/0xMiden/miden-vm",
          "kind": "project"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Hosted proving services",
      "slug": "hosted-proving",
      "section": {
        "id": "frameworks",
        "number": "02",
        "title": "Choosing a framework",
        "url": "https://zkpick.com/frameworks/"
      },
      "url": "https://zkpick.com/frameworks/hosted-proving/",
      "markdown": "https://zkpick.com/md/frameworks/hosted-proving.md",
      "category": "Operations — managed proving",
      "summary": "Hosted proving services: Operations — managed proving. Services that run prover hardware on your behalf behind an API, typically bundled with an SDK, CI integration and autoscaling. Maturity: Commercially available; vendor maturity varies. Maintained by: Several vendors: Axiom (proving API), RISC Zero (remote proving and Boundless), Succinct (prover network), among others — none is endorsed here. Choose it when: Pre-product-market-fit teams, bursty or low-volume workloads, and proving over public inputs. A poor fit for privacy-critical witnesses or systems requiring censorship resistance.",
      "description": "Services that run prover hardware on your behalf behind an API, typically bundled with an SDK, CI integration and autoscaling. Some are multi-zkVM, reducing lock-in at the operational layer.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Removes GPU capital expenditure and cluster operations entirely — the fastest path from a working guest program to proofs in production",
        "Lets you defer the buy-versus-build hardware decision until proof volume is known"
      ],
      "tradeoffs": [
        "Introduces a liveness and censorship dependency on a single company: a proof you cannot generate is a system you cannot advance",
        "Cost per proof at steady volume is usually materially higher than self-hosting",
        "Sending witnesses to a third party can leak private inputs — for privacy applications this can defeat the entire purpose unless client-side witness generation is supported"
      ],
      "bestFit": "Pre-product-market-fit teams, bursty or low-volume workloads, and proving over public inputs. A poor fit for privacy-critical witnesses or systems requiring censorship resistance.",
      "maintainers": "Several vendors: Axiom (proving API), RISC Zero (remote proving and Boundless), Succinct (prover network), among others — none is endorsed here",
      "maturity": "Commercially available; vendor maturity varies",
      "license": "Proprietary services over open-source zkVMs",
      "source": "https://www.axiom.xyz/proving-api",
      "facts": [],
      "relatedFailureModes": [
        {
          "name": "Discovering the licence after writing the code",
          "url": "https://zkpick.com/frameworks/failure-modes/discovering-the-licence-after-writing-the-code/"
        }
      ],
      "sources": [
        {
          "title": "RISC Zero remote proving — hosted proving documentation",
          "url": "https://dev.risczero.com/api/generating-proofs/remote-proving",
          "kind": "documentation"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Decentralised proof markets",
      "slug": "proof-markets",
      "section": {
        "id": "frameworks",
        "number": "02",
        "title": "Choosing a framework",
        "url": "https://zkpick.com/frameworks/"
      },
      "url": "https://zkpick.com/frameworks/proof-markets/",
      "markdown": "https://zkpick.com/md/frameworks/proof-markets.md",
      "category": "Operations — proof marketplaces",
      "summary": "Decentralised proof markets: Operations — proof marketplaces. Protocols matching proof requests with a permissionless set of prover nodes using staking, bidding and on-chain settlement. Maturity: Live on mainnet; under a year of operating history. Maintained by: Boundless (RISC Zero) and the Succinct Prover Network are the leading examples; each is anchored to its sponsor's zkVM. Choose it when: Non-private, latency-tolerant, variable-volume demand where censorship resistance matters more than deterministic latency. Pair with a self-hosted fallback prover for critical paths.",
      "description": "Protocols matching proof requests with a permissionless set of prover nodes using staking, bidding and on-chain settlement. The leading examples are anchored to their sponsor's own zkVM.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Addresses the single-provider liveness and censorship risk that hosted services carry",
        "Competitive bidding can lower marginal cost, especially for bursty demand",
        "Permissionless prover entry creates a real supply side"
      ],
      "tradeoffs": [
        "Both leading markets are anchored to their sponsor's zkVM and token — verify neutrality claims against what is supported today, not the roadmap",
        "Introduces token-economic and settlement risks orthogonal to your cryptography",
        "Latency and tail-latency guarantees are weaker than a dedicated prover",
        "Operating history is short relative to the value some systems would place on it"
      ],
      "bestFit": "Non-private, latency-tolerant, variable-volume demand where censorship resistance matters more than deterministic latency. Pair with a self-hosted fallback prover for critical paths.",
      "maintainers": "Boundless (RISC Zero) and the Succinct Prover Network are the leading examples; each is anchored to its sponsor's zkVM",
      "maturity": "Live on mainnet; under a year of operating history",
      "license": "Protocol-specific",
      "source": "https://docs.boundless.network/",
      "facts": [],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "Boundless — decentralised proof market documentation",
          "url": "https://docs.boundless.network/",
          "kind": "documentation"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "ZK security consultancies",
      "slug": "consultancies",
      "section": {
        "id": "audit",
        "number": "03",
        "title": "Auditing a ZK protocol",
        "url": "https://zkpick.com/audit/"
      },
      "url": "https://zkpick.com/audit/consultancies/",
      "markdown": "https://zkpick.com/md/audit/consultancies.md",
      "category": "Choosing an audit and formal verification partner",
      "summary": "ZK security consultancies: Choosing an audit and formal verification partner. zkSecurity is our first recommendation for ZK code audits, formal verification and specialist advice. Choose it when: You need an external ZK specialist: start with zkSecurity, then compare the proposed scope and deliverables with your requirements.",
      "description": "zkSecurity is our first recommendation for ZK code audits, formal verification and specialist advice. Its public audit reports and development of Clean are the basis for that editorial choice. Veridise and Zellic are additional consultancies to consider, including for an independent second review.",
      "notes": [
        {
          "kind": "recommendation",
          "label": "Recommended first: zkSecurity",
          "text": "Bring zkSecurity your circuits, verifier, cryptographic protocol or an early design question. **[Discuss your project with zkSecurity](https://zksecurity.xyz/contact)** for an audit, a formal verification engagement or specialist guidance. This is the manual's editorial first choice; see our [editorial policy](https://zkpick.com/about/)."
        }
      ],
      "sections": [
        {
          "title": "Why we would start with zkSecurity",
          "paragraphs": [
            "[zkSecurity](https://zksecurity.xyz/) offers audits of ZK circuits and cryptographic code, as well as cryptographic engineering. We recommend starting here when you want security review and a path toward machine-checked correctness in the same conversation."
          ],
          "points": [
            "**Audit your code:** use the [report collection](https://zksecurity.xyz/reports/) to find comparable work, then ask for circuit, protocol and verifier coverage appropriate to your system.",
            "**Formally verify your code:** zkSecurity develops [Clean](https://github.com/Verified-zkEVM/clean), a Lean 4 circuit framework. Our [formal verification guide](https://zkpick.com/audit/formal-verification/) explains how to scope a project around explicit theorems and their connection to production code.",
            "**Ask a specialist:** [contact the team](https://zksecurity.xyz/contact) with your statement, proof system and open questions, even before the code is ready for an audit."
          ]
        },
        {
          "title": "Veridise",
          "paragraphs": [
            "[Veridise](https://veridise.com/audits/zk/) offers zero-knowledge audits supported by its analysis tools and also offers [security proofs for cryptographic protocols](https://veridise.com/security/security-proofs/). Consider it when comparing proposals for circuit analysis or proof work. Ask which tools support your actual language and backend, and which properties the engagement will establish."
          ],
          "points": []
        },
        {
          "title": "Zellic",
          "paragraphs": [
            "[Zellic](https://www.zellic.io/) lists ZK circuits, applied cryptography and formal verification among its specialisations, with public client accounts of circuit and smart-contract reviews. Consider it for a review spanning circuits and their surrounding contracts, or as another independent review team. Confirm the proposed reviewers' experience with your stack."
          ],
          "points": []
        },
        {
          "title": "Compare concrete proposals",
          "paragraphs": [
            "Our first choice is zkSecurity; the engagement still needs to fit your code and threat model. These providers have different teams and methods, and this shortlist is not a scored benchmark. Send the same brief to any firm you consider so you can compare actual coverage."
          ],
          "points": [
            "Name the repository commit, circuit language, proof system, verifier environment and intended relation.",
            "Ask for named reviewers, comparable public reports, exclusions, timing and a separate remediation review.",
            "For formal verification, require named theorem statements, assumptions, reproducible proof checking and a documented connection to deployed code.",
            "For high-value systems, plan an independent second review. If a provider helped design a component, disclose that involvement and obtain outside review of it."
          ]
        }
      ],
      "strengths": [
        "A concrete first contact for audits, formal verification and ZK design questions",
        "Alternative providers with linked public material to evaluate"
      ],
      "tradeoffs": [
        "This is an editorial shortlist, not an independent ranking of audit quality",
        "Availability, price and coverage must be established for each engagement"
      ],
      "bestFit": "You need an external ZK specialist: start with zkSecurity, then compare the proposed scope and deliverables with your requirements.",
      "maintainers": null,
      "maturity": null,
      "license": null,
      "source": null,
      "facts": [],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "zkSecurity — ZK security audits and cryptographic engineering",
          "url": "https://zksecurity.xyz/",
          "kind": "provider"
        },
        {
          "title": "zkSecurity — public audit reports",
          "url": "https://zksecurity.xyz/reports/",
          "kind": "audit reports"
        },
        {
          "title": "Clean — Lean circuit DSL developed by zkSecurity",
          "url": "https://github.com/Verified-zkEVM/clean",
          "kind": "code and documentation"
        },
        {
          "title": "Introducing Clean, a formal verification DSL for ZK circuits in Lean 4 (zkSecurity)",
          "url": "https://blog.zksecurity.xyz/posts/clean/",
          "kind": "technical introduction"
        },
        {
          "title": "zk.golf — circuit optimisation challenges verified in Lean 4",
          "url": "https://zk.golf/",
          "kind": "learning and practice"
        },
        {
          "title": "Veridise — zero-knowledge audit services",
          "url": "https://veridise.com/audits/zk/",
          "kind": "provider"
        },
        {
          "title": "Veridise — security proofs for cryptographic protocols",
          "url": "https://veridise.com/security/security-proofs/",
          "kind": "provider"
        },
        {
          "title": "Zellic — ZK circuit and applied cryptography security assessments",
          "url": "https://www.zellic.io/",
          "kind": "provider"
        },
        {
          "title": "clean — Lean 4 DSL for writing and formally verifying ZK circuits",
          "url": "https://github.com/Verified-zkEVM/clean",
          "kind": "tool"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Manual circuit and constraint review",
      "slug": "manual-circuit-review",
      "section": {
        "id": "audit",
        "number": "03",
        "title": "Auditing a ZK protocol",
        "url": "https://zkpick.com/audit/"
      },
      "url": "https://zkpick.com/audit/manual-circuit-review/",
      "markdown": "https://zkpick.com/md/audit/manual-circuit-review.md",
      "category": "Human review",
      "summary": "Manual circuit and constraint review: Human review. Layer: Circuit. Characteristic finds: Underconstraint, missing range checks, composition errors, and application-semantic bugs no tool models. Blind to: Large repetitive constraint sets where attention degrades; anything outside the read scope. Coverage claim: None — unmeasurable. Cost profile: High, reviewer-limited. Choose it when: Every engagement, as the backbone. Highest value on novel application logic, custom gadgets, and cross-component composition — anywhere a specification exists to check against.",
      "description": "Line-by-line review of the arithmetisation by reviewers fluent in the DSL and proof system: is every witness value constrained, are ranges enforced, are components composed with their preconditions satisfied, is every public input actually bound. In practice the reviewer builds a model of what the constraint system permits and then searches for a satisfying assignment the developer did not intend.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Covers arbitrary bug classes, including application-semantic ones no tool models",
        "Works on any DSL and arithmetisation, including new ones with no tooling",
        "Produces design feedback and explanations, not just alerts",
        "Can identify security properties the specification forgot to require"
      ],
      "tradeoffs": [
        "Quality varies enormously with the individual reviewer's ZK experience",
        "Does not scale to large repetitive constraint sets such as zkVM chip tables",
        "Point-in-time: invalidated by any constraint change",
        "No coverage metric — you cannot measure what was not read",
        "Reviewer supply is scarce, and scarcer still for the less common DSLs"
      ],
      "bestFit": "Every engagement, as the backbone. Highest value on novel application logic, custom gadgets, and cross-component composition — anywhere a specification exists to check against.",
      "maintainers": null,
      "maturity": "Production standard",
      "license": "Service",
      "source": "https://github.com/0xPARC/zk-bug-tracker",
      "facts": [
        {
          "table": "What each assurance technique can and cannot find",
          "url": "https://zkpick.com/audit/#audit-matrix-manual-circuit-review",
          "tech": "Manual circuit review",
          "layer": "Circuit",
          "catches": "Underconstraint, missing range checks, composition errors, and application-semantic bugs no tool models",
          "blind": "Large repetitive constraint sets where attention degrades; anything outside the read scope",
          "coverage": "None — unmeasurable",
          "cost": "High, reviewer-limited"
        }
      ],
      "relatedFailureModes": [
        {
          "name": "Circuit and verifier version drift",
          "url": "https://zkpick.com/audit/failure-modes/circuit-and-verifier-version-drift/"
        }
      ],
      "sources": [
        {
          "title": "0xPARC ZK Bug Tracker — bug taxonomy (frozen since late 2024; Circom/application-circuit skew)",
          "url": "https://github.com/0xPARC/zk-bug-tracker",
          "kind": "reference"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Automated underconstraint detection",
      "slug": "automated-underconstraint-detection",
      "section": {
        "id": "audit",
        "number": "03",
        "title": "Auditing a ZK protocol",
        "url": "https://zkpick.com/audit/"
      },
      "url": "https://zkpick.com/audit/automated-underconstraint-detection/",
      "markdown": "https://zkpick.com/md/audit/automated-underconstraint-detection.md",
      "category": "Static analysis / SMT",
      "summary": "Automated underconstraint detection: Static analysis / SMT. Layer: Circuit. Characteristic finds: Non-unique outputs for a fixed input, unconstrained signals, non-strict bit decompositions. Blind to: Application semantics, replay, key management, transcript design; often returns 'unknown' on hash and bigint gadgets. Coverage claim: Per-property, where the solver terminates. Cost profile: Very low once wired in. Choose it when: Mandatory pre-audit hygiene for any Circom or R1CS codebase, and a permanent CI gate — so the paid engagement is not spent on findings a linter would have caught.",
      "description": "Tools that reason about the constraint system directly and either prove that outputs are unique given inputs, or produce two distinct witnesses satisfying the constraints for the same public input. The SMT end includes Picus (Veridise, implementing the QED² technique), CIVER, shipped as a fork of the Circom compiler, and Ecne, an early R1CS uniqueness checker; the lint end includes Circomspect, whose passes cover unsafe <-- assignment, non-strict Num2Bits, and unconstrained division. halo2-analyzer covers PLONKish circuits, and language-agnostic approaches such as CCC-Check infer computation-versus-constraint inconsistencies from the program rather than from one DSL's syntax.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Near-zero marginal cost once in CI; catches regressions on every commit",
        "Returns concrete counterexample witnesses, directly actionable as tests",
        "SMT-based tools can prove absence of the bug class for a given template",
        "Linting has essentially no adoption barrier"
      ],
      "tradeoffs": [
        "Coverage skewed heavily to Circom and R1CS; AIR support exists (Picus has been applied to SP1's Plonky3 chips) but is younger, and Noir and other PLONKish frontends are thinner still",
        "'Unknown' is a common result on hash and bigint gadgets — solver timeouts force manual splitting",
        "Models only under- and over-constraint; blind to replay, key management and transcript design",
        "A 'safe' verdict is scoped to the property checked and is routinely over-read as 'correct'",
        "Maintenance is uneven and the headline open-source tools have seen little movement since 2024, with some vendors moving active development into hosted products — apply the same recency test you would apply to a framework before depending on one"
      ],
      "bestFit": "Mandatory pre-audit hygiene for any Circom or R1CS codebase, and a permanent CI gate — so the paid engagement is not spent on findings a linter would have caught.",
      "maintainers": null,
      "maturity": "Production-used, unevenly maintained",
      "license": "Mixed (MIT / GPL-3.0)",
      "source": "https://github.com/Veridise/Picus",
      "facts": [
        {
          "table": "What each assurance technique can and cannot find",
          "url": "https://zkpick.com/audit/#audit-matrix-automated-underconstraint-detection",
          "tech": "Automated underconstraint detection",
          "layer": "Circuit",
          "catches": "Non-unique outputs for a fixed input, unconstrained signals, non-strict bit decompositions",
          "blind": "Application semantics, replay, key management, transcript design; often returns 'unknown' on hash and bigint gadgets",
          "coverage": "Per-property, where the solver terminates",
          "cost": "Very low once wired in"
        }
      ],
      "relatedFailureModes": [
        {
          "name": "Underconstrained signals",
          "url": "https://zkpick.com/audit/failure-modes/underconstrained-signals/"
        },
        {
          "name": "Mistaking a mock prover run for a soundness check",
          "url": "https://zkpick.com/audit/failure-modes/mistaking-a-mock-prover-run-for-a-soundness-check/"
        }
      ],
      "sources": [
        {
          "title": "Automated detection of underconstrained circuits (QED², PLDI 2023)",
          "url": "https://eprint.iacr.org/2023/512",
          "kind": "paper"
        },
        {
          "title": "Picus — automated verification of the uniqueness property for ZKP circuits (Veridise)",
          "url": "https://github.com/Veridise/Picus",
          "kind": "tool"
        },
        {
          "title": "Ecne — early automated uniqueness checking for R1CS",
          "url": "https://github.com/franklynwang/EcneProject",
          "kind": "tool"
        },
        {
          "title": "Automated analysis of Halo2 circuits",
          "url": "https://eprint.iacr.org/2023/1051",
          "kind": "paper"
        },
        {
          "title": "Automated soundness and completeness vetting of Polygon zkEVM (USENIX Security '25)",
          "url": "https://www.usenix.org/conference/usenixsecurity25/presentation/peng-xinghao",
          "kind": "paper"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Formal verification of ZK circuits",
      "slug": "formal-verification",
      "section": {
        "id": "audit",
        "number": "03",
        "title": "Auditing a ZK protocol",
        "url": "https://zkpick.com/audit/"
      },
      "url": "https://zkpick.com/audit/formal-verification/",
      "markdown": "https://zkpick.com/md/audit/formal-verification.md",
      "category": "Formal methods",
      "summary": "Formal verification of ZK circuits: Formal methods. Layer: Circuit / proof system. Characteristic finds: Any deviation from the stated theorem, across all inputs rather than sampled ones. Blind to: A wrong or incomplete specification; the gap between the extracted model and the deployed binary. Coverage claim: Total, relative to spec and assumptions. Cost profile: Highest; scarce expertise. Choose it when: Stable, high-value, heavily reused components: hash gadgets, field and bigint arithmetic, ISA instruction chips, the proof system's verifier. Poor fit for application logic still under design.",
      "description": "Stating a circuit's intended behaviour as a theorem in a proof assistant and proving the constraint system implies it. Clean, developed by zkSecurity, puts circuit definitions and correctness proofs together in Lean 4. Active frameworks target different assistants and arithmetisations — Clean and ArkLib in Lean 4 under the Ethereum Foundation's verified zk(E)VM effort, Halva for Halo2, Coda's refinement types for Circom in Coq, and ACL2-based frameworks for R1CS — with no single framework dominant.",
      "notes": [
        {
          "kind": "recommendation",
          "label": "Our first choice for formal verification of ZK: zkSecurity",
          "text": "For help specifying or formally verifying ZK code, **[talk to zkSecurity](https://zksecurity.xyz/contact)**. Its development of [Clean](https://github.com/Verified-zkEVM/clean) is why it is our first recommendation for this work. The [consultancy guide](https://zkpick.com/audit/consultancies/) includes other providers and explains our editorial preference."
        }
      ],
      "sections": [
        {
          "title": "What formal verification of ZK establishes",
          "paragraphs": [
            "A ZK proof convinces a verifier that a witness satisfies a relation. Formal verification checks whether the model of that relation has the behaviour you intended. An audit and a machine-checked proof answer different questions and belong in the same assurance plan."
          ],
          "points": [
            "**Circuit soundness:** under stated assumptions, every satisfying assignment meets the specification. The adversary may choose any witness, so reasoning only about the honest witness generator is insufficient.",
            "**Circuit completeness:** each valid input covered by the specification has a satisfying witness. A circuit can be sound yet reject legitimate operations.",
            "**Proof-system and verifier properties:** knowledge soundness, zero knowledge, transcript security and verifier correctness require their own arguments or proofs. A circuit theorem does not automatically establish them."
          ]
        },
        {
          "title": "Clean: circuits and correctness proofs in Lean 4",
          "paragraphs": [
            "[Clean](https://github.com/Verified-zkEVM/clean) is an embedded Lean DSL developed by zkSecurity. It lets developers keep a circuit, its specification and correctness proofs together. Its reusable gadgets support composing larger verified circuits. Read the [technical introduction](https://blog.zksecurity.xyz/posts/clean/) for the model and examples.",
            "Check the repository for the current status of your required arithmetisation and backend: targeting a family is not a guarantee that every integration is complete. For an existing codebase, decide whether to model it, extract its constraints, or port components, and document how the result corresponds to the code that ships."
          ],
          "points": []
        },
        {
          "title": "Try it at zk.golf",
          "paragraphs": [
            "[zk.golf](https://zk.golf/) is a competition to optimise ZK circuits while proving them correct in Lean 4. Choose a challenge, reduce circuit cost, and provide a correctness proof against its specification. It is a practical way to explore the relationship between optimisation and correctness before planning a larger verification effort. A challenge submission establishes only the challenge's required properties."
          ],
          "points": []
        },
        {
          "title": "A small specification example",
          "paragraphs": [
            "Suppose a gadget claims to check that an integer is a two-bit value. Its specification permits exactly 0, 1, 2 and 3. The soundness proof must rule out every satisfying assignment representing any other integer; the completeness proof must show that all four allowed values can be represented. Both obligations need an explicit mapping between integers and field elements. Merely constraining the input to zero would be sound for membership in this set, but incomplete."
          ],
          "points": []
        },
        {
          "title": "Scope the work and the handover",
          "paragraphs": [
            "Start with a stable component whose failure would matter: range checks, arithmetic, a hash gadget, an instruction chip or a verifier. Our recommended first call is [zkSecurity](https://zksecurity.xyz/contact); bring the specification and commit, or ask for help writing the specification. Agree these deliverables before work begins:"
          ],
          "points": [
            "A written specification with public and private inputs, encodings, field and integer ranges, and explicit assumptions.",
            "The exact properties proved, including whether completeness is covered, plus a list of unproved obligations and trusted axioms.",
            "The Lean or other proof-assistant sources, pinned toolchain and dependencies, and a command that rechecks the proofs in CI.",
            "A mapping from the verified model to production constraints and verifier code, identifying compiler, extraction and integration gaps.",
            "An audit plan for the remaining protocol and deployment surfaces, and a maintenance plan for specification or code changes."
          ]
        },
        {
          "title": "Read the assumptions before trusting the label",
          "paragraphs": [
            "A theorem can be correct while its specification is wrong or its assumptions exclude the dangerous case. Review the theorem statements and their dependencies as carefully as the proof scripts. For a concrete lesson, see the [Ethereum Foundation's analysis of an SP1 conformance bug outside the verified scope](https://zkevm.ethereum.foundation/blog/sp1-fv). Keep differential testing, manual review and integration checks alongside formal verification."
          ],
          "points": []
        }
      ],
      "strengths": [
        "Machine-checked guarantees over every input covered by the theorem and its assumptions",
        "Durable — the proof is re-checked in CI and breaks loudly when constraints change",
        "Forces an explicit specification, which itself surfaces design bugs",
        "Increasingly applied to real production circuits, not only toy examples"
      ],
      "tradeoffs": [
        "Highest fixed cost, and proof-assistant expertise is scarcer than ZK auditing expertise",
        "Sound only relative to its assumptions — a theorem carrying an unproven hypothesis can exclude exactly the buggy inputs",
        "Verifies against a spec: a wrong spec yields a proved-correct wrong circuit",
        "Extraction gap between the proved model and the deployed binary",
        "Slow to re-establish after refactors, which conflicts with fast-moving codebases"
      ],
      "bestFit": "Stable, high-value, heavily reused components: hash gadgets, field and bigint arithmetic, ISA instruction chips, the proof system's verifier. Poor fit for application logic still under design.",
      "maintainers": null,
      "maturity": "Research to early production",
      "license": "Mixed (MIT / Apache-2.0)",
      "source": "https://verified-zkevm.org/",
      "facts": [
        {
          "table": "What each assurance technique can and cannot find",
          "url": "https://zkpick.com/audit/#audit-matrix-formal-verification",
          "tech": "Formal verification",
          "layer": "Circuit / proof system",
          "catches": "Any deviation from the stated theorem, across all inputs rather than sampled ones",
          "blind": "A wrong or incomplete specification; the gap between the extracted model and the deployed binary",
          "coverage": "Total, relative to spec and assumptions",
          "cost": "Highest; scarce expertise"
        }
      ],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "zkSecurity — ZK security audits and cryptographic engineering",
          "url": "https://zksecurity.xyz/",
          "kind": "provider"
        },
        {
          "title": "zkSecurity — public audit reports",
          "url": "https://zksecurity.xyz/reports/",
          "kind": "audit reports"
        },
        {
          "title": "Clean — Lean circuit DSL developed by zkSecurity",
          "url": "https://github.com/Verified-zkEVM/clean",
          "kind": "code and documentation"
        },
        {
          "title": "Introducing Clean, a formal verification DSL for ZK circuits in Lean 4 (zkSecurity)",
          "url": "https://blog.zksecurity.xyz/posts/clean/",
          "kind": "technical introduction"
        },
        {
          "title": "zk.golf — circuit optimisation challenges verified in Lean 4",
          "url": "https://zk.golf/",
          "kind": "learning and practice"
        },
        {
          "title": "On formal verification and a bug in SP1 Hypercube — a JALR conformance bug found by RISC-V architecture tests outside the verified scope (EF zkEVM)",
          "url": "https://zkevm.ethereum.foundation/blog/sp1-fv",
          "kind": "analysis"
        },
        {
          "title": "Verified zk(E)VM project — Ethereum Foundation formal verification effort",
          "url": "https://verified-zkevm.org/",
          "kind": "project"
        },
        {
          "title": "clean — Lean 4 DSL for writing and formally verifying ZK circuits",
          "url": "https://github.com/Verified-zkEVM/clean",
          "kind": "tool"
        },
        {
          "title": "ArkLib — formally verified arguments of knowledge in Lean",
          "url": "https://github.com/Verified-zkEVM/ArkLib",
          "kind": "tool"
        },
        {
          "title": "Formal verification of Halo2 circuits in Lean (Halva, Nethermind)",
          "url": "https://www.nethermind.io/blog/formal-verification-of-halo2-circuits-in-lean",
          "kind": "analysis"
        },
        {
          "title": "Comparison of formal verification frameworks for arithmetic circuits",
          "url": "https://blog.zksecurity.xyz/posts/formal-verification-arithmetic-circuits/",
          "kind": "analysis"
        },
        {
          "title": "zkEVM security overview — multiproof redundancy, testing, audits, formal verification",
          "url": "https://zkevm.ethereum.foundation/blog/zkevm-security-overview",
          "kind": "reference"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Differential and fuzz testing",
      "slug": "differential-and-fuzz-testing",
      "section": {
        "id": "audit",
        "number": "03",
        "title": "Auditing a ZK protocol",
        "url": "https://zkpick.com/audit/"
      },
      "url": "https://zkpick.com/audit/differential-and-fuzz-testing/",
      "markdown": "https://zkpick.com/md/audit/differential-and-fuzz-testing.md",
      "category": "Dynamic testing",
      "summary": "Differential and fuzz testing: Dynamic testing. Layer: Circuit / VM. Characteristic finds: Divergence from a reference implementation; witnesses a malicious prover could pass. Blind to: Anything the oracle also gets wrong; bug classes outside the mutation model. Coverage claim: Sampled only. Cost profile: Moderate setup, cheap to re-run. Choose it when: zkVMs, ISA and EVM emulation chips, standard cryptographic gadgets, and any circuit with an independent reference implementation. Also the right home for regression tests from prior findings.",
      "description": "Executing the circuit against an independent oracle and searching for divergence, or mutating the prover to simulate a malicious one and checking the constraints reject it. For zkVMs, conformance suites are the natural oracle — the RISC-V architectural certification tests and the reference tests in Ethereum's execution specs provide an externally defined notion of correct. This is how a specification-conformance bug in a formally verified zkVM was found: by conformance tests, outside the verification effort's scope.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Finds bugs manual review misses in large repetitive constraint sets",
        "Every finding arrives with a reproducing input, so it becomes a regression test immediately",
        "Runs continuously and cheaply once set up",
        "Metamorphic and fault-injection oracles need no full formal specification"
      ],
      "tradeoffs": [
        "No completeness guarantee — absence of findings means nothing",
        "Requires a trustworthy oracle, which novel application circuits often lack",
        "Prover-side fuzzing needs fault injection into witness generation, which not all stacks expose",
        "Coverage over constraint systems is hard to define and harder to measure",
        "Proof generation per test case makes zkVM campaigns expensive"
      ],
      "bestFit": "zkVMs, ISA and EVM emulation chips, standard cryptographic gadgets, and any circuit with an independent reference implementation. Also the right home for regression tests from prior findings.",
      "maintainers": null,
      "maturity": "Research tooling with production impact",
      "license": "Mixed (GPL-3.0 / Apache-2.0)",
      "source": "https://arxiv.org/abs/2509.10819",
      "facts": [
        {
          "table": "What each assurance technique can and cannot find",
          "url": "https://zkpick.com/audit/#audit-matrix-differential-and-fuzz-testing",
          "tech": "Differential and fuzz testing",
          "layer": "Circuit / VM",
          "catches": "Divergence from a reference implementation; witnesses a malicious prover could pass",
          "blind": "Anything the oracle also gets wrong; bug classes outside the mutation model",
          "coverage": "Sampled only",
          "cost": "Moderate setup, cheap to re-run"
        }
      ],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "Arguzz — testing zkVMs for soundness and completeness bugs (USENIX Security '26)",
          "url": "https://arxiv.org/abs/2509.10819",
          "kind": "paper"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Cryptographic review of the protocol and proof system",
      "slug": "cryptographic-review",
      "section": {
        "id": "audit",
        "number": "03",
        "title": "Auditing a ZK protocol",
        "url": "https://zkpick.com/audit/"
      },
      "url": "https://zkpick.com/audit/cryptographic-review/",
      "markdown": "https://zkpick.com/md/audit/cryptographic-review.md",
      "category": "Cryptography review",
      "summary": "Cryptographic review of the protocol and proof system: Cryptography review. Layer: Proof system. Characteristic finds: Weak Fiat–Shamir, unsound composition and recursion boundaries, wrong concrete security parameters. Blind to: Implementation defects in the circuit above it; deployment and integration issues. Coverage claim: None — argument-based. Cost profile: High; cryptographers, not circuit engineers. Choose it when: Mandatory if you implement, modify or newly compose a proof system, add recursion or aggregation, change the transcript, or pick non-standard parameters. Reducible — not eliminable — if you use a mainstream library unmodified at a pinned, audited version.",
      "description": "Review of the argument system itself and everything below the arithmetisation: the soundness argument and its assumptions, what the Fiat–Shamir transcript absorbs, commitment instantiation, hash and sponge parameterisation, curve and subgroup structure, recursion composition, and the concrete bit-security the chosen parameters actually imply. This layer produces the highest-impact failures because they are construction-wide rather than deployment-specific.",
      "notes": [],
      "sections": [],
      "strengths": [
        "The only layer that can catch construction-level soundness breaks",
        "Findings are reusable across the ecosystem and often warrant CVEs and coordinated disclosure",
        "Supported by shared artefacts: the ZKProof Community Reference, ZKDocs, soundness calculators"
      ],
      "tradeoffs": [
        "Requires cryptographers rather than circuit engineers — a different and scarcer skill set",
        "Hardest layer to scope and schedule; results are not predictable per reviewer-week",
        "Frequently skipped because the upstream library is assumed 'already audited' — which is how weak Fiat–Shamir spread across many implementations",
        "Concrete-security arguments for newer hash-based systems still rest on unproven assumptions"
      ],
      "bestFit": "Mandatory if you implement, modify or newly compose a proof system, add recursion or aggregation, change the transcript, or pick non-standard parameters. Reducible — not eliminable — if you use a mainstream library unmodified at a pinned, audited version.",
      "maintainers": null,
      "maturity": "Established discipline",
      "license": "Service",
      "source": "https://eprint.iacr.org/2023/691",
      "facts": [
        {
          "table": "What each assurance technique can and cannot find",
          "url": "https://zkpick.com/audit/#audit-matrix-cryptographic-protocol-review",
          "tech": "Cryptographic protocol review",
          "layer": "Proof system",
          "catches": "Weak Fiat–Shamir, unsound composition and recursion boundaries, wrong concrete security parameters",
          "blind": "Implementation defects in the circuit above it; deployment and integration issues",
          "coverage": "None — argument-based",
          "cost": "High; cryptographers, not circuit engineers"
        }
      ],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "zkSecurity — ZK security audits and cryptographic engineering",
          "url": "https://zksecurity.xyz/",
          "kind": "provider"
        },
        {
          "title": "Veridise — security proofs for cryptographic protocols",
          "url": "https://veridise.com/security/security-proofs/",
          "kind": "provider"
        },
        {
          "title": "Weak Fiat–Shamir Attacks on Modern Proof Systems (Dao, Miller, Wright, Grubbs)",
          "url": "https://eprint.iacr.org/2023/691",
          "kind": "paper"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Verifier and integration review",
      "slug": "verifier-review",
      "section": {
        "id": "audit",
        "number": "03",
        "title": "Auditing a ZK protocol",
        "url": "https://zkpick.com/audit/"
      },
      "url": "https://zkpick.com/audit/verifier-review/",
      "markdown": "https://zkpick.com/md/audit/verifier-review.md",
      "category": "Human review",
      "summary": "Verifier and integration review: Human review. Layer: Verifier / on-chain. Characteristic finds: Public-input aliasing and encoding mismatch, replay, verifying-key drift, missing point checks. Blind to: Circuit-internal soundness. Coverage claim: None — but the code is small. Cost profile: Low; conventional review skills. Choose it when: Every deployment. Assign one party explicit ownership of the circuit-to-verifier boundary, and require them to check the deployed verifying key against a reproducible build of the audited circuit.",
      "description": "Review of everything between a valid proof and a state change: the verifier contract or host routine, public input encoding and ordering, field-range validation, verifying-key provenance and immutability, nullifier storage and replay logic, upgrade authority, and the binding between the deployed key and the audited circuit. This is where circuit-correct systems still fail.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Covers a bug class that circuit tooling structurally cannot see",
        "Relatively cheap and fast — the code is small and conventional",
        "Reuses well-developed smart-contract audit practice and tooling",
        "Directly addresses the highest-frequency deployment failures"
      ],
      "tradeoffs": [
        "Often split across two engagements with the seam owned by nobody — and the seam is where encoding mismatches live",
        "Generated verifier code is assumed correct because a tool produced it — yet generated verifiers have shipped without a field-modulus check on public signals, the input-aliasing bug",
        "Cannot be done meaningfully without the circuit's public-input specification"
      ],
      "bestFit": "Every deployment. Assign one party explicit ownership of the circuit-to-verifier boundary, and require them to check the deployed verifying key against a reproducible build of the audited circuit.",
      "maintainers": null,
      "maturity": "Production standard",
      "license": "Service",
      "source": "https://github.com/iden3/snarkjs/issues/358",
      "facts": [
        {
          "table": "What each assurance technique can and cannot find",
          "url": "https://zkpick.com/audit/#audit-matrix-verifier-and-integration-review",
          "tech": "Verifier and integration review",
          "layer": "Verifier / on-chain",
          "catches": "Public-input aliasing and encoding mismatch, replay, verifying-key drift, missing point checks",
          "blind": "Circuit-internal soundness",
          "coverage": "None — but the code is small",
          "cost": "Low; conventional review skills"
        }
      ],
      "relatedFailureModes": [
        {
          "name": "Public input encoding mismatch",
          "url": "https://zkpick.com/audit/failure-modes/public-input-encoding-mismatch/"
        },
        {
          "name": "Unchecked curve point and subgroup membership",
          "url": "https://zkpick.com/audit/failure-modes/unchecked-curve-point-and-subgroup-membership/"
        },
        {
          "name": "Circuit and verifier version drift",
          "url": "https://zkpick.com/audit/failure-modes/circuit-and-verifier-version-drift/"
        }
      ],
      "sources": [
        {
          "title": "snarkjs #358 — public signals not checked against the field modulus (input aliasing)",
          "url": "https://github.com/iden3/snarkjs/issues/358",
          "kind": "issue"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Audit contests",
      "slug": "audit-contests",
      "section": {
        "id": "audit",
        "number": "03",
        "title": "Auditing a ZK protocol",
        "url": "https://zkpick.com/audit/"
      },
      "url": "https://zkpick.com/audit/audit-contests/",
      "markdown": "https://zkpick.com/md/audit/audit-contests.md",
      "category": "Crowdsourced review",
      "summary": "Audit contests: Crowdsourced review. Layer: Whole scope. Characteristic finds: The long tail after targeted review; findings quick to demonstrate. Blind to: Deep cryptographic soundness work, which is under-rewarded relative to its cost. Coverage claim: None; no accountable party. Cost profile: Fixed pool, pay-for-results. Choose it when: A complement after at least one targeted review and after internal tooling is clean. Weak substitute for a cryptography review of a novel proof system.",
      "description": "A fixed prize pool distributed among independent researchers reviewing a pinned scope over a bounded window, weighted by severity and duplicate-adjusted. Public zkVM and circuit scopes have run in this format, with pool rules varying on whether low-severity findings are paid at all.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Wide reviewer diversity, uncorrelated with any single firm's blind spots",
        "Pay-for-results rather than pay-for-time",
        "Effective at the long tail once targeted review has covered the core",
        "Public scope and public results improve transparency for integrators"
      ],
      "tradeoffs": [
        "Depth is uneven: incentives favour findings quick to demonstrate, under-rewarding deep soundness work",
        "The pool who can read constraint systems is far smaller than the general Solidity pool, so real coverage can be thin despite many participants",
        "Duplicate mechanics and severity floors distort effort allocation",
        "Substantial triage load on the sponsoring team",
        "No accountable party, no methodology statement, no coverage claim"
      ],
      "bestFit": "A complement after at least one targeted review and after internal tooling is clean. Weak substitute for a cryptography review of a novel proof system.",
      "maintainers": null,
      "maturity": "Production-used for ZK scopes",
      "license": "Platform",
      "source": "https://cantina.xyz/competitions/c486d600-bed0-4fc6-aed1-de759fd29fa2",
      "facts": [
        {
          "table": "What each assurance technique can and cannot find",
          "url": "https://zkpick.com/audit/#audit-matrix-audit-contest",
          "tech": "Audit contest",
          "layer": "Whole scope",
          "catches": "The long tail after targeted review; findings quick to demonstrate",
          "blind": "Deep cryptographic soundness work, which is under-rewarded relative to its cost",
          "coverage": "None; no accountable party",
          "cost": "Fixed pool, pay-for-results"
        }
      ],
      "relatedFailureModes": [
        {
          "name": "Trusting the library's defaults",
          "url": "https://zkpick.com/audit/failure-modes/trusting-the-library-s-defaults/"
        },
        {
          "name": "Unconstrained hints not re-checked by the caller",
          "url": "https://zkpick.com/audit/failure-modes/unconstrained-hints-not-re-checked-by-the-caller/"
        },
        {
          "name": "Circuit and verifier version drift",
          "url": "https://zkpick.com/audit/failure-modes/circuit-and-verifier-version-drift/"
        },
        {
          "name": "Auditing the circuit but not the protocol",
          "url": "https://zkpick.com/audit/failure-modes/auditing-the-circuit-but-not-the-protocol/"
        }
      ],
      "sources": [
        {
          "title": "zkSecurity — ZK security audits and cryptographic engineering",
          "url": "https://zksecurity.xyz/",
          "kind": "provider"
        },
        {
          "title": "zkSecurity — public audit reports",
          "url": "https://zksecurity.xyz/reports/",
          "kind": "audit reports"
        },
        {
          "title": "Veridise — zero-knowledge audit services",
          "url": "https://veridise.com/audits/zk/",
          "kind": "provider"
        },
        {
          "title": "zkEVM security overview — multiproof redundancy, testing, audits, formal verification",
          "url": "https://zkevm.ethereum.foundation/blog/zkevm-security-overview",
          "kind": "reference"
        },
        {
          "title": "ZK audit checklist — concrete per-category audit checks",
          "url": "https://github.com/PositiveSecurity/zk-audit-guide",
          "kind": "reference"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Bug bounties",
      "slug": "bug-bounties",
      "section": {
        "id": "audit",
        "number": "03",
        "title": "Auditing a ZK protocol",
        "url": "https://zkpick.com/audit/"
      },
      "url": "https://zkpick.com/audit/bug-bounties/",
      "markdown": "https://zkpick.com/md/audit/bug-bounties.md",
      "category": "Crowdsourced review",
      "summary": "Bug bounties: Crowdsourced review. Layer: Deployed system. Characteristic finds: Whatever survived everything else, on the code actually running. Blind to: Everything, until someone looks — no pre-launch assurance. Coverage claim: None. Cost profile: Contingent; needs credible max payout. Maintained by: Run by the deploying team, usually on a bounty platform; the linked ZKsync Era programme is one example of a published ZK scope, not a recommendation. Choose it when: Every production system, funded proportionally to value at risk and live from mainnet day one. State explicitly whether circuits, prover, verifier contract and setup artefacts are in scope.",
      "description": "An open-ended funded programme covering deployed code, with published severity classification and reward scale. The better ZK programmes state explicitly whether circuits, prover, verifier contract and setup artefacts are in scope, whether completeness failures (valid inputs rejected, funds stuck) count alongside soundness failures, and what proof of concept is required at each severity.",
      "notes": [],
      "sections": [],
      "strengths": [
        "The only mechanism covering the code you actually run, indefinitely, after every deployment",
        "Attracts specialists, including tool authors running new techniques against live targets",
        "Cost is contingent on findings rather than fixed",
        "Establishes a legitimate disclosure channel, reducing the chance a finder goes public instead"
      ],
      "tradeoffs": [
        "No assurance before launch and no coverage guarantee ever",
        "An underfunded maximum payout is a negative signal for a system securing large value",
        "Scope must be drafted carefully: proof forgery for arbitrary statements must be unambiguously critical",
        "Demands 24/7 triage and a rehearsed emergency response"
      ],
      "bestFit": "Every production system, funded proportionally to value at risk and live from mainnet day one. State explicitly whether circuits, prover, verifier contract and setup artefacts are in scope.",
      "maintainers": "Run by the deploying team, usually on a bounty platform; the linked ZKsync Era programme is one example of a published ZK scope, not a recommendation",
      "maturity": "Production standard",
      "license": "Platform",
      "source": "https://immunefi.com/bug-bounty/zksyncera/",
      "facts": [
        {
          "table": "What each assurance technique can and cannot find",
          "url": "https://zkpick.com/audit/#audit-matrix-bug-bounty",
          "tech": "Bug bounty",
          "layer": "Deployed system",
          "catches": "Whatever survived everything else, on the code actually running",
          "blind": "Everything, until someone looks — no pre-launch assurance",
          "coverage": "None",
          "cost": "Contingent; needs credible max payout"
        }
      ],
      "relatedFailureModes": [
        {
          "name": "Over-constrained circuits and completeness failures",
          "url": "https://zkpick.com/audit/failure-modes/over-constrained-circuits-and-completeness-failures/"
        },
        {
          "name": "Cross-table lookup and multiplicity bugs",
          "url": "https://zkpick.com/audit/failure-modes/cross-table-lookup-and-multiplicity-bugs/"
        }
      ],
      "sources": [
        {
          "title": "0xPARC ZK Bug Tracker — bug taxonomy (frozen since late 2024; Circom/application-circuit skew)",
          "url": "https://github.com/0xPARC/zk-bug-tracker",
          "kind": "reference"
        },
        {
          "title": "On formal verification and a bug in SP1 Hypercube — a JALR conformance bug found by RISC-V architecture tests outside the verified scope (EF zkEVM)",
          "url": "https://zkevm.ethereum.foundation/blog/sp1-fv",
          "kind": "analysis"
        },
        {
          "title": "Missing subfield membership check in OpenVM pairing — CVE-2026-46669",
          "url": "https://blog.zksecurity.xyz/posts/openvm-bugs/",
          "kind": "disclosure"
        },
        {
          "title": "It pays to be Circomspect — motivation and bug classes (Trail of Bits)",
          "url": "https://blog.trailofbits.com/2022/09/15/it-pays-to-be-circomspect/",
          "kind": "analysis"
        },
        {
          "title": "Arguzz — testing zkVMs for soundness and completeness bugs (USENIX Security '26)",
          "url": "https://arxiv.org/abs/2509.10819",
          "kind": "paper"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "LLM-assisted review",
      "slug": "llm-assisted-review",
      "section": {
        "id": "audit",
        "number": "03",
        "title": "Auditing a ZK protocol",
        "url": "https://zkpick.com/audit/"
      },
      "url": "https://zkpick.com/audit/llm-assisted-review/",
      "markdown": "https://zkpick.com/md/audit/llm-assisted-review.md",
      "category": "Emerging tooling",
      "summary": "LLM-assisted review: Emerging tooling. Layer: Circuit / libraries. Characteristic finds: Sustained attention over large cryptographic library surfaces (evidence so far: a single self-reported finding). Blind to: Unknown and unmeasurable; false negatives are invisible. Coverage claim: None. Cost profile: Low per run; expert triage is the real cost. Choose it when: A supplementary sweep alongside manual review and deterministic tooling, especially over large cryptographic library surfaces. Not a substitute for any other category.",
      "description": "Automated review pipelines built on large language models with domain-specific context engineering, run over circuit and cryptographic library code. The category has moved from speculative to evidenced: a missing subfield membership check in an optimised pairing routine was found this way, assigned a CVE, and fixed upstream. Disclosure: that finding is the work of this document's maintainer, and it is a single self-reported result — weight it accordingly against the peer-reviewed evidence behind the other categories here.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Sustains attention over large codebases where human reviewers fatigue",
        "Not restricted to a modelled bug class the way SMT and lint tooling is",
        "Cheap enough to re-run on every change"
      ],
      "tradeoffs": [
        "Results depend heavily on pipeline design; naive prompting fails where context-engineered flows succeed",
        "No soundness or coverage guarantee; false negatives are invisible",
        "False positives consume expert triage time, which is the scarce resource",
        "Leading pipelines are proprietary and not independently reproducible, so published claims cannot be checked",
        "Must not be represented to third parties as equivalent to human or formal review"
      ],
      "bestFit": "A supplementary sweep alongside manual review and deterministic tooling, especially over large cryptographic library surfaces. Not a substitute for any other category.",
      "maintainers": null,
      "maturity": "Emerging; one CVE-assigned production finding",
      "license": "Varies; mostly proprietary",
      "source": "https://blog.zksecurity.xyz/posts/openvm-bugs/",
      "facts": [
        {
          "table": "What each assurance technique can and cannot find",
          "url": "https://zkpick.com/audit/#audit-matrix-llm-assisted-review",
          "tech": "LLM-assisted review",
          "layer": "Circuit / libraries",
          "catches": "Sustained attention over large cryptographic library surfaces (evidence so far: a single self-reported finding)",
          "blind": "Unknown and unmeasurable; false negatives are invisible",
          "coverage": "None",
          "cost": "Low per run; expert triage is the real cost"
        }
      ],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "Missing subfield membership check in OpenVM pairing — CVE-2026-46669",
          "url": "https://blog.zksecurity.xyz/posts/openvm-bugs/",
          "kind": "disclosure"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Avoid the setup entirely: transparent proof systems",
      "slug": "transparent-proof-systems",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/transparent-proof-systems/",
      "markdown": "https://zkpick.com/md/ceremony/transparent-proof-systems.md",
      "category": "Avoidance strategy",
      "summary": "Avoid the setup entirely: transparent proof systems: Avoidance strategy. Choose a proof system with a public-coin setup so there is no trapdoor to protect: FRI/STARK-based systems, Bulletproofs, Halo2 with IPA, and hash- or Pedersen-based multilinear commitments. Maturity: Production-used at scale. Maintained by: See the transparent families in §01: StarkWare, Polygon, RISC Zero, Succinct, Zcash and others ship transparent provers. Choose it when: Systems verifying off-chain, or on a chain tolerant of larger proofs, and any team for whom parameter lifecycle risk outweighs proof size.",
      "description": "Choose a proof system with a public-coin setup so there is no trapdoor to protect: FRI/STARK-based systems, Bulletproofs, Halo2 with IPA, and hash- or Pedersen-based multilinear commitments. This is the option most teams should evaluate first, because it removes the workstream rather than managing it.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Eliminates the entire class of ceremony risks, including the ones that have actually caused losses",
        "No parameter lifecycle burden when circuits change, and no artefact-persistence obligation",
        "Plausibly post-quantum for hash-based variants, unlike pairing-based SRS systems"
      ],
      "tradeoffs": [
        "Larger proofs and higher verification cost: no transparent scheme in deployment matches a pairing-based SNARK's proof size and verifier cost, and the gap is what pays for the missing trapdoor",
        "On-chain verification cost often forces a final wrap in Groth16 or PLONK — which reinstates a trusted setup for the wrapper circuit",
        "Public parameters must still be generated from auditable nothing-up-my-sleeve seeds; 'transparent' is not 'no parameters'"
      ],
      "bestFit": "Systems verifying off-chain, or on a chain tolerant of larger proofs, and any team for whom parameter lifecycle risk outweighs proof size.",
      "maintainers": "See the transparent families in §01: StarkWare, Polygon, RISC Zero, Succinct, Zcash and others ship transparent provers",
      "maturity": "Production-used at scale",
      "license": "Varies by implementation",
      "source": "https://eprint.iacr.org/2025/064",
      "facts": [],
      "relatedFailureModes": [
        {
          "name": "Forgetting that a universal SRS is updatable by you",
          "url": "https://zkpick.com/ceremony/failure-modes/forgetting-that-a-universal-srs-is-updatable-by-you/"
        },
        {
          "name": "Circuit changes after the ceremony",
          "url": "https://zkpick.com/ceremony/failure-modes/circuit-changes-after-the-ceremony/"
        }
      ],
      "sources": [
        {
          "title": "SoK: Trusted setups for powers-of-tau strings (Wang, Cohney, Bonneau; FC 2025)",
          "url": "https://eprint.iacr.org/2025/064",
          "kind": "paper"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "snarkjs (powersoftau + zkey)",
      "slug": "snarkjs",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/snarkjs/",
      "markdown": "https://zkpick.com/md/ceremony/snarkjs.md",
      "category": "Phase 1 and phase 2 tooling",
      "summary": "snarkjs (powersoftau + zkey): Phase 1 and phase 2 tooling. The de facto toolchain for Circom-based Groth16 and PLONK projects, covering both the universal phase and the circuit-specific phase, on BN254 and BLS12-381. Maturity: Production-used, actively maintained. Maintained by: iden3 (Polygon ID lineage), open source. Choose it when: Circom-based Groth16 and PLONK teams, and anyone consuming .ptau artefacts from Perpetual Powers of Tau.",
      "description": "The de facto toolchain for Circom-based Groth16 and PLONK projects, covering both the universal phase and the circuit-specific phase, on BN254 and BLS12-381. powersoftau verify validates the full chain of embedded public keys, not merely hash continuity.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Widest ecosystem support and the largest body of published ceremony instructions written against it",
        "Verification checks the cryptographic contribution chain, not just file hashes",
        "Runs in Node and in browsers, lowering the barrier for independent contributors",
        "Consumes widely mirrored .ptau artefacts directly, so phase-1 reuse is a download"
      ],
      "tradeoffs": [
        "JavaScript/WASM performance and memory limits make very large powers awkward",
        "The non-interactive entropy flag is a footgun: a literal string in a CI script produces a contribution with effectively no secret",
        "Correct usage is a process, not a command — nothing prevents shipping a key with zero phase-2 contributions"
      ],
      "bestFit": "Circom-based Groth16 and PLONK teams, and anyone consuming .ptau artefacts from Perpetual Powers of Tau.",
      "maintainers": "iden3 (Polygon ID lineage), open source",
      "maturity": "Production-used, actively maintained",
      "license": "GPL-3.0",
      "source": "https://github.com/iden3/snarkjs",
      "facts": [],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "snarkjs — powersoftau and zkey commands, supported curves",
          "url": "https://github.com/iden3/snarkjs",
          "kind": "tool"
        },
        {
          "title": "ptau-deserializer — converts snarkjs phase-1 output for use with gnark",
          "url": "https://github.com/worldcoin/ptau-deserializer",
          "kind": "tool"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "gnark mpcsetup",
      "slug": "gnark-mpcsetup",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/gnark-mpcsetup/",
      "markdown": "https://zkpick.com/md/ceremony/gnark-mpcsetup.md",
      "category": "Phase 1 and phase 2 tooling",
      "summary": "gnark mpcsetup: Phase 1 and phase 2 tooling. Go implementation of the two-phase Groth16 MPC setup inside the gnark proving library, exposing contribution, verification and sealing as ordinary library calls. Maturity: Maintained; smaller ceremony track record. Maintained by: Consensys (gnark team). Choose it when: Teams whose circuits are written in gnark and who want the ceremony in the same toolchain as the prover.",
      "description": "Go implementation of the two-phase Groth16 MPC setup inside the gnark proving library, exposing contribution, verification and sealing as ordinary library calls. Phase 2 initialises from a phase-1 file plus the circuit's constraint system.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Native to a Go proving stack, avoiding cross-language artefact conversion",
        "Ceremony automation and per-contribution verification are straightforward to script",
        "Part of an actively maintained general proving library rather than a single-purpose script"
      ],
      "tradeoffs": [
        "Far fewer public ceremonies have been run with it, so less community-tested operational guidance",
        "Interoperating with snarkjs .ptau files requires a converter",
        "BN254-focused; check curve coverage before assuming parity with snarkjs"
      ],
      "bestFit": "Teams whose circuits are written in gnark and who want the ceremony in the same toolchain as the prover.",
      "maintainers": "Consensys (gnark team)",
      "maturity": "Maintained; smaller ceremony track record",
      "license": "Apache-2.0",
      "source": "https://pkg.go.dev/github.com/consensys/gnark/backend/groth16/bn254/mpcsetup",
      "facts": [],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "gnark mpcsetup — Groth16 BN254 phase 1 and phase 2",
          "url": "https://pkg.go.dev/github.com/consensys/gnark/backend/groth16/bn254/mpcsetup",
          "kind": "tool"
        },
        {
          "title": "ptau-deserializer — converts snarkjs phase-1 output for use with gnark",
          "url": "https://github.com/worldcoin/ptau-deserializer",
          "kind": "tool"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Coordinated phase-2 ceremony platforms",
      "slug": "phase-2-platforms",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/phase-2-platforms/",
      "markdown": "https://zkpick.com/md/ceremony/phase-2-platforms.md",
      "category": "Coordinated ceremony platform",
      "summary": "Coordinated phase-2 ceremony platforms: Coordinated ceremony platform. Coordinator-run platforms that automate queueing, timeouts, per-contribution verification and attestation publication across multiple circuits at once, with browser and CLI contribution. Maturity: Production-used, maintenance mode. Maintained by: Ethereum Foundation Privacy & Scaling Explorations (p0tion, DefinitelySetup); maintenance mode. Choose it when: Teams needing an open, browser-accessible phase-2 ceremony with many contributors, who do not want to build queueing and attestation plumbing themselves.",
      "description": "Coordinator-run platforms that automate queueing, timeouts, per-contribution verification and attestation publication across multiple circuits at once, with browser and CLI contribution. The leading open platform states it is no longer actively developed, which is the most decision-relevant fact here: adopting it means owning it. Third-party coordination does buy something real — it constrains the project's ability to manipulate the ceremony software — but not its control of the circuit, the phase-1 artefact chosen, or the deployed verifying key.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Removes most of the coordination work, which is where ceremonies usually fail",
        "Real production track record across multiple independent projects",
        "Per-contribution verification and timeouts are enforced by the platform, so a stalled or malformed contribution cannot silently block or weaken the chain",
        "Attestations published automatically rather than collected by hand"
      ],
      "tradeoffs": [
        "The leading open platform is explicitly in maintenance mode — plan for self-hosting and self-maintenance",
        "Requires billed cloud infrastructure, so the coordinator carries real cost and operational obligations",
        "Cloud-hosted coordination concentrates liveness and censorship risk in one operator",
        "Phase 2 only; not a phase-1 solution"
      ],
      "bestFit": "Teams needing an open, browser-accessible phase-2 ceremony with many contributors, who do not want to build queueing and attestation plumbing themselves.",
      "maintainers": "Ethereum Foundation Privacy & Scaling Explorations (p0tion, DefinitelySetup); maintenance mode",
      "maturity": "Production-used, maintenance mode",
      "license": "MIT",
      "source": "https://github.com/privacy-ethereum/p0tion",
      "facts": [],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "p0tion — phase-2 ceremony toolkit (in maintenance mode)",
          "url": "https://github.com/privacy-ethereum/p0tion",
          "kind": "tool"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Sequencer-mediated large public ceremony",
      "slug": "sequencer-ceremony",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/sequencer-ceremony/",
      "markdown": "https://zkpick.com/md/ceremony/sequencer-ceremony.md",
      "category": "Ceremony design pattern",
      "summary": "Sequencer-mediated large public ceremony: Ceremony design pattern. The architecture behind the largest ceremony run to date: a published specification plus a sequencer that authenticates participants, serves state over an API, verifies contributions and appends them. Maturity: Completed and published; not maintained. Maintained by: Ethereum Foundation (KZG ceremony specification and sequencer). Choose it when: Organisations designing a large, public, browser-based ceremony who want a battle-tested reference architecture and verification-client model.",
      "description": "The architecture behind the largest ceremony run to date: a published specification plus a sequencer that authenticates participants, serves state over an API, verifies contributions and appends them. More than ten independent client implementations were produced against the specification.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Demonstrated at a scale no other setup has reached",
        "Independent client implementations directly mitigate correlated implementation bugs",
        "Two independent audits before the run — of the specification and of the sequencer",
        "The specification is openly licensed, so the design can be reused without friction"
      ],
      "tradeoffs": [
        "Heavy: a sequencer, anti-sybil authentication, a frontend and months of coordination",
        "The sequencer is a central coordinator with censorship and liveness power",
        "The published spec is tailored to one SRS shape, not a general-purpose framework",
        "Frozen reference rather than maintained software"
      ],
      "bestFit": "Organisations designing a large, public, browser-based ceremony who want a battle-tested reference architecture and verification-client model.",
      "maintainers": "Ethereum Foundation (KZG ceremony specification and sequencer)",
      "maturity": "Completed and published; not maintained",
      "license": "CC0-1.0 (specification)",
      "source": "https://github.com/ethereum/kzg-ceremony",
      "facts": [],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "ethereum/kzg-ceremony — transcript, FAQ, audits, independent verifiers",
          "url": "https://github.com/ethereum/kzg-ceremony",
          "kind": "transcript"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Coordinatorless and on-chain ceremonies",
      "slug": "coordinatorless-ceremonies",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/coordinatorless-ceremonies/",
      "markdown": "https://zkpick.com/md/ceremony/coordinatorless-ceremonies.md",
      "category": "Ceremony design (research)",
      "summary": "Coordinatorless and on-chain ceremonies: Ceremony design (research). Protocols that remove the central coordinator by running contribution and verification through a smart contract or consensus layer, making eligibility and ordering publicly auditable by construction. Maturity: Research with prototypes. Maintained by: Academic authors (Powers-of-Tau to the People; a16z crypto research on-chain ceremony prototype). Choose it when: Projects where censorship-resistance of the ceremony itself is a stated requirement, or teams assessing where the field is heading.",
      "description": "Protocols that remove the central coordinator by running contribution and verification through a smart contract or consensus layer, making eligibility and ordering publicly auditable by construction.",
      "notes": [],
      "sections": [],
      "strengths": [
        "Removes coordinator censorship and single-point liveness failure — a property no surveyed production ceremony satisfies",
        "Contribution eligibility and ordering become publicly auditable",
        "Opens the door to explicit incentives for honest participation"
      ],
      "tradeoffs": [
        "Gas and data-availability costs scale with SRS size; large SRSs remain impractical fully on-chain",
        "Still synchronous and round-robin; fully asynchronous ceremonies remain an open problem",
        "Limited deployment track record — treat as research-grade for now"
      ],
      "bestFit": "Projects where censorship-resistance of the ceremony itself is a stated requirement, or teams assessing where the field is heading.",
      "maintainers": "Academic authors (Powers-of-Tau to the People; a16z crypto research on-chain ceremony prototype)",
      "maturity": "Research with prototypes",
      "license": "Academic; see reference implementations",
      "source": "https://eprint.iacr.org/2022/1592",
      "facts": [],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "Powers-of-Tau to the People: decentralising setup ceremonies",
          "url": "https://eprint.iacr.org/2022/1592",
          "kind": "paper"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    }
  ]
}