To choose a smart contract auditor, look for public reports on code similar to yours (same chain, same kind of project), a documented methodology, named reviewers who will actually read your code, a clear re-audit policy and complete independence from your developer. Reputation and price matter, but they come after fit. The best auditor for a lending protocol on an EVM chain is not necessarily the best one for a Move token or a Rust program on Solana. This guide gives you the criteria, the questions to ask and the warning signs to watch for.
What matters most when choosing an auditor
The single most important factor is relevant experience: an auditor who has already reviewed code like yours, on your chain, will know where that kind of code usually breaks. A reviewer fluent in Solidity DeFi patterns may miss issues specific to Solana account validation, and the reverse is also true.
Keep in mind what an audit is and is not. It is a time-boxed expert review of a precise version of your code, which reduces risk and documents it. It does not guarantee the absence of bugs. Choosing well therefore means choosing the reviewers most likely to find what matters in the time you are paying for, and a report you can act on.
"Best smart contract auditors" rankings are of limited use for this reason. A useful shortlist is specific to your project: three to five auditors whose past work matches your language, your project type and your size.
The criteria to check
Evaluate each candidate on the same seven criteria, and ask for evidence rather than claims.
1. Relevant public reports
Ask for two or three public reports on projects comparable to yours: same chain or language, same project type (token, NFT, staking, DeFi, bridge, tokenization), similar size. Read them. A good report explains the scope, describes each finding clearly, rates its severity, proposes a fix and records whether the fix was verified. A long list of informational notes with few substantive findings is not, by itself, a sign of quality.
2. Methodology
A credible auditor can describe how the review is done: manual line-by-line review, threat modeling of the protocol's economic logic, automated tools such as static analysis, and where relevant fuzzing, invariant testing or formal verification. Ask what is manual and what is automated. Tools are useful, but they do not replace a reviewer who understands your business logic.
3. The team who actually reviews
Ask for the names and backgrounds of the people who will read your code, and how many auditor-days each will spend. Some organizations sell under a senior name and staff the work with juniors. Two reviewers working independently usually catch more than one reviewer working twice as long.
4. Availability and timing
Confirm the start date, the duration and the date the report will be delivered. Many auditors are booked weeks ahead. The site's indicative model applies an urgency surcharge (x1.25 to start within two weeks, x1.5 within a week), so planning early often saves money as well as stress.
5. Re-audit terms
The re-audit is the auditor's verification of your developer's fixes. Ask whether it is included, how many rounds, within what time window, and what happens if fixes introduce new code. In the site's indicative model, a re-audit costs about 20% of the first audit price when it is not included.
6. Report format and severity scale
Ask for a sample report and the severity scale used (for example critical, high, medium, low, informational), with the definition of each level. You need findings that your developer can reproduce, ideally with a proof of concept, and a final report that references the exact commit reviewed.
7. Independence from the developer
The auditor must have no stake in the code: no development work on the same project, no shared ownership with the developer, no commission paid by the developer. An auditor reviewing its own team's code, or a partner's, has an obvious conflict of interest. This point is covered in detail in the guide on developer and auditor independence.
Questions to ask before signing
Send the same written questions to every candidate so that answers are comparable.
- Which public reports of yours are closest to our project, and what did you find?
- Who exactly will review the code, and how many days will each person spend on it?
- What is your methodology, and which parts are manual?
- What do you need from us before the start (frozen commit, documentation, tests, deployment scripts)?
- What is the exact scope: which files, which commit, what is out of scope?
- Is the re-audit included? How many rounds and within what time frame?
- What severity scale do you use, and can we see a sample report?
- Will the final report be public, and can we publish it ourselves?
- Do you have, or have you had, any relationship with our developer?
- How do you communicate during the review, and how are critical findings reported?
Clear, specific answers are a good sign. Vague answers on scope, team or re-audit usually lead to disagreements later.
Red flags
Some warning signs justify removing a candidate from your shortlist.
- No public reports, or reports that cannot be linked to real reviews.
- A fixed price without reading the code or at least counting its size. Effort depends on the number of lines, the language and the complexity.
- A duration that does not match the scope: a few days for a large DeFi codebase should raise questions.
- Unnamed reviewers, or a refusal to say who will do the work.
- Promises of security, such as "bug-free" or "guaranteed safe". No honest auditor makes them.
- A report delivered without a commit reference, which makes it impossible to know what was actually reviewed.
- Any link with the developer: same group, revenue sharing, or an offer to "audit what we built".
- Pressure to skip preparation, such as starting before the code is frozen.
One flag is not always disqualifying, but it deserves a direct question and a written answer.
Independent auditors, firms, audit contests and bug bounties
These options are complementary, not substitutes: each one covers a different need at a different moment.
| Option | What you get | Best suited for | Limits |
|---|---|---|---|
| Independent auditor or boutique | One to a few senior reviewers, direct contact | Small to mid-size scopes, tight budgets, specialist chains | Limited capacity, fewer parallel reviewers |
| Established audit firm | Several reviewers, internal quality review, recognized report | Large or high-value protocols, investor or listing requirements | Higher price, longer booking lead time |
| Audit contest | Many reviewers in parallel for a fixed period | Additional coverage after a private audit | Variable quality, heavy triage, less dialogue |
| Bug bounty | Ongoing incentive to report issues after launch | Deployed code, continuous protection | Not a review of the code before deployment |
In the site's indicative model, independent auditors and boutiques typically charge 800 to 1,400 EUR per auditor-day and cover about 350 nSLOC per day, while established firms charge 1,800 to 3,500 EUR and cover about 250 nSLOC per day with deeper review. For a 1,500 nSLOC DeFi codebase in Solidity, that gives indicative ranges of 4,800 to 8,400 EUR (independent) and 15,000 to 30,000 EUR (established). Real quotes depend on your scope, and you can estimate yours with the audit cost calculator.
A common sequence for a significant protocol is a private audit, fixes and re-audit, then optionally an audit contest for additional coverage, and a bug bounty from launch. A small token may only need one independent review. What matters is that each step is chosen for a reason, not stacked for appearance.
How to make the final choice
Compare the shortlisted auditors on the same basis: same scope, same commit, same questions. Then weigh relevant experience and the quality of sample reports first, the named team and methodology second, and price and availability third.
If two candidates are close, a short call with the lead reviewer is often decisive: a good reviewer will quickly ask pointed questions about your architecture, your assumptions and your threat model. Platforms such as smart-contract.com enforce independence in their database, so a company engaged to develop your project cannot be invited to audit it, but you should check this point yourself whatever channel you use.
Finally, put the key terms in writing: scope and commit, reviewers, dates, deliverables, severity scale, re-audit rounds and publication rights.
Key takeaways
- Choose on fit first: public reports on the same chain and project type matter more than general reputation.
- Ask who will actually review the code, for how many days, with what methodology, and get the answers in writing.
- Clarify re-audit terms and the report format, including the severity scale and the commit reference, before signing.
- Treat any link between auditor and developer as disqualifying: independence is a condition, not a bonus.
- Private audits, audit contests and bug bounties are complementary, and none of them guarantees the absence of bugs.