TL;DR: An audit badge on a project’s website is marketing. The report behind it is data. Most users never open the PDF, which means they miss the only part that matters: what was actually reviewed, what was found, and what was fixed. This guide walks through a standard audit report section by section, explains how to read severity levels and scope limits, and gives you a red-flag checklist you can run in ten minutes before trusting any “audited” protocol.
You do not need to be a Solidity developer to read an audit report usefully. You need to know what questions each section answers — and which questions no audit can answer.
Why Audit Badges Mislead
A “Passed Audit” badge compresses a 40-page technical document into one pixel of information. That compression hides the three facts that determine whether the audit means anything:
- Scope — which contracts were actually reviewed
- Timing — whether the deployed code matches the audited code
- Resolution — whether the findings were fixed, or just acknowledged
Projects know most users do not check these. Some exploit that. A protocol can commission an audit of one small utility contract, then display an audit badge site-wide. That is not lying, technically — but it is not security either. For a broader framework of warning signs that go beyond audits, see DeFi Protocol Red Flags.
The core concept is simple: an audit is a contract audit — a point-in-time review of a specific code snapshot by a specific team, paid for by the project. Understanding what that relationship implies is the first step to reading reports with the right skepticism.
The Standard Anatomy of an Audit Report
Most reports from reputable firms follow a similar structure. Here is what each section actually tells you:
| Section | What it contains | What you should extract |
|---|---|---|
| Executive summary | Overall verdict, engagement dates | Auditor name, date, effort size (person-days) |
| Scope | Contracts, files, commit hash reviewed | The exact boundary of what was and was not reviewed |
| Methodology | Review techniques, tooling, time budget | How deep the review could realistically go |
| Findings | Issues by severity, with code references | Count per severity, exploitability, fix status |
| Resolved findings | Issues the project fixed during engagement | Whether fixes were re-reviewed or just accepted |
| Retest / fix review | Verification of remediation | Whether fixes were verified, not just claimed |
| Disclaimer | Legal limits of the audit | What the audit explicitly does not cover |
Two of these sections do most of the work: scope and findings. The rest is context. Read those two carefully and skim the rest.
Reading the Scope Section (Where Audits Go to Die)
The scope section is the single most valuable part of the report, because it defines the boundary of the auditor’s knowledge. Common patterns to recognize:
- Partial coverage. A protocol with 30 contracts may have audited 8. The unaudited 22 might include the bridge, the vault, or the upgrade logic — the exact components attackers target.
- Commit hash mismatch. The report references a specific commit. If the deployed contract on the block explorer does not correspond to that commit, the audit covers different code than what holds user funds. Projects sometimes ship “small changes” after an audit. Small changes have historically produced large exploits.
- Explicit exclusions. Scope sections often list what was not reviewed: admin functions, third-party integrations, off-chain components, deployment scripts. These exclusions are legitimate — auditors cannot review everything — but users should treat excluded components as unaudited, because they are.
- Upgradeability blind spots. If the system uses an upgradeable proxy, an audit of the current implementation says nothing about future implementations. Check whether upgrade authority sits behind a timelock and multisig. For how upgrade mechanisms get exploited, see Proxy Upgrade Attacks Explained.
A useful mental model: the scope section converts the question “is this protocol audited?” into “which parts of this protocol are audited?” The second question is the only one that has an answer.
Reading Findings and Severity Levels
Findings are typically graded Critical / High / Medium / Low / Informational. These grades estimate impact if exploited, not likelihood of exploitation:
| Severity | Typical meaning | How to react |
|---|---|---|
| Critical | Direct, realistic loss of funds | Unfixed in deployed code = walk away |
| High | Loss under specific conditions | Must be fixed and re-verified |
| Medium | Limited, temporary, or indirect impact | Understand the mechanism before depositing |
| Low | Edge-case bugs, gas waste | Low concern, but note patterns |
| Informational | Code quality, centralization notes | Read these — they often describe real risks |
Three reading mistakes to avoid:
Mistake 1: Counting only Critical findings. A report with zero Critical and twelve High findings is not a clean report. High findings describe realistic loss paths under specific conditions — in DeFi, specific conditions arrive eventually.
Mistake 2: Treating a long Informational list as dirt. Informational findings often just document centralization keys or known trade-offs. That is candor, not sloppiness. Conversely, a report with zero findings of any severity can indicate a shallow review — real code always has something to say.
Mistake 3: Ignoring fix status. A finding marked “Acknowledged” is a finding the project chose not to fix. Sometimes that is defensible (low impact, high fix cost). Sometimes it is the vulnerability that gets exploited later. The pattern to check: are unresolved findings concentrated in access control or fund-movement paths? Those are the ones that end lives.
To go deeper on the classes of bugs that show up in findings tables, read Reentrancy Attacks Explained and Oracle Manipulation in DeFi — understanding two or three canonical bug classes makes finding descriptions dramatically easier to parse.
The Four Questions No Audit Answers
Reports disclaim this in fine print, so make it explicit. An audit does not tell you:
- Whether the deployed code matches the audited code. Verification is your job — check the contract address against the audited commit hash via the block explorer.
- Whether keys are safe. Admin keys, upgrade keys, and oracle operator keys are usually out of scope. Multi-sig and timelock arrangements are governance questions, not audit questions. Centralized key control is one of the most common red flags in otherwise-audited protocols.
- Whether future code will be safe. Post-audit changes are unaudited by definition. Continuous audit coverage (re-audits on every upgrade) is a strong positive signal; a single audit from two years ago is a weak one.
- Whether the team is honest. Audits review code, not intentions. Insider rug paths — mint functions, pause powers, withdrawal asymmetry — may be fully visible in an audit and fully intended by the team.
For projects that take security seriously, audits are one layer among several: a public bug bounty program, formal verification on critical paths, timelocked admin actions, and incident response plans. A protocol with an audit and none of the rest is safer than one with nothing, but not by as much as its marketing implies.
A 10-Minute Checklist Before Trusting an “Audited” Project
Run this before any meaningful deposit:
- Open the actual report — not the badge. If the full report is not publicly reachable, treat the audit as unverified.
- Note the auditor name and date. Check the engagement size: a two-day review and a three-week review are different products.
- Compare the scope’s commit hash with the deployed contract. Mismatch = the audit does not cover live code.
- List what the scope excludes. Ask whether excluded components touch user funds.
- Count findings by severity, then check the status of every Critical and High: Fixed and re-tested, or Acknowledged?
- Check upgrade mechanics: proxy? timelock? multisig? Who can change the rules, and how quickly?
- Look for a live bug bounty program and its max payout — bounty size is a rough proxy for how much the project values finding bugs before attackers do.
- Check whether the audit firm itself has a reputation that survives scrutiny. Unknown firms produce reports that look identical to good ones.
- Cross-check on-chain: token flows, treasury composition, and holder concentration tell you things no document will. Start with How to Verify a Token Before Buying and How to Audit Your Wallet Activity.
- Re-run this checklist whenever the protocol ships an upgrade — an audit ages with the code it reviewed.
Where Reports Actually Live
Legitimate projects make reports easy to find: linked from the docs security section, in the GitHub repository, or on the auditing firm’s own site under published engagements. Bookmark the report itself rather than the project’s claims page — the PDF cannot be quietly edited the way a website can, and firms keep their published lists independent of the projects.
If you can only find the badge and never the document, you have learned everything the project wanted you to know — and nothing you needed to know.
Limitations of This Guide
Reading an audit report well does not make you a security researcher. It makes you a harder target for lazily-marketed risk. You can still be fooled by a competent, fully-audited, intentionally malicious project — that failure mode requires on-chain monitoring and community diligence, not document literacy. Use this skill as a filter for obvious nonsense, then stack it with the other checks in your process.
Conclusion
Audit reports are one of the few genuinely free, information-dense artifacts in crypto security — most users just never open them. Scope tells you what the auditor saw. Findings tell you what they found. Fix statuses tell you what the project did about it. Everything else on the website is a compressed, curated version of those three facts. Ten minutes with the source document beats any badge.
Related Reading
- Contract Audit — what an audit engagement actually involves
- Bug Bounty — continuous security after the audit ends
- DeFi Protocol Red Flags — warning signs beyond audits
- Proxy Upgrade Attacks Explained — why upgradeability weakens audit guarantees
- Oracle Manipulation in DeFi — a canonical Critical-finding class
- Reentrancy Attacks Explained — the classic finding that keeps reappearing
- ERC-20 Token Security Check — hands-on verification workflow
Frequently Asked Questions
Does an audit guarantee a smart contract is safe?
No. An audit is a point-in-time review of a specific code snapshot by a specific team. It does not cover code changed after the audit, unaudited components, private key management, or infrastructure. Treat an audit as one signal among several — combine it with on-chain checks, timelocks, and monitoring.
What is the most important section of an audit report?
The scope section. It defines exactly which contracts, files, and commit hashes were reviewed. Everything outside that scope is effectively unaudited, no matter what the marketing page claims. Always match the audited commit hash against the deployed contract address.
What do severity levels (Critical, High, Medium, Low) mean in an audit?
Severity estimates the worst-case impact if a finding is exploited: Critical usually means direct loss of funds, High means loss under specific conditions, Medium means temporary or limited impact, and Low/Informational cover best-practice and code-quality issues. Severity reflects impact, not likelihood.
Can a project be hacked even with zero Critical findings?
Yes. Attacks repeatedly occur through paths outside the audited scope: admin keys, upgradeable proxies, post-audit modifications, off-chain infrastructure, or cross-chain message verification. A clean findings table only covers what the auditor was asked to review.
Where can I find a project's actual audit report?
Legitimate projects link the full PDF or web report — not just a badge — in their documentation, GitHub repository, or security page. The report should name the auditing firm, the commit hash, and the date. If a project shows a logo but the report itself is not reachable, treat the claim as unverified.