What Happens During a Smart Contract Audit: Week-by-Week Process

A smart contract audit takes about three to four weeks from kickoff to final report. The first week is pre-audit preparation, the next two weeks are manual review by senior security researchers, the fourth week is findings documentation and fix verification, and the deliverable is a detailed report tied to a specific commit hash. Understanding this process before you book your audit is what separates founders who get value from founders who pay for a PDF they don't understand.

Most founders sign $20,000-plus audit contracts without knowing what they're actually paying for. They hand over their codebase, wait three weeks, and hope the result is worth the cost. This guide closes that gap. It walks you through exactly what your auditor should be doing during each phase of a professional smart contract audit, so you know what to expect, what to ask for, and how to tell if your audit firm is actually doing the work.

TL;DR — Quick Summary

A real smart contract audit has six phases: pre-audit prep, week 1 (architecture reading + tools), week 2 (manual deep review + attack scenarios), week 3 (findings + peer review + draft report), fix verification, and final deliverable.
The pre-audit prep week is the most underrated part of the entire process, and it is the founder's job, not the auditor's.
In week 1, the researcher is not finding bugs yet. They are reading. You cannot find a sophisticated attack in a system you do not understand.
A draft report with zero findings should make you suspicious, not relieved. Every protocol has findings.
The fix verification round is the step most cheap firms skip. Without it, you do not have an audit, you have half of one.
The final deliverable must include a signed attestation tied to a specific commit hash so the audit is publicly verifiable.

Ready to book?

Get a scoped quote or check if you qualify for a grant.

Skip the back-and-forth. Tell us about your protocol and you'll get a clear scope, named auditors, and a realistic timeline within 48 hours. If cost is the blocker, the grants program covers 25 to 100 percent of audit fees based on a simple points system.

Request a scoped quote Apply for an audit grant

Watch the full video walkthrough

This article is the written companion of the YouTube video where I walk founders through what actually happens during a smart contract audit. If you prefer video, watch it here: What Actually Happens During a Smart Contract Audit.

In this article:

What founders should do in the week BEFORE the audit starts (and why most skip it)

Why a senior researcher spends week 1 reading, not finding bugs

How real bugs get found in week 2 (the question that defines auditing)

How findings become a structured, severity-rated report in week 3

Why the fix verification round separates real audit firms from fakes

What the final deliverable should include and what it means for your investors

Before the audit starts: the prep week most founders skip

Most founders think the audit starts when they sign the contract. It does not. The week before any code gets reviewed is the most underrated part of the entire process. It is where most audits go right or wrong, and almost none of it is the auditor's job. It is yours.

Three things must happen in this pre-audit week.

One. Scope agreement in writing. You and the auditor agree on which contracts, which files, and which functions are in scope. What is in. What is out. Signed off in writing. No vibes. Without this clear audit scope, the engagement either expands uncontrollably or misses entire modules.

Two. Commit hash and code freeze. You hand over a specific commit hash, not a branch. The hash locks in the version being audited. Once it is set, you stop pushing changes. This is called a code freeze, anchored to a frozen commit hash. If you keep merging features mid-audit, the auditor is reviewing a moving target, and that is how bugs slip through.

Three. Documentation and threat modeling. A short README explaining what the protocol does. Architecture diagrams if you have them. A threat model describing the attacks YOU are worried about. The more context the auditor has on day one, the more time they spend finding real bugs instead of figuring out what your code is supposed to do.

There is one more thing most founders never think to do. Run a free security scanner over your code yourself before sending it to the auditor. At Zealynx we built one called Krait. It is free, and it catches the issues a tool can catch in minutes. That way the human auditor is not spending your money finding bugs a scanner could flag in five minutes. They spend it on the bugs only a human can find.

Pre-audit week ends with a kickoff call, usually 45 minutes. You walk the auditor through the architecture. They ask questions. You answer them. Then the real work starts.

Week 1: understanding your system before finding bugs

Here is something that surprises every founder I have worked with. In week one of an audit, the researcher is not really finding bugs yet. They are reading.

A senior security researcher opens your codebase and goes through it the way a novelist reads a book. Slowly. Carefully. Taking notes. What does each contract do? How do the contracts call each other? Where does money flow in? Where does it flow out? What state does each function modify? What are the trust assumptions? Who is allowed to do what?

This is also when automated tooling runs in the background. Static analyzers like Slither. Symbolic execution. Internal proprietary tools that vary by firm. The machines surface the easy patterns while the human researchers build a mental model of the system.

The reason this matters: you cannot find a sophisticated attack in a system you do not understand. The bugs that drain protocols for millions of dollars are not pattern-matched by a tool. They are found by a person who sat with your code long enough to see what you could not see when you wrote it. By the end of week one, the auditor knows your code better than most of your engineers do. Sometimes better than you do. That foundation is everything the rest of the audit depends on.

Week 2: how real bugs actually get found

Week two is when the audit gets interesting. The researcher understands the system. Now they start asking the question that defines our entire job: what if I were trying to break this, how would I do it?

This is the manual deep review. It is not glamorous. It is a researcher sitting in front of a screen for eight to ten hours a day, asking variations of the same question about every function in your codebase.

What happens if a user calls this function with zero?
What happens with the maximum integer value?
What happens if two users call it simultaneously?
What happens if a malicious contract is calling it instead of an EOA?
What happens during a flash loan?
What happens when the oracle price spikes?
What happens when this admin role gets compromised?

Most of those questions lead nowhere. The code handles them correctly. But every once in a while, a question leads somewhere the developer never anticipated. That is a finding.

During week two, expect questions from your auditor. Sometimes a lot of them. This is a good sign. It means they are actually reading. A silent auditor in week two is a red flag. They are either disengaged or not deep enough yet to know what to ask. How to choose an audit firm often comes down to whether they ask the right questions during this phase.

Week 3: how findings become a structured report

By week three, the researcher has a backlog of findings. Each one goes through a structured process before it ever hits your inbox.

First, the finding is documented. Title. Description. Vulnerable code snippet. Impact. Proof of concept if it is exploitable.

Second, severity is assigned. Critical, High, Medium, Low, Informational. Severity is not vibes-based. It is a structured audit severity matrix of impact times likelihood. A serious firm uses the same framework on every audit, so a "High" on your report means the same thing as a "High" on another protocol's report.

Third, a recommendation is written. Not just "this is broken." Specifically how to fix it. The code change. The trade-offs. What to watch for after the fix.

Fourth, every finding goes through audit peer review. Another senior researcher reads it and pushes back if something does not hold up. This is how false positives get caught BEFORE they hit your report, not after, when they would be embarrassing for everyone. Cheap firms skip this step. It is one of the clearest separators of audit quality.

By the end of week three, you receive a draft report. That is your first look at what was found. This is also when most founders panic for the first time. It is normal. Every protocol has findings. Even the best teams. Even the most carefully written code. If your report comes back with zero findings, be suspicious. It probably means the auditor did not look hard enough.

The fix verification round: the step most firms skip

After the draft report drops, the ball is back in your court. You go through the findings. You fix what needs fixing. Sometimes that takes three days. Sometimes three weeks. Depends on how deep the issues run.

Then you send the patches back to the auditor.

This is where a real audit firm earns its money. The fix verification round is a second review. The auditor takes your patches and asks three questions:

Did the patch actually fix the bug?
Is the fix complete, or does it leave an edge case open?
Did the fix introduce a NEW vulnerability?

The third question is the killer. I have seen fixes that patched a critical vulnerability and created a different critical vulnerability in the same pull request. Without a fix verification round, nobody catches it. It ships. It gets exploited.

At Zealynx, fix verification is included by default in every audit. No exceptions. If your auditor charges extra for it, or does not offer it at all, you do not have an audit. You have half of one. This is one of the red flags founders should watch for when evaluating audit firms.

Once verification is done, the report is updated. Each finding gets a final status: Acknowledged, Fixed, Partially Fixed, or Not Addressed. That is the document you show your investors, your users, and your board.

What you actually get at the end

When the audit is fully closed, here is what lands in your inbox.

A final PDF report, usually 20 to 80 pages depending on findings. Inside that report:

An executive summary your non-technical co-founders can read.
A summary table of all findings sorted by severity.
A detailed write-up of every finding: what it is, where it is, why it matters, and how it was fixed.
A scope section so anyone reading later knows exactly what was reviewed and what was not.
The commit hash of the audited version.
A signed audit attestation from the firm.

Are you audit-ready?

Download the free Pre-Audit Readiness Checklist used by 30+ protocols preparing for their first audit.

No spam. Unsubscribe anytime.

That last piece is what investors look for in an audit report. The signed audit attestation, tied to a specific commit hash, makes the audit verifiable. Anyone in the world can check that the code running on chain matches the code that was reviewed.

You also typically get the right to display the firm's badge. "Audited by Zealynx Security" on your website, linked to the public report. That is a trust signal users actively look for now.

Three things founders consistently get wrong

In years of doing this, three founder behaviors keep showing up.

They wait too long to engage an auditor. Good firms book out four to eight weeks in advance. If you are three weeks from launch and you have not booked an audit, you are either delaying launch or rushing the audit. Both are bad outcomes. Talk to a firm the moment you have a stable feature set, not when you are done coding. Improving your audit readiness before the kickoff call saves real money on the audit itself.

They keep pushing code during the audit. Code freeze means code freeze. If you discover a feature you forgot, either add it to the next audit or accept that everything new is unreviewed. Do not make your auditor re-audit work they already did because your team could not wait two weeks.

They treat the audit as a checkbox. The audit is not the goal. Security is the goal. The audit is one signal in a system that also includes testing, fuzzing, monitoring, bug bounty programs, and incident response. A great audit is the start of your security posture, not the finish line. Founders who get that get ten times more out of every audit than founders who do not.

When cost is the blocker: audit grants

The most common reason founders delay an audit is cost. If that is your situation, look into Zealynx Audit Grants. We cover anywhere from 25 percent to 100 percent of the audit cost based on a simple points-based system. Use our security scanner, complete a few of our Academy modules, share your security work publicly. The more points you stack, the bigger the grant. There is no good reason cost should be the thing keeping you from launching safely.

Partner with Zealynx

At Zealynx Security, we run every audit using the exact process described in this article. Named auditors, written scope, code freeze, manual deep review, peer-reviewed findings, and a mandatory fix verification round on every engagement. No exceptions. Whether you are 6 weeks from launch or just starting to plan your security budget, we can scope a quote within 48 hours.

Request a scoped audit quote

Apply for a Zealynx Audit Grant

FAQ: Smart contract audit process and timeline

1. How long does a smart contract audit take from kickoff to final report?

A typical audit takes 3 to 4 weeks from kickoff to draft report, plus 1 to 2 weeks for fix verification. Simple tokens may take as little as 1 week. Complex DeFi protocols, bridges, or L1s may take 6 to 12 weeks. The size and complexity of your codebase, the language (Solidity vs Rust vs Cairo vs Move), and your timeline pressure all affect duration.

You should plan for the audit to end roughly 1 to 2 weeks before your launch date, which means booking it about 4 to 6 weeks ahead. Booking further in advance risks audit decay as your code keeps changing between the review and launch.

2. What should be included in a complete smart contract audit?

A complete audit must include six elements:

Written audit scope agreement signed before kickoff.
Code freeze on a specific frozen commit hash that locks the version under review.
Manual deep review by senior researchers, not just automated tooling output.
Severity-rated findings using an impact-times-likelihood matrix that is consistent across audits.
Internal peer review of every finding before the draft report hits the client.
Fix verification round on the client's patches.

The final deliverable should be a signed report tied to the audited commit hash. If your firm skips any of these, push back or pick a different firm.

3. What is a fix verification round and why is it so important?

A fix verification round is a second review performed by the audit firm after you patch the issues from the initial report. The auditor checks three things: whether your fixes actually resolve the bugs, whether they leave any edge cases open, and whether they introduce new vulnerabilities.

The last check is the most important. A patched critical vulnerability that creates a different critical vulnerability is one of the most common ways protocols get exploited post-audit. Fix verification should be included by default in any serious audit. If a firm charges extra for it or does not offer it, the engagement is incomplete.

4. Why does my audit report have findings even though my code seems clean?

Every protocol has findings. Even the best engineering teams. Even the most carefully tested code. If your audit report comes back with zero findings, that is suspicious. It usually means the auditor did not look deeply enough rather than that your code is perfect.

A clean audit report is a red flag, not a green one. A good audit firm will find issues in every codebase they review, even if many are Low or Informational severity. The goal of the audit is not a clean report, it is knowing every issue so you can fix it before users do.

5. How do I prepare for a smart contract audit to get the best value?

To maximize the value of your audit budget:

Lock a specific commit hash and freeze your codebase for the full duration of the engagement.
Write clear documentation including architecture diagrams and a threat model describing the attacks you are worried about.
Run a free scanner like Krait before the kickoff to clean up low-hanging issues that a tool can catch in minutes.
Make sure your test coverage is at least 70 percent so the auditor is not finding things basic tests would have caught.
Budget engineering bandwidth for fix work after the report drops, otherwise the audit ends without resolved issues.

Doing these things before the kickoff call saves real money and produces a substantially better audit.

6. What is the difference between a draft report and a final report in a smart contract audit?

The draft report is delivered at the end of week 3 and contains all findings the auditor identified during the review, with severity ratings and recommended fixes. At this point the client has not yet patched anything.

The final report is delivered after the fix verification round, usually 1 to 2 weeks later. It includes a final status for each finding (Acknowledged, Fixed, Partially Fixed, or Not Addressed) and is the document you show to investors, users, and your board. The final report is the one tied to the signed attestation that makes the audit publicly verifiable.

Glossary

Term	Definition
Code Freeze	The policy of halting all changes to the audited codebase from kickoff through final report delivery, locking the audit to a specific commit hash.
Manual Deep Review	The week-two phase of a smart contract audit where a senior researcher manually asks adversarial questions of every function in scope, looking for exploit paths automated tools cannot find.
Audit Severity Matrix	The two-axis framework auditors use to assign Critical, High, Medium, Low, or Informational severity to findings based on impact times likelihood.
Audit Peer Review	The internal quality assurance process where a second senior researcher reviews every finding before the draft audit report is delivered to the client.
Fix Verification Round	A mandatory second review by an audit firm to confirm that client patches actually fix the reported vulnerabilities without introducing new ones.
Signed Audit Attestation	A formal statement signed by the audit firm that ties a specific audited commit hash to the final report, making the audit publicly verifiable on-chain.

View complete glossary →

Are you audit-ready?

Download the free Pre-Audit Readiness Checklist used by 30+ protocols preparing for their first audit.

No spam. Unsubscribe anytime.