How to Read a Smart Contract Audit Report
Quick answer. Check the reviewed commit and files, the severity definitions, the status of every High and Critical, and the fix review. Then confirm deployed code matches: a report shows what was checked, not that a protocol is safe.
Video transcript
An audit report shows what was checked, not that a protocol is safe. Here is how to read one in five minutes.
Start with scope. A commit hash pins the exact code the auditors read. Anything not listed was not reviewed.
Watch for gaps: oracles and bridges, deployment scripts, offchain keepers, and code changed after the final commit.
Read severity definitions before counting Criticals. Guardian rates impact against likelihood, so a High can be a severe bug that is hard to trigger.
Then check each status. Resolved means fixed. Partially resolved leaves some risk. Acknowledged means no fix recorded here. An acknowledged Critical with no reason should be treated as live.
Fixes are new code. In Guardian's GMX report, the first remediation review recorded six new findings, including a Medium.
Every report has a disclaimer: no endorsement, and no guarantee the code is bug-free. As ethereum.org puts it, audits won't catch every bug.
The quick checklist: a commit for every round, scope covering fund-holding code, Highs and Criticals resolved or explained, a fix review, and a final commit matching deployed code.
Guardian publishes its reports publicly, 320 so far, each listing every finding with its severity and status.
Read the full guide for worked examples, or talk to Guardian about an audit you can verify at guardian.security.
An audit report is the main public evidence that a protocol’s code was checked. It is also easy to misread.
A report covers one codebase, at one commit, over a fixed window. Code changed after that sits outside it.
This guide walks through each part of a report, what to check and the red flags. The worked examples are Guardian’s public reports.
Start With Scope and Commit
The scope says what was reviewed. Read it before any finding.
The commit hash
A commit hash pins the exact code the auditors read. Without one, nobody can show that the deployed code is the reviewed code.
Good reports name a commit for every round. Guardian’s GMX Just-in-Time Liquidity report lists four: the main review and three remediation reviews, all in GMX’s public repository.
The files
Next, the file list. Guardian’s Callisto report names 17 files and 4,245 nSLOC (normalized source lines of code), with a commit for each round.
Check that the list includes every contract that holds funds, mints tokens, sets prices or controls upgrades.
What is out of scope
Anything not listed was not reviewed. Look for these gaps:
- Oracles, bridges and other external dependencies
- Deployment scripts and initial configuration
- Offchain keepers, relayers and admin tooling
- Code changed after the final commit
If the risky code sits outside the scope, the report says nothing about it.
Methodology and Severity
Methodology
The methodology says how the auditors looked: manual review, static analysis, fuzzing or formal verification.
Check that it fits the code. Accounting-heavy protocols benefit from invariant fuzzing, which tests safety properties across many random states.
Guardian’s Strata Tranches report lists static analysis, manual review, a test suite and contract fuzzing. Its table shows 14 invariants, each run 10 million+ times.
Read the columns, not just the count. One invariant failed in the main review, then passed after the fix.
Severity definitions
A severity label means what that report defines it to mean. Read the definitions before counting Criticals.
Recent Guardian reports rate impact against likelihood:
| Likelihood | High impact | Medium impact | Low impact |
|---|---|---|---|
| High | Critical | High | Medium |
| Medium | High | Medium | Low |
| Low | Medium | Low | Low |
So a High can be a severe bug that is hard to trigger. Compare reports on their definitions, not their counts.
Our guide to smart contract audit severity levels covers how auditors weigh the two.
Findings and Their Status
Each finding carries a severity, a status and often a resolution note. The status records what the team did about it.
| Status | What it means | What to check |
|---|---|---|
| Resolved | A fix was made | Which commit holds it, and whether it was reviewed |
| Partially resolved | Some of the risk remains | What is left, and why |
| Acknowledged | No fix recorded in this report | The team’s stated reason |
| Pending or reported | No final status yet | Whether a later report closes it |
Acknowledged can reflect a design decision or a fix made later. Read the resolution note.
An acknowledged Critical needs a written reason. Without one, treat the bug as live.
Privileged roles
Look for findings about owners, admins, upgrade keys and pausers. A team may accept these as design, which moves the risk to whoever holds the keys.
Guardian’s disclaimer says it plainly: “active smart contract owner privileges constitute an elevated impact to any smart contract’s safety and security.”
For worked examples of individual findings, see six smart contract audit findings explained.
The Fix Review
Fixes are new code. A fix review checks them, and it can turn up new bugs.
In the GMX report, the first remediation review recorded six new findings, including a Medium.
Check three things:
- A fix review round with its own commit
- Which fixes it covered, and which it did not
- The confidence or verdict note that follows
Good reports also say what was left unreviewed. The Strata report notes that fixes to findings from its remediation round “have not been reviewed by Guardian.”
It then names the next step: an independent review “at a finalized frozen commit” before deployment. The Strata team accepted that advice.
Guardian’s newer reports also score confidence from 1 to 5. The GMX report scores 4, which the scale defines as “suitable for deployment after remediations; consider periodic review with changes.”
Disclaimers and Later Changes
Every report carries a disclaimer. Read it as a statement of limits. Guardian’s says a report:
- Is not an endorsement of the project
- Gives no guarantee that the code is bug-free
- Could include false positives and false negatives
- Should not be used to make investment decisions
Ethereum.org makes the same point: “Smart contract audits won’t catch every bug.”
Later changes
Compare the report’s final commit with what is deployed. If the contracts changed afterward, the report does not cover the changes.
Check verified source on a block explorer against the final reviewed commit, and follow any proxy to its current implementation. Our study of deployed vs audited code shows how.
A Five-Minute Checklist
Run these checks on any report before you rely on it:
| Check | Red flag |
|---|---|
| A commit hash for every round | No commit hash |
| Files cover the fund-holding code | Scope leaves out the risky code |
| Severity definitions are stated | Counts with no definitions |
| Every Critical and High resolved or explained | “Acknowledged” Criticals with no reason |
| A fix review with its own commit | No fix review |
| Final commit matches deployed code | A report older than the deployed code |
| Report on the auditor’s own site or GitHub | Only a PDF on the project’s site |
Guardian’s Public Reports
Guardian publishes its reports in a public portfolio, 320 so far. Each report page lists every finding with its severity and status, and links the full PDF.
Vanguard, Guardian’s enterprise audit, includes six months of update review after production, up to 2,500 onchain SLOC. Changes to the same scope keep getting reviewed.
Risk Monitoring then tracks “whether the configuration running today is the one that was reviewed.”
Frequently Asked Questions
What is the most important part of an audit report?
The scope and commit. They define what the auditors actually reviewed. Every finding, status and verdict in the report applies only to that code at that commit.
Does an audit report mean a protocol is safe?
No. It shows which code was reviewed and what was found. Guardian’s disclaimer gives no guarantee the code is bug-free, and ethereum.org notes audits won’t catch every bug. Check later changes, admin keys and offchain systems too.
What does acknowledged mean in an audit report?
No fix was recorded for that finding in the report. It can reflect a design decision or a later fix, so read the resolution note. An acknowledged Critical with no stated reason is a red flag.
How do I check that deployed code matches the audit?
Find the final reviewed commit in the report. Compare it with the verified source on a block explorer, following any proxy to its current implementation. Check again after every upgrade.
Sources
- Guardian: GMX Just-in-Time Liquidity Security Review (November 5, 2025)
- Guardian: Strata Tranches Security Review (October 10, 2025)
- Guardian: Callisto Security Review (December 3, 2025)
- ethereum.org: Smart contract security (updated October 22, 2026)
- Guardian: Public audit portfolio
- Guardian: Vanguard
- Guardian: Risk Monitoring
Get an audit you can verify
Vanguard puts two independent teams on your scope, then keeps reviewing updates for six months after production.