Noir
Noir security review
Noir is Aztec's language for writing zero-knowledge circuits. Hackerbane audits the circuits, the unconstrained functions, and the verifier that runs on-chain.
scope
What we review
We audit Noir circuits, the unconstrained functions that feed them, the standard-library hashes and Merkle helpers you call, and the on-chain verifier those circuits pair with. Typical issues are an unconstrained result that never gets an assert, a public input a caller can set, a leaked witness, and a verifier that does not match the nargo crate.
Unconstrained functions whose results never get an assert or range check.
Public inputs a caller can set to skip a required check.
Stdlib hashes and Merkle helpers used without the checks those calls need.
Witness values that leak through return values, logs, or public outputs.
A proving backend or on-chain verifier that does not match the nargo crate.
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 Noir review follows the same five-stage engagement as every Hackerbane audit. The work is a constraint review on nargo crates: we read each unconstrained function, check that every value it returns is later asserted, and follow the proof from witness generation to the verifier on-chain.
Two senior engineers read the crate in parallel and build it with nargo. We mark every unconstrained function, trace public inputs to the assert that should bind them, and compare the proving backend and verifier in the repo to the ones production runs.
Scope and threat model
We lock the crate, the commit, the proving backend, and the deployed verifier before the review starts, and name what the proof is supposed to guarantee.
Architecture and design review
We read the circuit against that model, separating what is constrained from what is only computed by an unconstrained helper.
Hybrid code and infrastructure review
Two senior engineers read the Noir in parallel, build with nargo, and run a constraint review across unconstrained results and public inputs.
Exploitability and root-cause analysis
Soundness findings ship with an input that satisfies the circuit but should not, and the root cause, so the missing constraint is fixed, not only the symptom.
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 crate you already build. nargo stays as it is; we review unconstrained functions and stdlib calls, then check the generated verifier against the one on-chain.
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.
Notes from the review: unconstrained functions, stdlib calls, and how the backend lines up with the verifier.
How to prepare
| # | Before review starts |
|---|---|
| 01 | nargo builds and tests run cleanly from a fresh checkout. |
| 02 | The proving backend and on-chain verifier versions are pinned and written down. |
| 03 | Unconstrained functions are listed, and each one says what assert is supposed to follow it. |
| 04 | Public and private inputs are labelled, with known limitations noted. |
| 05 | Scope is defined: which crate, which commit, and which verifier. |
Other pages
Questions
- Does an unconstrained function make my circuit unsound?
- Only if you treat its result as proven. Unconstrained code generates a witness. The circuit is sound only if a later assert or range check binds that witness. We flag every place that check is missing.
- Do you review the stdlib and the on-chain verifier?
- Yes. We read how you call stdlib hashes and Merkle helpers, and we compare the verifier you deploy to the one nargo generated for this crate.
- Is a green nargo test enough?
- No. Tests run the program. They do not prove every witness is constrained. We check unconstrained functions, public inputs, and the verifier on-chain.
Next step
Request an audit
Send the Noir crate, the proving backend (the system that generates the proof), and the verifier in production. We will propose an audit plan and estimate. If it already builds with nargo, send it as it is.