How to Read a Smart Contract Audit
A smart contract audit is one of the most useful documents for judging whether a crypto project is built carefully. But an audit is easy to misread. This guide shows you what each section means, how to spot what an audit does and does not cover, and why "audited" never means "safe."
What a smart contract audit actually is
A smart contract audit is a review of a project's on-chain code by security specialists who look for bugs, logic errors, and ways an attacker could steal funds or break the protocol. If you are new to the underlying technology, it helps to first understand how smart contracts work and the basics of blockchain, because an auditor is essentially stress-testing automated code that controls real money.
An audit is a snapshot in time, not a seal of permanent approval. It tells you that a specific version of the code was examined by specific people who found and reported specific issues. That is valuable, but it is narrow. For a fuller picture of why audits matter and where they fit among other safety checks, see our overview of the smart contract audit process.
Scope and commit: read this first
Before any finding matters, you need to know what was reviewed. Every credible report opens with a scope section. Two details deserve your full attention:
- Scope — the exact list of files or contracts that were audited. Anything not listed was not reviewed, even if the project uses it in production.
- Commit hash — a unique fingerprint (a long string like
a3f9c1d) identifying the precise code version. If the project later changed the code, the audit no longer fully describes what is live on-chain.
Vault.sol and Staking.sol at commit a3f9c1d. The project's price-feed contract and admin scripts are not in scope. A reader who assumes "the whole protocol is audited" would be wrong: the unreviewed price feed could still hold a critical flaw.Always cross-check the audited commit against the contract address that is actually deployed. A common trap is an audit of an early version while a heavily modified version runs live.
Severity: how serious is each finding?
Findings are graded by severity, usually on a scale from informational up to critical. There is no universal standard, but most firms use something close to the table below.
| Severity | Rough meaning | Example impact |
|---|---|---|
| Critical | Funds can be stolen or frozen | Anyone can drain the vault |
| High | Serious harm under realistic conditions | Rewards miscalculated, large losses |
| Medium | Limited or conditional damage | Breaks only with specific inputs |
| Low | Minor issue, hard to exploit | Edge-case rounding error |
| Informational | Style or best-practice note | Missing comments, gas waste |
Do not just count findings. A report with one unresolved critical issue is far more concerning than one with twenty informational notes. Focus your reading on critical and high items first.
Resolved vs. acknowledged: the most important distinction
After listing each finding, an audit records how the team responded. The wording matters enormously, and beginners often skim past it.
- Resolved / Fixed — the team changed the code and the auditor verified the fix.
- Acknowledged — the team read the finding but did not fix it. They may consider it acceptable risk, or simply chose not to act.
- Mitigated — partly addressed, often by an external control rather than a code change.
"Acknowledged" is not the same as "solved." A clean-looking audit can still contain serious unresolved risks that the team simply chose to live with. Read every high and critical finding's status, not just the summary.
Disclaimers and the hard limits of any audit
Near the end, every report includes a disclaimer. It is not boilerplate to ignore — it states plainly what the audit cannot promise. Typical limits include:
- It covers only the listed code at the listed commit, not later changes.
- It cannot guarantee the absence of all bugs; auditors review within a fixed time budget.
- It does not cover economic design, governance abuse, oracle manipulation outside scope, or off-chain infrastructure.
- It is not an endorsement of the project, the team, or the token's value.
Audits also say nothing about whether a project is a good investment or whether a token will hold value. Many exploited protocols were audited. Treat an audit as one input among many: combine it with the project's track record, who controls admin keys, and your own security habits. If you are still learning the ecosystem, our guides on DeFi and avoiding crypto scams add useful context, and reviewing general security best practices protects you regardless of any audit's conclusions.
A simple checklist
- Confirm the scope and that the commit hash matches the deployed contract.
- Read every critical and high finding before anything else.
- Check whether each is resolved or merely acknowledged.
- Read the disclaimer to see what is excluded.
- Check who the auditor is and whether the report is published in full, not just summarized.
Reading an audit well takes a few minutes and replaces blind trust with informed judgment. It will not make any project risk-free, and it should never be your only safeguard.
This article is for educational purposes only and is not investment advice. Crypto assets are volatile and you can lose money. An audit does not guarantee safety or returns. Always do your own research and never invest more than you can afford to lose.
NOONOO TRADING — join the free chat and watch live trading together.
Join free chat →📈 Sign up on OKX for a trading fee discount
Get OKX fee discount →