Before a book that names real people goes to print, the publisher sends it for a legal read. A media lawyer takes one specific proof, marks every passage that could draw a claim, and grades how worried to be about each one. The author rewrites. The lawyer reads the rewrites. Then the lawyer signs off on that proof.
Everyone in publishing knows what the sign-off does not cover: the paragraph the author slipped in the night before it went to the printer.
A smart contract audit runs the same way, step for step, and it has the same edge. Each step below covers what happens, what your team does during it and what comes out.
Quick Answer
A smart contract audit runs in eight steps: scoping, a code freeze on one commit, automated analysis, manual review, findings rated by severity, remediation by your team, a fix review, and the final report. The report covers the frozen commit and the fixes checked against it. The next change you merge sits outside it.
The eight steps at a glance
| Step | What happens | What your team does | What comes out |
|---|---|---|---|
| 1. Scoping | The auditor reads the repository and agrees what is in and out | Names the contracts, shares docs and tests | A scope, a price and a start date |
| 2. Code freeze | One commit is fixed as the audit target | Stops changing the files in scope | A commit hash that goes in the report |
| 3. Automated analysis | Static analysis and detectors run across the code | Answers build and setup questions | Leads for the reviewers, not yet findings |
| 4. Manual review | Line-by-line reading of logic and economics | Stays reachable for questions | Findings, with critical ones flagged early |
| 5. Findings and severity | Each finding is written up and rated | Reads the draft report and triages | A draft report |
| 6. Remediation | Your team fixes what it chooses to fix | Ships one change per finding | Fix commits |
| 7. Fix review | The auditor checks each fix against its finding | Answers follow-up questions | A status on every finding |
| 8. Final report | The report is finalised and, usually, published | Publishes and links it | The report, and at Fidesium a badge and an on-chain NFT record |
1. Scoping: deciding what is actually being audited
Scope is a list of files at a version. Everything else follows from it: the price, the date, and what the report can honestly claim.
A good scoping conversation names what is out as clearly as what is in. Forked code, external dependencies, deployment scripts and off-chain services are the usual grey areas. If a contract is out of scope, a bug in it is out of the report, however obvious it looks afterwards.
At Fidesium, scoping starts from the shape of the protocol. On our Adrena engagement, that meant classifying every one of the program’s 122 instructions by who can call it: admin, gated user or anyone. Permissionless instructions are where attackers start, so they get the most attention. You can start the same conversation for your own codebase on the manual audit page.
2. Code freeze: one commit, written down
The auditor needs code that stops moving. So the audit target is pinned to a single commit hash, and that hash is printed in the report. OpenZeppelin describes the same step as confirming “the exact version of the code to audit, avoiding last-minute changes.”
Your team keeps working during a freeze, in a branch. Nothing lands in the audited files until the review is done.
The week before the freeze is the cheapest week of the whole audit. Trail of Bits’ preparation guide says to treat the audit team as “newly hired, fully remote developers” who know nothing about your product. Its checklist is still the right one:
- Fix every compiler warning.
- Delete dead code, stale branches and unused libraries.
- Write down what the protocol is meant to do, in plain language.
- Make the tests run from a clean checkout, with instructions.
- Hand over earlier audit reports and past security bugs.
Every hour an auditor spends working out how to build your code is an hour not spent attacking it.
3. Automated analysis: clearing the mechanical ground
Before anyone reads the business logic, tools run across the code. Static analysers such as Slither, a static analysis framework for Solidity and Vyper, run “a suite of vulnerability detectors” and flag known patterns: reentrancy, unchecked low-level calls, shadowed state variables, a delegatecall whose target a caller controls.
What comes out is a list of leads for the reviewers. Each lead gets triaged, and false positives are thrown away before anything reaches a report.
Fidesium runs this step on its own deterministic tooling, built on static and AST (abstract syntax tree) analysis. The same code gives the same result every time, which matters when you later want to know whether a change introduced something new. For how the common tools compare, see our guide to Solidity static analysis tools.
4. Manual review: where the expensive bugs are found
Tools find patterns. They do not know what your protocol is supposed to do, and most serious losses come from code that runs exactly as written and still does the wrong thing. We made that point in our post on formal analysis for founders: the logic behaves correctly according to the code and incorrectly according to the business intent.
So the core of the audit is people reading code line by line. They trace how value moves, who can call what, and which assumptions hold only under normal market conditions. OpenZeppelin, for one, puts at least two auditors on the same codebase, and flags critical issues to the client as soon as they are found rather than waiting for the report.
On Adrena, a Solana perpetuals exchange, our review ran in four passes before the bug hunt proper:
- Protocol mapping: every instruction classified by who can invoke it.
- Token flow diagrams: every path value takes through the protocol, written down as conservation rules.
- Cross-program invocation (CPI) analysis, with the oracle integrations as their own sub-pass.
- Cross-verification: do the two sides of every calculation actually match?
The conservation rules from pass 2 became the properties the fuzzers checked later. That is the difference between hoping to stumble on a bug and checking the rules the system is meant to obey.
5. Findings and severity: how bad is each one?
Every finding is written up with its location, what an attacker could do, how likely that is, and a recommended fix. Then it gets a severity rating, and this is where reports are easy to misread, because firms do not use the same scale.
| Who | Scale | What the top level means |
|---|---|---|
| OpenZeppelin audits | Critical, High, Medium, Low, Informational | Five levels, with Low and Informational used for code-quality suggestions |
| Immunefi bug bounties | Critical, High, Medium, Low | A four-level scale defined by impact |
| Code4rena audit contests | High, Medium, QA | High: “Assets can be stolen/lost/compromised directly” |
A Medium on one scale can be a High on another. When you compare two reports, or two firms, compare the definitions, not the labels.
Severity measures impact on the protocol as a whole, and that includes who controls it. On Adrena the review raised one Critical, three High and eight Medium findings. The single Critical was a governance issue, a missing timelock on admin operations, rather than a solvency bug.
6. Remediation: your team fixes, one change per finding
Now the work moves back to you. Your team reads the draft report, agrees or disputes each finding, and fixes what it decides to fix.
Keep each fix small and separate. OpenZeppelin asks for every fix in its own pull request, and the reason is practical: a fix is new code. It can introduce a new bug, and a fix buried in a large refactor is hard to check.
You do not have to fix everything. A Low you consider an accepted risk can stay, and the report will record it as acknowledged rather than resolved. What you should not do is merge unrelated feature work into the audited files at the same time.
7. Fix review: checking the fixes, and only the fixes
The auditor re-reads the code at the new commit and gives every finding a status, typically resolved, partially resolved or acknowledged. How many rounds are included varies by firm. OpenZeppelin includes one. Fidesium’s manual audits include two rounds of fix verification. It is worth asking before you sign, along with the other questions in our shortlist of smart contract audit firms.
The weakest fix reviews are a second reading of a prose paragraph. On Adrena every finding produced at least one runnable test, so fix review became mechanical: does the test that failed before now pass? Those tests stay in the codebase afterwards, so a later refactor that reintroduces the bug fails the test suite.
8. The final report: what it covers, and what it does not
The final report lists the scope, the commit hashes reviewed, the method, and every finding with its severity and final status. Many teams publish it, because investors and exchanges often ask to see it.
Fidesium publishes each report with a badge and mints it as an on-chain NFT, so anyone can verify which code was reviewed and when. You can read 23 public reports across 16 protocols, each with its findings and remediation record intact.
Read any report for what it actually says. It says that named files, at named commits, were reviewed by a named team, and here is what they found. It does not say the contract is safe.
The step most process guides leave out: the next commit
The process guides that rank for this topic end at the report. Chainlink’s list stops at “Publish Final Audit Report”. OpenZeppelin’s stops at final delivery and optional publication.
Your code does not stop there. You ship an upgrade, change a parameter, add an integration. The report still names the old commit, like the legal read that covers the proof and not the paragraph added afterwards. Adrena knew this: when its own code moved through the v38 to v39 migration, it commissioned a follow-on review.
That is why we say security is a process. Fidesium re-runs audit-grade analysis on every commit and pull request, and every manual audit includes a month of continuous scanning after launch. For how quickly an audit’s reasoning goes stale, read when a smart contract audit actually expires. For what scanning and monitoring each catch, read continuous monitoring vs one-time audits, and see our security services for monitoring after launch.
Frequently asked questions
How long does a smart contract audit take?
It depends on how much code is in scope and how complex it is, so a firm should give you a date at scoping, against a frozen commit. Plan for more than the review itself: your team’s remediation and the fix review after it are part of the calendar, and a launch date that assumes zero findings is the one that slips.
What does a code freeze mean in a smart contract audit?
It means the audit targets one specific commit, and that commit hash is printed in the report. Your team can keep working in a branch, but nothing should land in the audited files until the review is finished. Code merged after the freeze is not covered by the report.
Do auditors use automated tools or read the code by hand?
Both. Automated analysis runs first and clears the known patterns quickly, such as reentrancy and unchecked calls. Manual review is where logic and economic bugs are found, because a tool cannot know what the protocol is meant to do. An audit that is only a scan is a scan.
How are smart contract audit findings rated?
Each finding gets a severity, usually from Critical down to Low or Informational, based on impact and likelihood. Scales differ: Code4rena uses High, Medium and QA, Immunefi uses four levels, and OpenZeppelin uses five. Before comparing two reports, check what each firm means by each level.
What is a fix review?
After your team fixes the findings, the auditor checks each fix against the finding it addresses and records a status: resolved, partially resolved or acknowledged. The number of rounds included varies by firm. Fidesium’s manual audits include two.
What should I prepare before a smart contract audit?
Fix every compiler warning, delete dead code and unused libraries, write down in plain language what the protocol should do, make the tests run from a clean checkout, and share any earlier audit reports. Then freeze a commit. Preparation is the cheapest part of the audit to get right.
What happens after a smart contract audit?
You publish the report and ship. From then on, any code you change is code the report does not cover. That is the case for re-running analysis on every commit and for monitoring after launch.
Get a quote
Fidesium’s manual audits start at $5,000 and include automated pre-scanning, manual line-by-line review, two rounds of fix verification, a public report with badge and NFT record, and a month of continuous scanning. Request a quote on the manual audit page.
