How to Read a Smart Contract Audit Report

Audit reports are written for developers but read by founders, investors, and users — most of whom reasonably skip to the summary table, see mostly green, and move on. That is where the useful information gets missed. Here is how to actually read one.

Start with the scope, not the findings

Every credible report opens with what was reviewed: which contracts, at which commit hash, over what period. This is the single most important section and almost nobody reads it.

Check specifically:

• Does the commit match what is deployed? If the report covers a3f9c1 and mainnet runs something else, the report describes code that is not running.
• Which contracts were excluded? Exclusions are normal and legitimate. Silent exclusions are not.
• What is explicitly out of scope? Reports commonly exclude economic design, off-chain infrastructure, key management, and third-party dependencies. Those risks did not disappear; they were just not reviewed.
• How long did the review take? A large protocol reviewed in two days was skimmed.

What the severity ratings mean

Most reports use a variant of impact × likelihood:

• Critical: funds can be taken or permanently frozen, with no unusual preconditions. Fix before launch, no exceptions.
• High: serious loss or breakage, possibly requiring specific conditions or a privileged actor behaving badly.
• Medium: real impact under narrower conditions, or significant damage to functionality rather than funds.
• Low: limited impact, unlikely preconditions, or defence-in-depth.
• Informational: style, gas, and maintainability. Not security findings.

Ratings are judgement calls and they vary between auditors. What matters is whether the reasoning is shown. “High severity” with no explanation of impact and likelihood is an assertion, not an assessment.

Read the finding bodies, not the table

The summary table is the least informative part of the document. For any finding that matters, the body should give you a description of the flaw, the affected lines, a concrete attack path, and a specific fix. If a finding is exploitable, a good report includes a proof of concept — a test you can run.

Findings that say only “consider adding validation” without specifying what to validate or why are filler. A report made mostly of those is telling you how the review was conducted.

Status fields are where reports get misread

Each finding carries a resolution status, and the vocabulary is misleading if you take it at face value:

• Fixed / Resolved: changed and — ideally — re-reviewed. Check whether a retest actually happened, or whether the auditor simply recorded what the team told them.
• Acknowledged: the team read it and chose not to fix it. The issue is still present in the code. This is the field people misread most often.
• Partially fixed: some of the problem remains. Find out which part.
• Disputed: the team disagrees. Sometimes they are right. Read both arguments and decide for yourself.

A report showing three acknowledged mediums is not the same as a clean report, however similar the summary table looks.

What a “clean” report tells you

A report with zero medium-or-above findings is not automatically good news. It has three possible explanations, and you cannot tell them apart from the summary:

• The code genuinely is in excellent shape.
• The scope was narrow enough to contain nothing interesting.
• The review was shallow.

Distinguish them by reading the informational findings. A thorough reviewer who found nothing serious will still have plenty to say about assumptions, edge cases, and design trade-offs. A report that is thin everywhere, including the low-severity items, is thin because the review was.

Checking a report someone else commissioned

If you are evaluating a protocol as a user or investor:

• Verify the report exists on the auditor's site or GitHub, not only on the project's. Fabricated reports are a real phenomenon.
• Compare the audited commit against the verified source on the block explorer.
• Check the date. A report from before two major upgrades describes a system that no longer exists.
• Look at what was excluded from scope, then ask why.
• Search for acknowledged findings and judge whether you are comfortable with the risk the team decided to accept on your behalf.

What no report can tell you

An audit is a time-boxed review of a specific commit by a human with finite hours. It cannot prove the absence of bugs, it says nothing about who holds the admin keys today, and it does not cover the code shipped after it was written.

Read it as evidence that a competent outsider looked hard and reported what they found — which is genuinely valuable, and materially less than a guarantee. Anyone presenting an audit as proof of safety has either misunderstood the document or is counting on you to.

My own reports are published in full on the home page so you can apply all of the above before deciding whether to work with me. Related: how to evaluate an auditor.