Pick a smart contract audit firm by the fit of its reviewers to your code, then judge the result by the report, not the logo. Chainalysis counted more than $3.41 billion in crypto stolen from January to early December 2025, as reported by The Block. An audit lowers that risk only if it covers the exact code you deploy and the token model the board approved.
Who decides this
The CTO owns audit firm selection and the response to every finding, and is accountable to the board for both. The board should not pick the firm. It should ask the CTO three things before launch. Which commit was audited? Which findings remain open? Does the audited code match the approved token model?
What should we look for in a smart contract audit firm?
Choose the firm whose named reviewers have audited code like yours, in your language and your chain, within a timeline that lets you fix findings and have them re-checked. Brand matters less than that match. A strong team on unfamiliar code still misses things.
The market has no common standard for audit quality, pricing or severity labels. So compare firms on what you can verify yourself.
| Criterion | What to ask for | Why it matters |
|---|---|---|
| Relevant experience | Public reports on systems like yours, with the same language and chain | Domain gaps are where reviewers miss logic errors |
| Named reviewers and hours | Who reviews, for how many days, and whether they change mid-engagement | A short review window is a stated limitation in any report |
| Scope discipline | A fixed commit hash and file list agreed before kickoff | Code that moves during review is not fully reviewed |
| Fix review | Whether a round of fix review is included, and on what terms | A fix can introduce a new bug |
| Report quality | A sample report with full write-ups of high-severity issues | Copied tool output is a warning sign |
| Severity method | Which scale they use and how they rate impact and likelihood | Labels differ between firms |
| Publication | Whether the final report can be public and in what form | Exchanges and partners will ask to see it |
We do not rank firms here. The right one depends on your code base, and the reviewers on your engagement matter more than the firm's past work.
Plan the calendar before you sign. A slot that forces you to freeze code before it is ready is worse than a later one. Work back from the launch date. Leave time for the review, for your fixes, and for the auditor to check those fixes before anything is deployed. If the calendar cannot hold all three, move the launch, not the audit.
Should we buy a private audit, a competitive audit or a bug bounty?
Buy a private audit before launch, then add a competitive audit for complex or high-value code, then run a bug bounty once the code is live. They answer different questions at different times, and none replaces the others.
| Format | When it runs | Who reviews | How it pays | Main limit |
|---|---|---|---|---|
| Private audit | Before deployment, on a frozen commit | A small team from one firm | Fixed fee for the engagement | Bounded by that team's time and knowledge |
| Competitive audit contest | Before deployment, usually 1–3 weeks | Many independent reviewers, with judges ruling on severity | A prize pool shared by an awarding formula | Findings get public; quality of coverage varies |
| Bug bounty | After deployment, on live code | Anyone who reads the programme scope | Rewards per valid finding | Pays only after a bug exists in production |
Code4rena's competition documentation says its submission phase typically lasts one to three weeks. Judges then rule on validity and severity, and the report is usually published. Immunefi's bug bounty platform says more than $162 million in bounties is currently available on its platform. It also cites a single $10 million payout for one critical bug.
Our view: the private audit is the floor. Use a contest when the economic logic is novel or the value at risk is high. Size the bounty to make reporting a bug worth more than exploiting it.
How do we fix the scope so the report means something?
Agree a single commit hash and file list before the audit starts, and freeze it. OpenZeppelin's published audit process begins by confirming the exact codebase and commit hash so there are no last-minute changes. It then offers one round of fix review, provided each fix sits in its own pull request.
The scope also has to include the spec. Auditors check code against what you tell them the system should do. OpenZeppelin's preparation steps centre on architecture docs, usage scenarios and business logic. If those documents describe the wrong token model, the auditors check the wrong thing.
Then confirm what you deploy. ChainSecurity's guide to audit reports advises comparing the audited commit hash with the verified source of the deployed contract. Any mismatch means the report describes a different program. A report covers the version it reviewed, not whatever runs today.
How should the board read a smart contract audit report?
Read the scope page first, then the open findings, then the severity write-ups. The headline "no critical issues" is the least useful line in the document.
Severity labels describe impact, but each firm defines them its own way. OpenZeppelin uses Critical, High, Medium, Low and Informational. Immunefi's older severity classification puts bugs that empty or freeze a contract's holdings at Critical. It treats theft of yield or temporarily frozen transfers as High. ChainSecurity warns of "severity inflation", where minor issues are deliberately given a higher label.
The status of each finding matters more than its label. "Resolved" or "fixed" should mean the auditor reviewed and approved the fix. In most reports, "acknowledged" means the team chose not to fix it, for a stated reason. An acknowledged High finding is a risk the CTO has accepted for the board. That needs a written reason and a board-level sign-off.
Read the assumptions section too. Reports list what the auditors took as given: trusted admin keys, external oracles and dependencies treated as secure. Each assumption is a part of the system nobody reviewed. Many large losses start there, not in the audited code. Immunefi's Q1 2025 losses report traced most of that quarter's $1.64 billion in losses to two exchange incidents involving compromised wallets, not contract bugs.
When do we need a re-audit?
Re-audit any change to in-scope code after the audited commit, and any change to the token model the code enforces. That includes upgrades, parameter changes hard-coded into contracts, and new modules. As ChainSecurity puts it, even a small change can introduce a severe vulnerability.
Two audits of different commits do not add up to one audit of the final code. If a second firm reviews a later version, the first report says nothing about the changes. For upgradeable contracts, put a re-audit trigger in the change-management policy so the decision is not made under launch pressure.
What goes wrong: tokenomics the contractor rewrote
The board approves a token model: supply, allocations, vesting cliffs, emission schedule, treasury controls. A development contractor turns it into a spec and then into code. Along the way, a cliff becomes linear, an allocation moves between buckets, or a mint function keeps a role the board never agreed to. Nobody signs off on the change because nobody sees it as one.
The audit firm then checks the code against the contractor's spec. The code matches the spec. The report comes back clean. The board treats it as proof that the launch matches what it approved, and it is not.
The fix is a reconciliation step before the audit starts. Someone independent of the contractor maps every parameter in the approved model to the spec and to the contract. Our tokenomics design review guide, linked below, covers that check. Give the auditors the board-approved model as well as the spec, and ask them to flag any difference.
How Alcyone approaches it
Alcyone's partners do not sell audits. They coordinate them. Alcyone's quality and security review assesses contracts, applications and integrations, and coordinates security review with audit partners. Its launch-readiness checklist and sign-off is where we confirm that what went to the auditors matches the token model the board signed. The engagement starts with a fixed-scope, fixed-fee assessment credited against further work. The partners have commissioned audits of their own platforms: Team Finance counts 40,000+ projects using its locks, vesting, staking and airdrops, and their platforms span 27 blockchains.