How to Choose a Crypto Security Auditor

Picking a security auditor is one of the most consequential decisions a cryptography or smart-contract project makes. A good engagement catches the bug that would have drained the protocol. A poorly matched one produces a clean-looking report that misses the issue that actually mattered. This guide covers how to choose well, based on how strong reviews are staffed and run in practice.

The thing to get right is fit, because the bugs that matter cluster by domain. A team that lives in EVM smart contracts looks for reentrancy, broken access control, oracle and price manipulation, and rounding that rounds in the attacker’s favor. A zero-knowledge team looks for under-constrained circuits, missing range checks, nondeterministic witnesses, and a Fiat-Shamir transcript that lets a prover forge a proof. Those are different reading skills built on different mental models. A firm that is excellent at one can miss the other completely, and a general reputation does not close that gap. Fit is what catches bugs.

1. Define your scope before you talk to anyone

Before you ask for a single quote, write down three things.

• What you’re protecting. The value at risk, the adversary you assume, and what a worst case looks like. State the security goal in concrete terms: no loss of funds, censorship resistance, proof soundness, witness privacy. Each goal points the review in a different direction.
• The technology surface. Name the stack precisely. ZK circuits and the proving system (Halo2, Plonky2, Groth16, or a custom AIR). Smart contracts with the chains and languages (Solidity, Vyper, Move, Cairo, Rust on Solana). Consensus, bridge, or cross-chain message verification. A custom protocol or primitive. Off-chain components such as sequencers, provers, and keepers, which are often where the real trust sits.
• What has already been done. Internal review, prior audits, fuzzing, formal specs. Auditors plan and price very differently for greenfield code than for a well-tested second look.

A clear scope document is also the fastest way to find out whether a firm understands your system. Watch how precisely they respond to it, and whether they push back on the parts you left vague.

2. Match specialization to scope

Most security work here falls into a handful of deep specializations. The firms below are grouped by where they do their deepest work, not ranked. Filter to the sectors that match your scope, then build a shortlist.

A few patterns are worth knowing.

• Boutiques usually win on depth in a narrow domain and on having the senior people do the actual reading rather than hand off to juniors.
• Large firms bring breadth, the bench to staff a big scope, brand assurance for investors, and the ability to run several workstreams at once.
• Formal-verification teams prove a property holds for every input rather than sampling by hand for the inputs a reviewer happened to try. Use them when a specific invariant matters enough to want a machine-checked guarantee, and budget for the spec-writing time, which is where most of the work goes.

A rule of thumb. For cryptography-heavy code such as circuits, novel protocols, and primitives, lean toward specialists. For broad application code, a strong generalist or large firm is often the better fit. For the highest-stakes systems, use both, and have them review each other’s assumptions.

3. Check for real depth, not just the logo

Reputation is a starting filter, not the decision. Look for evidence that the specific people on your engagement can do your kind of work.

• Read their reports. Pull two or three past reports in your domain and read the findings, not the summary. You want issues that took understanding the system to find, not a list of generic items any tool would flag.
• Relevant prior work. Ask for references on projects similar to yours in technology, not just in name recognition. A famous DeFi audit tells you little about whether they can read your circuit.
• Who actually does the work. Will senior people review your code, or does the named expert close the deal and hand off? Ask for the names and backgrounds of the people who will be assigned.
• Methodology with teeth. Manual review, fuzzing, static analysis, and formal methods each catch different things. The signal is whether they can explain how they decide where to spend time on your codebase, and what they expect to be hard.

4. Questions to ask every candidate

• Who specifically will work on this, and what is their background in our exact domain?
• Walk us through a hard bug you found in a system like ours. How did you find it?
• What does your process look like for a system like this, and where do you expect the risk to concentrate?
• How do you handle findings during the engagement, continuous disclosure or one report at the end?
• How do you classify severity, and how do you handle a borderline case?
• What is your policy on re-reviewing fixes after we remediate?
• What are the limits of this engagement, and what will you not be checking?

The bug-walkthrough question is the most revealing. A team that reviews can tell the story of the reasoning. A team that scans will describe a tool’s output. The severity question matters too, because a clear rubric of impact against likelihood, with named thresholds, signals a team that has argued hard calls before.

5. How to read a quote

Compare proposals on more than price and calendar length.

• Effort, not just time. Two weeks with one person is very different from two weeks with three. Look at the person-weeks of senior time, which is the number that tracks coverage.
• Coverage against depth. A cheap quote that skims everything is usually worse than a focused, deep review of the components that can actually lose funds or break soundness. Decide which components actually hold value or carry the soundness of the system, and concentrate there.
• Deliverables. A report, a debrief, fix verification, and a public summary are different things. Confirm which are included, and whether the public summary needs your sign-off.
• Scheduling. The strongest teams book out months ahead. Plan around that, especially near a mainnet launch, when everyone is trying to book the same weeks.

6. After the engagement

The report is the start, not the end. Remediate, then get the fixes re-reviewed, because fixes are a common source of new bugs. A patch written under deadline pressure, against a finding the author may not fully understand, is exactly the kind of change that introduces a fresh issue. After that, think about standing coverage. An ongoing bug bounty or audit-competition harness watches the code after it ships and changes, which a point-in-time audit cannot.

See also: the pre-audit preparation checklist, which makes any engagement cheaper and more useful.