A smart contract audit follows a predictable sequence: the scope is fixed on a specific commit, the auditors review the code manually and with automated tools, they report findings ranked by severity, the developer fixes them, and the auditor verifies the fixes before issuing a final report. Most audits of a small to mid-sized codebase take one to three weeks of review, plus the time needed for fixes and the re-audit. Knowing each step in advance helps you plan your launch date, prepare your team and read the report correctly.
Overview of the audit process
The audit process has nine steps, and the client has a defined role in each of them. The table below summarizes who does what.
| Step | Led by | What the client does |
|---|---|---|
| 1. Scoping and commit hash | Client and auditor | Defines the files in scope, freezes the code, shares the commit |
| 2. Kickoff | Auditor | Walks the auditors through the design and answers questions |
| 3. Manual review | Auditor | Stays available for questions, does not change the audited code |
| 4. Automated analysis | Auditor | Provides a working test suite and build instructions |
| 5. Findings and severity | Auditor | Reads early findings, asks for clarifications |
| 6. Report delivery | Auditor | Reviews the preliminary report with the developer |
| 7. Fixes | Developer | Prioritizes fixes, tracks each finding to a commit |
| 8. Re-audit | Auditor | Shares the fix commits and responses per finding |
| 9. Final report and publication | Auditor and client | Decides whether to publish, links the report to the deployed code |
Scoping and kickoff
The audit starts with two preparation steps: agreeing on the exact code to review, then briefing the auditors on how it works.
Step 1: scoping and commit hash
Scoping defines exactly which code the auditor will review, and it is anchored to a single commit hash. The audit scope lists the repository, the files and contracts included, the files explicitly excluded (tests, mocks, third-party libraries), and the size of the code, usually measured in nSLOC (normalized source lines of code).
At this stage the client should:
- Share the repository and the exact commit to be audited.
- Declare a code freeze on the files in scope.
- Provide the specification, architecture notes and the list of privileged roles.
- Mention external integrations (oracles, bridges, other protocols) and upgradeability, since they widen the review.
The scope drives the quote. A change of scope after the audit has started usually means a new estimate, a delay, or both. Our guide on how to prepare for a smart contract audit covers the preparation in detail.
Step 2: kickoff
The kickoff is a meeting where the development team explains the system to the auditors before the review begins. It typically lasts one to two hours and covers the purpose of the protocol, the main user flows, the trust assumptions, the roles and permissions, and the areas the team considers most sensitive.
The client should attend with at least one developer who knows the code in depth. The team also agrees on a communication channel for questions during the review and on the format of the reports. A clear kickoff saves auditor time, and auditor time is what you pay for.
Steps 3 and 4: manual review and automated tools
The core of an audit is manual review by experienced auditors, supported by automated tools that cover what humans do less efficiently. Neither replaces the other.
Manual review
Auditors read the code line by line and reason about how it can be misused. They check the business logic against the specification, access control, handling of external calls and reentrancy, price and oracle assumptions, arithmetic and rounding, upgrade mechanisms, and the economic incentives of each actor. Logic errors, which tools rarely catch, are found here.
Automated tools
Auditors typically combine several techniques:
- Static analysis: tools scan the code for known patterns of vulnerabilities and bad practices.
- Fuzzing: the contracts are called with large volumes of random or semi-random inputs to find unexpected states.
- Invariant testing: the auditor writes properties that must always hold (for example, total deposits cover total claims) and tries to break them.
- Formal verification, in some engagements: a mathematical proof that specific properties hold. It is costlier and usually limited to critical components.
During this phase the client stays available to answer questions quickly and does not modify the audited commit. Any new code goes on a separate branch.
Findings, severity and report
The output of the review is a list of findings ranked by severity, delivered in a preliminary report that the client and developer then review.
Step 5: findings and severity
Each issue the auditor identifies is recorded as a finding with a description, its location in the code, its impact, a recommendation, and a severity level. Severity combines the impact of an exploit with its likelihood.
Common levels are:
- Critical: direct loss or freezing of funds, or takeover of the system, with a realistic path to exploitation.
- High: significant loss or disruption under plausible conditions.
- Medium: limited impact, or significant impact that requires unusual conditions.
- Low: minor issues, deviations from best practice with small impact.
- Informational: code quality, documentation, gas optimization.
Important findings are often shared as soon as they are confirmed, sometimes with a proof of concept. The client should read them promptly and ask for clarification if the impact is unclear.
Step 6: report delivery
At the end of the review, the auditor delivers a preliminary audit report. It usually contains the scope and commit hash, the methodology, a summary by severity, each finding in detail, and general observations on code quality and design.
The client and the developer review this report together, confirm or dispute each finding with arguments, and decide how each one will be handled: fixed, partially fixed, or acknowledged (accepted as a known risk, with a justification).
Fixes, re-audit and final report
After the report, responsibilities split: the developer fixes, the auditor verifies, and the final report records the result.
Steps 7 and 8: fixes and re-audit
The developer fixes the findings, and the auditor then verifies the fixes in a re-audit. These are two separate roles. The auditor does not write the fixes, and the developer does not validate them.
For the fixes, the client should:
- Fix critical and high findings first, and avoid mixing fixes with new features.
- Link each finding to a specific commit or pull request.
- Write a short response per finding explaining what changed, or why the risk is accepted.
- Add tests that reproduce each fixed issue.
For the re-audit, the auditor reviews the diff between the audited commit and the fix commit, checks that each fix resolves the issue without introducing a new one, and updates the status of each finding. The re-audit is much shorter than the first review, but it is not free. In the site's indicative model, it is budgeted at about 20% of the first audit price. Large changes between the audited commit and the fix commit may require a new review rather than a re-audit.
Step 9: final report and publication
The final report records the status of every finding after the re-audit and identifies the exact commit that was reviewed. The client then decides whether to publish it. Publication is common for projects that hold user funds, since users, partners and exchanges often ask for it.
When publishing, make sure the deployed code matches the final audited commit, and state it clearly. A report on a commit that differs from what is on mainnet gives a false sense of assurance.
How long a smart contract audit takes
Duration depends mainly on the size and complexity of the code, the number of auditors, and how ready the project is. In the site's indicative model, a 1,500 nSLOC DeFi codebase in Solidity represents about 6 auditor-days with an independent auditor, or about 8.5 auditor-days (around two weeks) with an established firm. A 5,000 nSLOC DeFi codebase takes about three weeks with two auditors. Small token contracts fall under the minimum engagement of 3 auditor-days.
Add to this the time between the booking and the start (auditors are often booked weeks ahead), the time for fixes, and the re-audit. These are indicative ranges from the site's public model; real timelines depend on the scope. For figures on your own project, see our guide on smart contract audit cost or the audit cost calculator.
What an audit does and does not guarantee
An audit reduces risk, it does not eliminate it. It is a time-boxed review of a specific commit by specific people, and its value depends on the scope, the time allowed and the quality of the preparation.
An audit does:
- Identify vulnerabilities and design weaknesses in the code in scope.
- Give an independent opinion on the code at a given commit.
- Provide recommendations and verify the fixes during the re-audit.
An audit does not:
- Guarantee the absence of bugs or the security of funds.
- Cover code outside the scope, later changes, or other deployments.
- Cover off-chain components, key management or operational security unless they were explicitly included.
- Validate the economic soundness of the business model, unless that was part of the engagement.
For that reason, many teams combine an audit with other measures: extensive tests, a bug bounty after launch, monitoring, a multisig and a timelock on admin functions. The independence of the auditor also matters: the firm that wrote the code should not audit it. This is a rule on smart-contract.com, where a company engaged to develop a project can never be engaged for its audit or re-audit.
Key takeaways
- The audit process runs from scoping on a frozen commit to a final report on the fixed code, with manual review at its core and automated tools in support.
- The client has a role at every step: preparing the scope, attending the kickoff, answering questions, fixing findings and documenting each fix.
- The developer fixes the findings and the auditor verifies them in a re-audit, budgeted at about 20% of the first audit in the site's indicative model.
- Typical review time ranges from a few days for small contracts to several weeks for large DeFi codebases, plus booking, fixes and re-audit.
- An audit reduces risk on a specific commit; it does not guarantee the absence of bugs.