Smart contracts hold real value, run in public, and are hard to change once deployed. A smart contract security audit is how a team finds the flaws an attacker would exploit before the code goes live. This guide explains what auditors look at, how audits differ, what you receive, and where an audit's limits are.
A Smart Contract Security Audit, Defined
A smart contract security audit is a structured, independent review of a protocol's on-chain code and the assumptions that determine how it should behave. Security researchers read the code line by line, model how value and authority move through the system, and actively try to break it the way an attacker would.
The review is performed against a fixed commit, so everyone knows exactly which code was assessed. Confirmed issues are written up with their impact, evidence, and a recommended fix. After the team remediates, the auditors re-check the changes in a fix verification step, and the final report records the status of every finding.
Why Smart Contracts Need Audits
Smart contracts combine properties that make mistakes unusually expensive. Their code is public, so attackers can study it as closely as the developers did. They often hold or control assets directly. Many are immutable or difficult to upgrade quickly. And they are composable, so one protocol's bug can propagate through every system that integrates it.
Losses remain large. CertiK's Hack3D reporting counted $3.35 billion in Web3 losses in 2025 and $1.31 billion across 344 incidents in the first half of 2026, including $152 million from 204 incidents attributed to code vulnerabilities. Not every incident is a smart contract bug, but the code-vulnerability share is exactly the category an audit is designed to reduce.
What Auditors Actually Check
A checklist of known vulnerabilities is the starting point, not the audit. The most damaging bugs are usually specific to a protocol's logic: an accounting rule that breaks under an unusual order of calls, a price that can be moved for one block, or a privileged function that a role should never have been able to reach.
Code-level safety
- Reentrancy and external calls
- Input validation
- Arithmetic and rounding
- Unsafe token assumptions
Logic and accounting
- Invariants and state transitions
- Share and debt math
- Liquidations and fees
- Edge cases and ordering
Integrations
- Oracles and price sources
- DEX, lending, and bridge calls
- Cross-chain messages
- Token standard behavior
Control and operations
- Access control and roles
- Upgrades and proxies
- Pausing and emergency paths
- Deployment configuration
Types of Smart Contract Security Reviews
Different review models answer different questions. Many protocols combine several of them across a launch.
| Model | What it is | Best used for | Main limitation |
|---|---|---|---|
| Private expert audit | Assigned researchers review a fixed scope with direct access to the team | Pre-launch and pre-upgrade assurance | Bounded by scope, time, and team size |
| Competitive audit contest | Many researchers review the same code for a prize pool | Broad coverage after a private audit | Less direct collaboration and remediation support |
| Bug bounty | Ongoing rewards for vulnerabilities reported in live code | Continuous coverage after launch | Reactive, and only as strong as its rewards and scope |
| Formal verification | Mathematical proof of explicit properties | Critical invariants such as solvency | Only covers the properties that are specified |
| AI security scan | Automated analysis that surfaces candidate issues | Fast feedback during development | Needs expert validation before results are trusted |
What You Receive: The Audit Report
The report is the lasting output of an audit. It should let an engineer, an investor, or a governance participant understand what was reviewed and what was found without having been in the room. You can see the format Kann Audits uses in our published audit reports.
- Scope: repository, fixed commit, files in scope, and explicit exclusions.
- Methodology: how the review was performed and which techniques were used.
- Severity classification: how impact and likelihood were combined into a rating.
- Findings: description, impact, proof or reproduction path, and recommendation for each issue.
- Status: whether each finding was fixed, partially fixed, or acknowledged after fix verification.
- Disclaimer: what the audit does not cover and what it cannot guarantee.
How Findings Are Rated
Severity combines the impact of an issue if exploited with the likelihood that the conditions for exploitation are met. Kann Audits reports use the following scale.
| Severity | Meaning |
|---|---|
| Critical | Directly exploitable with few or no preconditions, leading to theft or permanent loss of funds or loss of control of the system. Must be fixed before deployment. |
| High | Directly exploitable vulnerabilities that can lead to significant material loss or critical impact on the system and require immediate fixing. |
| Medium | Moderate loss of funds or impact on multiple users, but only under specific conditions. Exploitable without privileged access, but typically requires certain assumptions or edge cases. |
| Low | Issues with limited impact that do not put funds directly at risk, such as edge cases or deviations from documented behaviour. |
| Informational | Non-exploitable findings such as best-practice deviations, cosmetic issues or documentation and compliance notes. |
What an Audit Cannot Promise
An audit is evidence, not insurance. It covers a defined scope at a specific commit, performed by a specific team in a specific amount of time. It cannot prove that no vulnerability exists, and it says nothing about code that changes afterward or systems that were excluded from scope.
That is why teams should treat an audit as one layer: combined with internal testing, careful access control, monitoring, incident readiness, and additional review whenever the code or its integrations change materially.
An audit reduces uncertainty within its scope. Changes after the reviewed commit need their own review.
Cost, Timeline, and Choosing a Provider
The price and duration of an audit depend mostly on code size, complexity, language, and how much of the design is novel. Our audit cost guide explains the drivers in detail, and the audit process guide walks through each stage from first contact to the final report.
If you are selecting a team, read how to choose a smart contract auditor and our comparison of top Web3 security audit firms.
Common Questions About Smart Contract Audits
Quick answers to the questions teams ask before their first smart contract security audit.
What is a smart contract security audit in simple terms?
It is an independent, adversarial review of a protocol's smart contracts and the assumptions around them. Security researchers look for ways an attacker could steal funds, break accounting, take control, or stop the system from working, and document each confirmed issue with its impact and a recommended fix.
What does a smart contract audit report include?
A useful report identifies the repository and commit in scope, the methodology, the severity classification, and every finding with its description, impact, evidence, recommendation, and final status after fix verification. It also states what the review did not cover.
Is an audited smart contract guaranteed to be safe?
No. An audit reduces uncertainty within a defined scope and code revision. It cannot prove that every vulnerability has been found, and later code changes, new integrations, and out-of-scope systems can introduce new risk.
What is the difference between an audit and a bug bounty?
An audit is a scheduled, scoped review by assigned researchers before launch or before an upgrade. A bug bounty is an open, ongoing invitation for anyone to report vulnerabilities in live code in exchange for a reward. Mature protocols usually use both.
When should a protocol get a smart contract audit?
After the in-scope code is stable and tested, and before deployment, with enough time left for remediation and fix verification. Significant upgrades and new integrations should be reviewed again before they go live.
How long does a smart contract audit take?
It depends on code size, complexity, language, and how novel the design is. A focused contract can take days, while a large protocol or cross-chain system can take several weeks. A provider should review the codebase before proposing a schedule.
Primary references