Crypto Audit Firms: How to Pick the Right One
An audit is not a certificate; it is a time-boxed review by a specific set of humans against a specific commit. The name on the report matters far less than who was on the engagement, how long they had, and what you did with the findings. This page separates the review models, sets out how to prepare so the audit spends its hours on logic rather than on your formatting, and covers what to check in a quote.
Covered on this page (alphabetical, not ranked): Cantina, CertiK, Code4rena, ConsenSys Diligence, Halborn, OpenZeppelin, Quantstamp, Sigma Prime, Spearbit, Trail of Bits.
We have not audited these organisations, we publish no scores or price tables, and no placement on this page is paid for.
How the options differ
- Retained audit firms. A scheduled engagement with a named team and a formal report. Predictable, slow to book, and the standard for institutional diligence.
- Competitive audit contests. Many researchers review in parallel for a prize pool. Excellent breadth on well-specified code, noisier reports, and requires strong internal triage.
- Solo researchers and boutique teams. Deep expertise in one domain — AMMs, bridges, account abstraction. Often the best value if the domain matches.
- Continuous review and monitoring. Ongoing review plus runtime monitoring. Relevant once you are upgrading contracts in production.
What to verify before you commit
- Ask which named researchers will be on the engagement, and read their prior public reports.
- Confirm scope by commit hash, plus what happens to findings introduced after that commit.
- Agree the re-audit terms up front. Fixing findings creates new code; know what re-review costs before you start.
- Check severity methodology. Firms classify differently, and a wall of informational findings can hide one real issue.
- Plan to publish the report in full, including unfixed findings and your reasoning. Partial publication is a red flag to sophisticated readers.
Mistakes we see most often
- Booking an audit as a launch checkbox two weeks before TGE, when there is no time to fix anything.
- Sending unfrozen code, so half the budget is spent reviewing what you then rewrite.
- Treating the report as marketing and never fixing medium-severity findings.
What a good engagement timeline looks like
Work backwards from the date you need the report in hand. Reputable firms book weeks or months out, so the sequence is: freeze scope, book the slot, spend the intervening time on documentation and test coverage, deliver a frozen commit, then reserve calendar time after delivery for fixes and re-review. Teams that compress the last two steps are the ones who ship unfixed mediums.
Budget for the fix window explicitly. Findings arrive in a batch, and triaging, fixing, re-testing and re-reviewing them is real engineering work, not an afternoon.
Reading an audit report like a reviewer
Start at the scope section, not the summary. Check which files and which commit were reviewed, then compare that against what you actually deployed — a mismatch there invalidates everything downstream. Next read the acknowledged-and-not-fixed findings and your own responses to them; that section tells a sophisticated reader more about the team than the severity counts do.
Finally, look at whether the report describes the system's intended behaviour accurately. If the reviewers misunderstood a mechanism, they did not test it properly, and the absence of findings in that area means nothing.
Want help choosing?
We take no kickbacks from anyone named on this page. Book a 30-minute vendor selection call and we will work through which option fits your stage, budget and ecosystem.
🔗 Related reading from the Metamoonshots Journal
FAQ
How many audits do we need?
One thorough review by a team with domain expertise, plus a bug bounty in production, beats three rushed reviews. A second audit is justified for bridges, custody or anything holding significant third-party funds.
What should we do before the audit starts?
Freeze the code, write full natspec and a threat model, achieve high test coverage, and document intended behaviour for every privileged function. Every hour here buys several hours of reviewer attention on real logic.
Does an audit make us safe?
No. It reduces the probability of a known class of bug in reviewed code at one point in time. Monitoring, upgrade discipline and an incident plan carry the rest.
Does a bug bounty replace a second audit?
No, but it complements one well. A bounty gives you continuous adversarial attention in production, while an audit gives concentrated review before deployment. Most teams need both and the bounty scales better over time.
What if we upgrade contracts after the audit?
Any upgrade needs review of the changed code and its interactions. Agree a rate and turnaround for incremental reviews when you sign the original engagement, so post-launch changes do not stall.