The Smart Contract Audit Process, Step by Step
Quick answer. A smart contract audit runs in six steps: scoping and quote, kickoff, manual review with tooling, live findings and questions, a draft report, then fix review and a final report. SEAL puts review at 1 to 5+ weeks by size; fix reviews add days.
Video transcript
An audit runs longer than the review window on its quote. Your team has work at all six steps.
Scoping and quote, kickoff, manual review with tooling, live findings and questions, a draft report, then fix review and the final report.
Scoping turns your code into a quote. Freeze one commit, name the exact files, and quote every firm against that same scope.
Kickoff starts with a readiness check. OpenZeppelin wants passing tests covering at least 90 percent of the code.
Manual review is where most auditor time goes. SEAL counts lines and calls its bands rough, from one to two weeks to five or more. Guardian's medians run two to fourteen working days.
During review, keep answers fast. Name one engineer for questions, push no new commits, and fix early findings in separate pull requests.
The draft report gives each finding a severity, impact and recommended fix. Treat it as a fix list, not a public record.
Then budget at least one fix review. 53 of 67 Guardian reports in its timing sample include a remediation round.
Fix reviews catch new bugs. In Guardian's Ethos Network report, a fix made reward accounting round up while a view function still rounded down.
Guardian scopes from your repository and commit, runs two independent teams, and reviews your fixes before the final report. Read the full guide, or share your scope at guardian.security.
The Six Steps at a Glance
The review window on a quote is only one part of an audit. The audit runs longer, and your team has work at every step.
An audit reviews a defined codebase at one commit. Its report recommends fixes but guarantees nothing. ethereum.org, OpenZeppelin, Security Alliance SEAL Frameworks
Below are the six steps, what happens in each and how long each takes. For the full calendar from booking to launch, see how long a smart contract audit takes.
| # | Step | What happens | Typical duration |
|---|---|---|---|
| 1 | Scoping and quote | Repository, commit, files and team agreed; quote issued | Set by each firm; see Step 1 |
| 2 | Kickoff | Readiness check, then a design walkthrough meeting | One meeting, after code freeze |
| 3 | Manual review and tooling | Line-by-line review, static analysis and fuzzing | 1 to 2 weeks under 1,000 lines; 5+ above 4,000 |
| 4 | Live findings and questions | Questions answered; serious issues flagged early | Runs alongside the review |
| 5 | Draft report | Findings with severity, impact and recommended fixes | After review ends; Spearbit sends it before the close-out call |
| 6 | Fix review and final report | Auditors check your fixes and update finding statuses | Two and four days in two Guardian examples |
Step 1: Scoping and Quote
Scoping turns your code into a quote. The firm needs the repository, a frozen commit and the exact files in scope. OpenZeppelin, Security Alliance SEAL Frameworks, Guardian
Size is usually counted in nSLOC: non-comment source lines of code. Complexity, contract count and integrations can move the estimate substantially. Guardian Resource Hub
None of the firms in our timing guide publishes a standard lead time. Ask each one for its next start date before you fix a launch date.
Quote every firm against the same frozen scope, or the totals will not compare.
Our guide to smart contract audit scoping explains how auditors size code and handle scope creep.
- Repository URL and the frozen commit hash.
- Exact in-scope and out-of-scope files.
- Every dependency, oracle and protocol the code trusts.
- Target chains and how the code will be deployed.
- Auditor count, named reviewers and review dates.
- How many fix-review rounds the price includes.
- Deliverables: report format, severity scale and whether the report is published.
Step 2: Kickoff and Readiness
Before work starts, the audit team checks that the final code, documentation and tests are ready. OpenZeppelin
OpenZeppelin's readiness guide asks for tests that pass on a fresh install and cover at least 90% of the code.
The kickoff meeting then confirms scope and timeline. Your team walks through the design, and the researchers ask precise questions about it. Guardian
Freeze the code first. Sherlock asks contest teams for the frozen commit about 72 hours before kickoff. Guardian Resource Hub
Our checklist on how to prepare for a smart contract audit lists what to hand over.
Step 3: Manual Review and Tooling
Most auditor time goes here. Reviewers trace architecture, permissions, accounting, integrations and business logic line by line, looking for edge cases. OpenZeppelin, ethereum.org
OpenZeppelin assigns at least two auditors to the same codebase.
Tools add coverage. Static analysis flags known bug patterns, while fuzzing and invariant tests run generated call sequences against properties that must always hold.
Formal verification proves specified properties, and only those. Our comparison of formal verification vs fuzzing vs audit explains when each fits.
Guardian runs two independent teams on the full scope: manual review with an invariant fuzzing suite, and Helix, its AI auditor. Only human-verified findings reach the report. Guardian
Review length rises with size. SEAL calls its bands rough; Guardian's medians count main-review working days across 67 public reports, with six or seven per band above 2,000 nSLOC. Security Alliance SEAL Frameworks, Guardian Resource Hub
Our smart contract audit cost estimator turns these lengths into a price range.
For the reviewer's side of this step, read how to audit a smart contract.
| Size in scope | SEAL rough estimate | Guardian median review |
|---|---|---|
| Up to 500 nSLOC | 1 to 2 weeks (under 1,000 lines) | 2 working days |
| 501 to 1,000 nSLOC | 1 to 2 weeks (under 1,000 lines) | 4 working days |
| 1,001 to 2,000 nSLOC | 2 to 5 weeks (1,000 to 4,000 lines) | 8 working days |
| 2,001 to 3,000 nSLOC | 2 to 5 weeks | 11 working days |
| 3,001 to 5,000 nSLOC | 2 to 5 weeks, then 5+ above 4,000 lines | 14 working days |
| Over 5,000 nSLOC | 5+ weeks | 14 working days |
Step 4: Live Findings and Questions
An audit should not go quiet for weeks. Auditors keep a channel open to clarify code and test their assumptions with your developers. OpenZeppelin
OpenZeppelin alerts clients right away when it finds a Critical or High issue, so they can begin planning fixes.
Fast answers buy review time. Every hour an auditor spends guessing intent is an hour not spent attacking the code.
- Name one engineer to answer auditor questions, ideally the same day.
- Push no new commits to the audited branch.
- Fix early findings in separate pull requests, ready for the fix review.
- Write down design answers given on calls; they belong in your documentation.
Step 5: The Draft Report
The draft report follows the review. Each finding carries a severity, its location, the impact and a recommended fix. OpenZeppelin, Security Alliance SEAL Frameworks
Expect proofs of concept for exploitable issues, plus informational notes and gas suggestions.
Delivery timing is set by each firm, so put the draft date in your statement of work. Spearbit sends its draft after the review period ends and before its close-out call, without a stated day count. Spearbit Spearbook
OpenZeppelin calls its first report an initial private report. Treat yours as a fix list, not a public record.
- Read every finding, and ask for a call on any you dispute.
- Fix Critical and High findings first.
- Record a reason for each finding you will not fix.
- Keep each fix small, and rerun the full test suite after it.
Step 6: Fix Review and Final Report
You patch the findings at a new commit. The auditors review each fix and the code around it, then update each finding's status. OpenZeppelin, Security Alliance SEAL Frameworks, Guardian
OpenZeppelin includes one round of fix reviews when each fix sits in its own pull request, and its readiness guide frames fix review as done on request.
Ask how long you have to fix. Spearbit's documentation sets its fix period at within two weeks, before the report becomes final. Spearbit Spearbook
Plan for at least one: 53 of the 67 Guardian reports in its timing sample include a remediation round. Guardian Resource Hub
In two published Guardian engagements, fix reviews spanned four and two calendar days. Your team's fixing time comes first, and grows with the finding count.
Fix reviews catch new bugs. In Guardian's July 2026 Ethos Network report, a fix made reward accounting round up while a view function still rounded down.
The remediation review logged that mismatch as a new Low, later resolved. It also noted an earlier Low that was only partly fixed.
The final report lists each finding's status and the reviewed commits. Our guide to audit finding statuses explains resolved, acknowledged and the rest.
Before launch, check that deployed bytecode matches the final reviewed commit. Keys, signers, frontends and APIs need their own assessments. ethereum.org
Code changed after the final report is unaudited; see which changes need a re-audit.
Frequently Asked Questions
Can we change code during the audit?
Only through a rescope. SEAL says scope sets the timeline and cost, and broader scope costs more. Ask the firm to price the new code as a change, at its own commit, before it lands. Security Alliance SEAL Frameworks
How long does the whole audit process take?
Add up the steps: lead time, a few days of code freeze, the review, your fixes and the fix review. In two Guardian examples, fix reviews began six and thirteen days after the main review ended. Guardian Resource Hub
Should we publish the audit report?
It is optional. OpenZeppelin's readiness guide lists publication as the last, optional step, and SEAL lists a community-facing report among final deliverables. Publish the final version, not the draft, so readers see each fix's status. OpenZeppelin, Security Alliance SEAL Frameworks
Related reading
- what is a smart contract audit
- how to choose a smart contract auditor
- smart contract audit rfp template
- smart contract audit severity levels
- how to read a smart contract audit report
Sources
- ethereum.org: Smart contract security
- OpenZeppelin: What is a Smart Contract Audit: Lessons from OpenZeppelin’s 700+ Audits (January 22, 2025)
- OpenZeppelin: Smart Contract Audit Readiness Guide
- Security Alliance SEAL Frameworks: What to Expect from a Smart Contract Audit
- Guardian: Smart contract audit services
- Guardian Resource Hub: How Long Does a Smart Contract Audit Take?
- Guardian Resource Hub: Smart Contract Audit Cost Estimator and Calculator
- Guardian: Ethos Network Vouching and Slashing Audit Report
- Guardian: LayerZero Solana Console Security Review
- Guardian: LayerZero Solana OApp Audit Report
- Guardian: Alt Fun Bonding, Routing and Graduation Audit Report
- Guardian: Synthetix SNX Vaults Audit Report
- Spearbit Spearbook: Close-out Call and Walkthrough
- Spearbit Spearbook: Final Report Delivery
- ChainScore Labs: Substrate Governance Pallet Security Audit
Plan your first audit around the fix review
Guardian scopes each smart contract audit from your repository and commit, runs two independent teams on one scope, and reviews your fixes before the final report. Share your scope to get a quote.