The right auditor for a Solidity lending market may be the wrong one for a Move-based asset system or a zero-knowledge bridge. This checklist helps protocol teams compare providers on the things that actually change the outcome of an audit.
Start From Your Architecture, Not a Brand List
Most teams begin with a list of well-known names. A better starting point is a short description of what you are building: the language and chain, the protocol category, the external integrations, the privileged roles, and the value the system will hold at launch. That description tells you which experience actually matters.
A Solidity lending market needs researchers who understand liquidations, oracle risk, and interest accounting. A Rust or Move program needs people fluent in that execution model. A bridge needs cross-chain messaging experience, and a zero-knowledge system needs circuit and cryptography expertise. A provider can be excellent and still be the wrong fit for your stack.
Ask Who Will Actually Review Your Code
The audit is performed by people, not by the logo on the report. Ask for the researchers who will be assigned, what they have reviewed before, and what evidence shows they find serious issues. Public results from audit contests and bug bounties, published reports, and judged findings are stronger evidence than generic team descriptions.
Also ask how many researchers will work on the code and for how long. Researcher time relative to code size and complexity is one of the clearest indicators of review depth. You can read how Kann Audits selects its researchers for an example of an explicit, verifiable bar.
The Evaluation Checklist
Use the same questions for every provider on your shortlist so their answers are comparable.
| Criterion | What to ask | What a strong answer looks like |
|---|---|---|
| Researcher fit | Who is assigned and what have they found before? | Named researchers with relevant, verifiable results |
| Coverage | How many researcher-days for this scope? | An estimate derived from your code, not a template |
| Methodology | How is the review performed? | Manual line-by-line review, threat modeling, and testing, with tools as support |
| Track record | Which reports are published? | Reports with scope, commit, evidence, and final statuses |
| Communication | How do we talk during the review? | A shared channel and findings shared as they are validated |
| Remediation | Is fix verification included? | Every fix re-checked and statuses recorded in the final report |
| Timeline | When can you start and finish? | A schedule that leaves time to fix before launch |
Read Their Published Reports
Published reports are the best preview of what you will receive. Look for an exact commit and file list, a clear methodology, findings that explain impact and include proof or a reproduction path, recommendations that address root causes, and statuses that show what happened after the fixes. Compare reports on protocols similar to yours.
Be cautious with counts alone. A report with many low-severity notes can look busy while missing the logic issues that matter, and a short report on a small, well-tested codebase can be excellent. Quality is in the reasoning, not the number of entries. Our own published audit reports are open for exactly this kind of review.
Red Flags When Comparing Auditors
Some warning signs show up repeatedly when teams later regret their choice of provider.
No honest auditor can guarantee that a protocol is free of vulnerabilities. A guarantee is a reason to ask more questions, not fewer.
- A quote or timeline given before anyone has looked at the code.
- No clear answer about who will review the code or how much time they will spend.
- Guarantees that the code will be secure or bug-free after the audit.
- Reports dominated by automated tool output with little manual analysis.
- No fix verification step, so nobody checks whether the fixes actually work.
- Unwillingness to share published reports or references from similar projects.
Weigh Price and Timing Last
Price matters, but only after you know what each quote buys. Two quotes for the same codebase can differ because of researcher seniority, the number of researcher-days, whether fix verification is included, or how much of the system is actually in scope. Normalize the quotes before comparing them. Our audit cost guide explains the main pricing drivers.
Timing is often the real constraint. Experienced teams book ahead, and a good engagement needs time after the review for remediation and fix verification. Reach out before code freeze, and avoid choosing a provider only because they can start tomorrow.
A Simple Selection Process
Most teams can make a well-informed decision in a few steps, and the same process works for later upgrades.
Compare Providers Side by Side
If you want a starting shortlist, our comparison of the best Web3 security audit firms in 2026 profiles ten providers, their audit models, and the situations each is best suited to. Use it alongside the checklist above, because the best provider is always the one that fits your system.
Questions About Choosing an Auditor
Short answers to the questions teams ask while comparing smart contract audit providers.
How do I choose a smart contract auditor?
Start from your architecture and risk, not from a brand list. Shortlist providers whose researchers have relevant experience in your language and protocol type, read their published reports, ask who exactly will review your code, and compare scope, timeline, communication, and fix verification before comparing price.
What should I ask a smart contract audit firm before hiring them?
Ask who will be assigned and what they have found before, how many researchers will work on the code and for how long, how findings are communicated during the review, whether fix verification is included, what the report will contain, and how the quote was derived from your codebase.
Is the cheapest smart contract audit good enough?
Sometimes, for a small and simple codebase reviewed by experienced researchers. A quote that is far below others for the same scope usually means fewer researcher hours, less experienced researchers, or a narrower review than you expect. Compare what is being reviewed and by whom, not only the total.
Should I use a private audit or an audit contest?
A private audit gives you assigned researchers, direct communication, and remediation support. A contest adds broad independent coverage from many researchers. Many teams use a private audit first and a contest or bug bounty afterward for high-value launches.
How far in advance should I book a smart contract audit?
As early as you can define the scope. Experienced teams are often booked weeks ahead, and the schedule also needs room for remediation and fix verification before launch. Contacting providers before code freeze gives you more choice.
Do I need more than one audit?
For high-value or complex systems, often yes. Independent reviews by different teams find different issues, and every significant upgrade or new integration changes the code that was originally reviewed.
Primary references