Choosing a smart contract auditor is a procurement decision with an irreversible downside: once code is deployed and funded, a missed flaw cannot be patched quietly, and a weak engagement can cost far more than the audit fee. Teams face private audit firms, solo reviewers, competitive audit contests and formal verification specialists, with prices and timelines that vary by an order of magnitude. This vendor-neutral buyer's guide explains how to write requirements, compare engagement models, evaluate proposals, negotiate terms that protect you, and pay for re-audits sensibly. It is for protocol founders, engineering leads, security leads and the risk and treasury teams who sign off launches. Audit readiness, report triage and post-launch controls are covered in the Smart Contract Audit Readiness and Choosing an Auditor Guide; this page goes deeper on the buying decision.
Key takeaways
- Buy reviewer time on a frozen scope. An audit is a time-boxed review of a specific commit, not a certificate. Anything changed after that commit is unaudited code.
- Match the engagement model to risk. Private audits give named, accountable reviewers; competitive audits give breadth from many researchers; formal verification gives proofs of properties you specify. High-value protocols often need more than one.
- Judge auditors by evidence, not logos. Read their published reports on code like yours. Security Alliance (SEAL) guidance notes that comparing two firms that reviewed the same code at the same time is far fairer than comparing sequential audits.
- Fix review is part of the price. Agree the mitigation review window, re-review scope and final report in the contract, or you may pay twice.
- Price follows size, complexity and urgency. SEAL's rough industry estimates run from one to two weeks for under 1,000 lines to five weeks or more above 4,000 lines, at USD 1,000 to 60,000 per week. Treat quotes far outside the range with questions, not delight.
Define requirements
- Scope: exact repositories, contracts and commit hash; in-scope and out-of-scope files; libraries and inherited code; deployment and upgrade scripts; and whether off-chain components (keepers, oracles, front end, signing infrastructure) need a separate review.
- Protocol type and risk: lending, exchange, bridge, staking, L2, vault or token. Note total value expected at launch, upgradeability (proxy pattern), privileged roles and external dependencies such as oracles.
- Language and platform: Solidity, Vyper, Rust, Move or others, and the target chains. Reviewer experience must match.
- Assurance goals: which invariants must never break (for example, total supply equals the sum of balances, only the timelock can upgrade). These drive whether you need fuzzing or formal verification.
- Timeline: code freeze date, audit window, fix window, re-review and launch. Book early: reputable reviewers are often scheduled weeks ahead.
- Standards: whether findings should be mapped to the OWASP Smart Contract Top 10 or another checklist. See the OWASP Smart Contract Top 10 Guide.
- Publication: whether the final report will be public, which is common in web3, and who controls the wording.
Capability areas
| Engagement model | Best for | Limits |
|---|---|---|
| Private audit by a firm | Complex or high-value protocols needing named, accountable reviewers and direct communication | Higher cost; coverage depends on the specific people assigned |
| Solo or small independent reviewers | Small, well-tested codebases; a second opinion alongside a firm | Capacity and continuity risk; less formal process |
| Competitive audit (contest) | Breadth of perspective on code that is already reviewed and fixed; tens or hundreds of researchers compete for a prize pool | Code is exposed to many people before launch; less personalised; quality depends on participation and judging |
| Formal verification | Proving that critical invariants hold under every execution | Needs skilled specification writing and significant effort; a poor specification gives false confidence; some properties cannot be proved |
| Fuzzing and invariant testing engagements | Stress-testing state transitions and economic edge cases | Finds what the invariants describe; not a substitute for manual review |
| Bug bounty after launch | Continuous coverage once code is live. See the Bug Bounty and VDP Platform Buyers Guide | Pays for findings, not coverage; not a pre-launch substitute |
A common sequence for high-value code is a private audit to clear the bulk of issues, a competitive audit or second review on the fixed code, and a bounty at launch. Formal verification is usually targeted at the few properties whose failure would be catastrophic, such as accounting and access control, because ethereum.org notes it is more demanding and expensive than testing and audits.
Evaluation criteria
Weights are illustrative. A small token contract will weight price and speed higher; a bridge will weight depth and formal methods higher.
| Criterion | Weight | Evidence to request |
|---|---|---|
| Relevant published work | 20% | Two or three public reports on the same protocol type and language; read the findings, not the summary page |
| Named reviewers and time allocation | 20% | Names, roles and reviewer-days per person written into the proposal |
| Methodology | 15% | Manual review approach, static analysis, fuzzing, invariant testing, formal verification where proposed, threat modelling of privileged roles |
| Report quality and severity scheme | 10% | Sample report with proof of concept for high findings, clear severity definitions, actionable fixes |
| Fix review and re-audit terms | 10% | Included fix-review window, rules for what counts as a fix versus new code, re-audit pricing |
| Scope clarity and price | 10% | Price tied to defined files, lines and duration; change control for scope creep |
| Communication | 10% | Shared channel, response times, mid-engagement updates, walkthrough sessions |
| Operational security | 5% | How they handle your private repository access, confidentiality, and disclosure of critical issues found before launch |
Questions to ask vendors
- Who exactly will review our code, how many days each, and can we have that written into the contract with a substitution clause?
- Which comparable protocols have your proposed reviewers audited, and where are the public reports?
- How will you test our stated invariants: manual reasoning, fuzzing, formal verification or a mix? What will you not cover?
- How do you treat privileged roles, upgrade paths and deployment scripts? Are proxy initialisation and storage layout in scope?
- What is included in the fix review, how long is the window, and how do you price changes that go beyond fixes?
- For a competitive audit: how are findings judged and deduplicated, how is the prize pool split, and what confidentiality applies to participants?
- For formal verification: who writes the specification, how will we review it, and which properties will be proved versus only tested?
- What happens if you find a critical issue in code that is already deployed?
- Can we publish the final report, and do you require any wording or approval?
Red flags
- Guarantees: any promise to find all vulnerabilities or to make code "secure". SEAL lists this as a red flag.
- Very low price with vague scope: a quote that does not tie to lines, files and reviewer-days.
- Logos instead of reports: client lists with no readable findings.
- Bait and switch: senior staff on sales calls, no names in the contract.
- No fix review: a report with no re-review, leaving fixes unaudited.
- Badges and certificates: marketing that presents an audit as a permanent seal of safety.
Proof of concept
Few teams can trial an auditor on live code, but you can test fit before committing the full budget.
- Send a scoping pack to two or three shortlisted firms. Include architecture notes, the invariants list, line counts, test coverage and the target commit. Compare how each proposal reflects your real risks.
- Hold a technical scoping call. Ask each team to explain the attack paths they would look at first for your design. Weak answers here predict weak coverage.
- Read one recent report per firm closely. Check whether high findings include a proof of concept and whether fixes were re-reviewed.
- Consider a short paid pilot. For large programmes, commission a small, time-boxed review of one module before booking the main engagement.
- Freeze the commit and agree terms. Contract named reviewers, scope, fix window, re-review and publication rights.
- Measure the outcome. Track findings by severity, fixes verified, issues found later by others in audited scope, and time from report to launch. Use this to choose auditors next time.
How NHI Mgmt Group can help
We provide independent advice on web3 security, key management and identity for protocol teams and crypto businesses, including requirements and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Smart Contract Audit Readiness and Choosing an Auditor Guide · Smart Contract Security Guide · Formal Methods for Security Guide · Web3 Incident Response Playbook