How to Read a Smart Contract Audit Report

Reading a smart contract audit report means going beyond the headline claim that a protocol "has been audited" to actually check the specific findings, their assigned severity, and whether each one was fixed, partially addressed, or left unresolved before the protocol went live.

Many users treat an audit badge as a simple pass/fail signal, but the real value of an audit report lies in its details — a protocol can legitimately advertise "audited by [firm]" while still carrying unresolved high-severity findings, if the team chose not to fix them or plans to address them in a future update. Our companion guide on what a smart contract audit is covers what these reviews generally include and what they don't.

Key sections to look for

Scope. This defines exactly which contracts, files, or code versions the audit actually covered, along with the specific commit hash or version reviewed. A narrow scope — for example, covering only a core lending contract but not a newer, related module — means large parts of a protocol's live code may never have been reviewed at all.

Methodology. This describes how the audit was conducted, such as manual code review, automated static analysis, and any formal verification techniques used. A more thorough methodology combining multiple approaches generally provides stronger assurance than a single automated scan.

Findings list. Each identified issue is typically listed individually with a description of the vulnerability, its potential impact, and a severity rating. This is the heart of the report and the section most often skipped by readers who only check whether an audit exists at all.

Resolution status. For each finding, the report should indicate whether the project's team fixed it, acknowledged it without fixing it, disputed the finding, or left it unaddressed. This status is arguably more important than the initial finding itself, since an unresolved critical issue means the underlying risk is still live in the deployed code.

Understanding severity ratings

Severity	Typical meaning	What it implies for users
Critical	Could lead to direct loss of funds or complete contract compromise	Should be fully resolved before any real funds are at risk
High	Significant risk under plausible conditions	Warrants caution if unresolved; check for a fix before use
Medium	Meaningful risk under specific or less likely conditions	Worth noting, less urgent if isolated
Low	Minor issue, limited practical impact	Generally low priority
Informational	Best-practice suggestions, not a vulnerability itself	Not a safety concern on its own

Severity naming conventions vary somewhat between auditing firms, so it's worth checking how a specific report defines its own scale rather than assuming a universal standard.

Red flags to watch for within a report

• Any critical or high-severity finding marked as "acknowledged" or "won't fix" rather than resolved
• A scope that excludes contracts the protocol is actually using in production, such as newer modules added after the audit
• An audit conducted significantly earlier than the protocol's current deployed code, with no follow-up review of subsequent changes
• A report that is only summarized in marketing materials, with the full findings document unavailable or not published for independent review
• Only one audit ever conducted, with no periodic re-review despite ongoing development

A practical reading checklist

1. Confirm the audit's scope actually matches the contracts currently in use
2. Check the date and version reviewed against the protocol's current deployed code
3. Read the full findings list, not just a summary count of issues found
4. Pay closest attention to critical and high-severity findings and their resolution status
5. Check whether more than one independent firm has reviewed the code
6. Note whether the audit is fully published, rather than only referenced or summarized

How this fits into broader due diligence

Reading an audit report carefully is one component of a broader evaluation process, alongside checking team transparency, tokenomics, and real on-chain activity, as covered in our guide on vetting a new crypto project. It's also worth remembering the limits of any audit, discussed in more depth in what a smart contract audit is — even a clean report with no unresolved findings doesn't eliminate risks like economic design flaws or future upgrade bugs, the kind that contributed to incidents like the Nomad bridge hack.

Bottom line

An audit report is only as useful as the attention paid to its actual contents — the scope, the severity of each finding, and whether critical or high-severity issues were genuinely resolved rather than just acknowledged. Treat a protocol's "audited" claim as an invitation to check the details, not as a standalone guarantee of safety, and weigh unresolved high-severity findings as seriously as the absence of any audit at all.