Sample audit report: see how a Hackerbane report is structured. Open the report →

Circom

Circom security review

Circom is a language for writing zero-knowledge circuits: programs that prove a fact without revealing the secret inputs. Hackerbane audits those circuits and the verifier they pair with.

What we review

We audit Circom templates and the on-chain verifier they pair with. Typical issues are a missing constraint, a missing range check, a public input a user can set, a witness that never becomes a constraint, and a verifier left over from an older compile.

  1. Under-constrained signals a prover can set because nothing binds them.

  2. Missing range checks on values that must be bits, amounts, or indices, not arbitrary field elements.

  3. Public inputs a user can set to skip a check the circuit assumed.

  4. Witness values computed out of circuit, or with a hint, and never constrained.

  5. Verifier contracts that pair with a different circuit or keys than the repo builds.

Advanced Threat Detection

We built our own advanced threat detection stack that is more performant and cheaper than our competitors. We use a state-of-the-art AI harness coupled with world-class senior security engineers with proven experience finding vulnerabilities in well-tested software.

How we review this language

A Circom review follows the same five-stage engagement as every Hackerbane audit. The difference is the constraint system: which signals are bound, which are only hinted, and whether the verifier contract pairs with the circuit you shipped.

Two senior engineers read the templates in parallel, rebuild them, and check each signal against the constraints that should bind it. We compare the deployed verifier and its keys to the circuit in the repo. A passing test only shows one witness. It does not show every signal is bound.

  1. Scope and threat model

    We lock the circuits, the commit, the trusted setup, and the deployed verifier before the review starts, and name what the proof is supposed to guarantee.

  2. Architecture and design review

    We read the constraint system as a whole against that model, because the soundness flaws live between signals, not inside one line.

  3. Hybrid code and infrastructure review

    Two senior engineers read the Circom in parallel, rebuild it, and run a constraint review across every signal alongside a verifier check.

  4. Exploitability and root-cause analysis

    Soundness findings ship with a witness that satisfies the circuit but should not, and the root cause, so the missing constraint is fixed, not only the symptom.

  5. Reporting and remediation

    A prioritized report, a live walkthrough, and verification of every in-scope fix within the remediation window.

Tools and practices

We work from the Circom sources you already compile. We add a constraint review across every signal, a check that the verifier contract pairs with that circuit, and a look at the trusted setup the deployment relies on.

What you get

  • Prioritized findings your engineers can ship against, each with root cause and a recommended fix.

  • Verifiable proofs of concept for High and Critical soundness issues where one can be built.

  • A report you can share with partners, exchanges, investors, and regulators.

  • Remediation verification and a final report that reflects the fixed state of the circuit.

  • The constraint review notes and verifier pairing checks used during the audit.

How to prepare

What we need before the engagement starts.
#Before review starts
01Builds and tests run cleanly from a fresh checkout, with pinned circom and snarkjs versions.
02The trusted setup or ceremony and its outputs are documented.
03The deployed verifier address and its keys are provided.
04Public and private signals are labelled, and known limitations are written down.
05Scope is defined: which circuits, which commit, and which verifier.

Questions

Is a passing test suite enough for a circuit?
No. A test picks one witness. A prover can still set an under-constrained signal to something else and get a valid proof. We read the constraints, not only the witness your tests already chose.
Do you review the trusted setup too?
Yes, when the proof depends on it. We look at the ceremony and its outputs alongside the circuit.
What if the verifier contract does not pair with the circuit we shipped?
We compare the deployed verifier and its keys to the circuit you compile. If they do not match, production is checking a different statement than the one you tested.

Next step

Request an audit

Share the Circom sources, the trusted setup (the ceremony that created the proving and verifying keys), and the verifier in production. We will propose an audit plan and estimate. circom and snarkjs projects can come as they are.