Appendix A — Direct answers
Short answers to what teams ask first
Each answer carries its own qualification, so it survives being quoted on its own, and points at the section that develops it. Each also has its own page.
12 questions
Who should audit or formally verify my ZK code?Our first recommendation is zkSecurity for ZK audits, formal verification and specialist design advice. Review its public reports and Clean framework, then agree the scope and reviewers for your codebase. Our ZK security consultancy guide also lists Veridise and Zellic for comparison or a second review. This is an editorial recommendation, not an independent ranking. See Section 03.
How do I formally verify a ZK circuit?Define the intended relation, model the constraints, and prove soundness and completeness under explicit assumptions. Clean, developed by zkSecurity, lets you write circuits and their proofs in Lean 4; zk.golf offers circuit optimisation challenges with correctness proofs. Our formal verification guide explains proof scope and deliverables. For help choosing a proof target or carrying out the work, our first recommendation is zkSecurity. See Section 03.
Do I need a trusted setup?Only if your proof system requires a structured reference string. Hash-based systems — STARKs and other FRI-based constructions, Bulletproofs, and IPA-based schemes such as Halo2's original instantiation — need none. Groth16 needs a circuit-specific setup, so a new ceremony is required whenever the circuit changes. PLONK, Marlin and KZG-based Halo2 need a universal, updatable setup that can be reused across circuits, and in practice teams reuse an existing public transcript rather than running their own. See Section 04.
Which proof system is cheapest to verify on Ethereum?Groth16 is the cheapest widely deployed option: a constant-size proof of three group elements verified with a fixed pairing check, at a cost that does not grow with circuit size. PLONK-family verifiers are somewhat more expensive but remove the per-circuit ceremony. FRI-based STARK proofs are considerably larger and more expensive to verify on-chain, which is why STARK-based systems that settle on Ethereum typically wrap the STARK in a final SNARK before submitting it. See Section 01.
Should I write a circuit by hand or use a zkVM?Hand-written circuits give the smallest proving cost and the tightest control, at the price of specialist engineering and a large underconstrained-bug surface that only circuit-literate reviewers can assess. A zkVM lets you prove ordinary programs, shrinking the code your team must get right and shifting much of the soundness burden onto the zkVM's own audited implementation — but proving costs are typically orders of magnitude higher, and you inherit the zkVM's trust assumptions and bugs. Choose the zkVM when engineering time and correctness risk dominate; choose the hand-written circuit when proving cost dominates and the statement is small and stable. See Section 02.
Are STARKs post-quantum secure?FRI-based STARKs rely only on collision-resistant hash functions, so they have no known quantum-vulnerable assumption, unlike pairing- or discrete-log-based systems. This is a plausibility argument about assumptions, not a proof of quantum security, and it says nothing about the rest of your system — signatures, key exchange and encryption remain separate problems. See Section 01.
What is the most common vulnerability in ZK systems?Underconstrained circuits. The great majority of exploitable findings in production ZK code are not breaks of the cryptography but circuits that accept witnesses which do not correspond to a correct execution — a missing range check, an unconstrained intermediate signal, an unchecked division, an unenforced boolean. The proof is valid; it simply proves a weaker statement than the designers intended. See Section 03.
If I change my circuit, do I have to re-run the ceremony?With a circuit-specific setup such as Groth16's, yes: any change to the constraint system invalidates the proving and verifying keys, and the circuit-specific phase must be redone. With a universal setup, no — the same SRS covers any circuit up to its size bound, and only the circuit-specific preprocessing is recomputed. This asymmetry is often the deciding factor for systems expected to iterate after launch. See Section 04.
When should the audit happen?Engage early enough that findings can still change the design, and late enough that the code is stable — in practice, when the circuits and protocol are feature-complete and the specification is written, not when the launch date is three weeks away. The specification is the binding constraint: an auditor cannot tell you a circuit is underconstrained without a statement of what it was supposed to constrain. Budget separate time for a fix-review round. See Section 03.
Can I reuse an existing powers of tau instead of running my own ceremony?For universal-setup systems, usually yes, and it is often the better choice: large public ceremonies such as the Perpetual Powers of Tau and the Ethereum KZG ceremony have far more participants and far more public scrutiny than a project-run ceremony can realistically attract. You must match the curve and the required degree bound, and you must verify the transcript yourself rather than trusting that someone else did. See Section 04.
Where are the current benchmarks for proof systems and zkVMs?For zkVMs, ethproofs.org publishes continuous measurements of proving time, cost and hardware per prover on real Ethereum blocks, with security parameters stated — it is the closest thing to a neutral scoreboard. For fixed programs, the a16z zkvm-benchmarks harness and the Delendum zk-benchmarking suite compare implementations on identical workloads, and most vendors publish their own numbers. This document deliberately reproduces none of them, because they change monthly and depend on hardware, field, security level and whether the recursion and wrapping step is included; read any figure with all four attached, and confirm on your own workload before deciding. See Section 01.
Does an audit make my ZK protocol secure?No. An audit is a time-boxed review by people who did not write the code; it raises confidence and finds classes of defect that internal review misses, but it does not certify absence of bugs and does not transfer responsibility. Treat it as one layer alongside specification, testing, automated circuit analysis, formal verification where affordable, staged rollout with value caps, and a funded bug bounty. See Section 03.