What is a zero knowledge proof?

A zero knowledge proof is a cryptographic protocol that lets a prover convince a verifier that a statement is true without revealing why. In practice, ZK proofs are used to compress expensive computation offchain and verify the result onchain cheaply. The risks are subtle — a circuit that compiles is not necessarily a circuit that proves only true statements.

What is the difference between soundness and completeness bugs?

A soundness bug lets a prover construct a valid proof for a false statement — this is critical, because it breaks the security guarantee. A completeness bug means an honest prover cannot construct a proof for a true statement — this is a liveness issue. We classify soundness bugs as Critical or High depending on exploitability.

Which proving systems do you audit?

Groth16, PLONK and its variants (Halo2, UltraPLONK), STARKs, Plonky2, Risc Zero STARK-based systems, and the wrapping curves used to verify on Ethereum (BN254, BLS12-381). We have audited circuits in Circom, Halo2, Cairo, Noir, and Plonky2.

Do you audit the cryptographic primitives or assume they are correct?

We assume battle-tested primitives (BN254 pairing, BLS12-381, Poseidon over standard parameters) are correct as implemented in mature libraries. We audit your custom constraint system, your hash usage, and your domain separation. If you have rolled your own primitive, we will tell you to use a vetted library.

How is a ZK audit priced?

ZK audits start at US$150,000 and scale with circuit complexity. The first few days of an engagement often go to building the spec with you, because the spec is the contract we audit against.

Zero Knowledge Audit

A zero knowledge audit reviews the cryptographic constructions, the circuit implementation, the proving system integration, and the smart contracts that verify proofs onchain. We have audited circuits in Circom, Halo2, Cairo, Plonky2, and Noir, and the proving stacks for several Ethereum L2s. The output is a written report with findings classified by severity, plus reproductions where the soundness or completeness of a circuit is in question.

Request a scoping call

What we cover.

A zero knowledge audit covers the full ZK stack:

01

Circuit soundness. Can a malicious prover construct a valid proof for a statement that should not be provable? This is the most critical class of finding.
02

Circuit completeness. Can an honest prover always construct a proof for a true statement? Completeness bugs are liveness failures.
03

Constraint system correctness. Are constraints well-formed? Are public inputs constrained? Is every signal used? Is every signal constrained?
04

Hash and commitment usage. Domain separation, fixed-input length, padding correctness, choice of hash function over the field.
05

Trusted setup integrity. For Groth16 and similar systems, the setup ceremony and the way your project ingests the parameters.
06

Onchain verifier correctness. The Solidity (or other) verifier contract — the BN254 precompile usage, gas exhaustion vectors, replay protection, malleability.
07

Prover-verifier integration. The offchain prover service, witness generation, and the data flow from user input to onchain verification.

Our approach.

ZK audits start with a specification phase. The spec is the contract we audit against — a circuit cannot be audited without one, because we cannot tell you whether the constraints are correct unless we know what they are supposed to enforce.

If a spec exists, we review it. If a spec does not exist, we build one with the engineering team in week one of the engagement. This costs time but is the only way to do the work honestly.

We model soundness and completeness separately. For soundness, we attempt to find a witness that satisfies the constraints but corresponds to a false statement. For completeness, we attempt to find a true statement for which no satisfying witness exists in the field.

We assume battle-tested cryptographic primitives (BN254 pairing, BLS12-381, Poseidon over standard parameters) are correct as implemented in mature libraries. If you have rolled your own primitive, we will tell you to use a vetted library.

How we scope ZK audit work.

The specification is part of scope

A circuit can be internally consistent and still prove the wrong statement. That is why ZK review starts with the statement being proven, the public inputs, the witness data, and the exact security property the verifier relies on. If the statement is ambiguous, the audit starts by resolving the ambiguity.

A mature spec does not need to be long. It needs to be precise enough that an engineer can tell whether a constraint is missing, redundant, or enforcing a different property than intended.

Soundness and completeness fail differently

Soundness bugs let a malicious prover create a valid proof for a false statement. Completeness bugs stop an honest prover from proving a true statement. Both matter, but they create different production failures and different severity calls. We review them separately instead of folding them into a generic circuit-correctness category.

Verifier code is not boilerplate

Public input ordering, range assumptions, and domain separation.
Replay protection and proof binding to chain, contract, epoch, or message context.
Trusted setup handling, verifier key changes, and upgrade authority.
Gas, precompile usage, and failure behaviour under malformed proof data.

Related research and guidance.

Frequently asked questions.

What is a zero knowledge proof?

A zero knowledge proof is a cryptographic protocol that lets a prover convince a verifier that a statement is true without revealing why. In practice, ZK proofs are used to compress expensive computation offchain and verify the result onchain cheaply. The risks are subtle — a circuit that compiles is not necessarily a circuit that proves only true statements.
What is the difference between soundness and completeness bugs?

A soundness bug lets a prover construct a valid proof for a false statement — this is critical, because it breaks the security guarantee. A completeness bug means an honest prover cannot construct a proof for a true statement — this is a liveness issue. We classify soundness bugs as Critical or High depending on exploitability.
Which proving systems do you audit?

Groth16, PLONK and its variants (Halo2, UltraPLONK), STARKs, Plonky2, Risc Zero STARK-based systems, and the wrapping curves used to verify on Ethereum (BN254, BLS12-381). We have audited circuits in Circom, Halo2, Cairo, Noir, and Plonky2.
Do you audit the cryptographic primitives or assume they are correct?

We assume battle-tested primitives (BN254 pairing, BLS12-381, Poseidon over standard parameters) are correct as implemented in mature libraries. We audit your custom constraint system, your hash usage, and your domain separation. If you have rolled your own primitive, we will tell you to use a vetted library.
How is a ZK audit priced?

ZK audits start at US$150,000 and scale with circuit complexity. The first few days of an engagement often go to building the spec with you, because the spec is the contract we audit against.

Other engagements you might be considering.

Scope a zero knowledge audit.

Tell us about your circuits. We respond within two business days with a scoping call and a written engagement proposal.

Request a scoping call

Services

Products

Resources

Company

Social

contact@sigmaprime.io