How to Review a Smart Contract Audit Claim
A checklist for locating the actual report, scope, date, version and unresolved findings.
This article may contain affiliate links. Commercial relationships are disclosed in the affiliate policy.
An audit claim is usually a badge, a sentence in a pitch deck, or a line in a project documentation page: “audited by a recognised firm.” That sentence carries almost no information on its own. The useful question is not whether an audit happened, but whether a report exists that you can read, whether its scope covers the code you are about to interact with, and whether the findings relevant to your use case were fixed. This guide walks through how to check each of those things yourself.
Separate four things that get called “the audit”
Most confusion comes from collapsing four distinct items into one word.
- The firm. Who performed the review, and whether the name is verifiable.
- The report. Whether a document actually exists, and whether it is public or gated behind a request to the team.
- The scope. Which contracts, which commit, and which version were actually reviewed.
- The findings. What the reviewers flagged, and whether those findings were fixed.
A project can have a reputable firm, a real report, and a scope that excludes the exact contract a user interacts with. In that case the badge is genuine and still tells you almost nothing about your use of the protocol.
Step 1 — Establish whether a report exists
Start from the report, not from the firm’s logo. Look for a link to a document, a public repository entry, or a verification page. Then check the date. An audit of a codebase from two years ago describes code that has probably been modified since, and modifications after an audit are the normal case rather than the exception.
Also check whether the report names the project at all. Reports get reused and misattributed more often than people expect, and a report whose title belongs to a different protocol proves nothing.
Step 2 — Read the scope before the findings
The scope section tells you what was and was not reviewed. Look for the commit hash, the branch, and the contract addresses included in scope. Then compare those addresses with the contract the application currently uses. A common pattern is that the reviewed contract is the previous deployment, while the live address was upgraded afterwards. In that case the audit describes code that is no longer running, which is worth confirming before relying on it.
If the scope mentions a specific token, pool, or oracle, note it. Audits are frequently written for one market or one deployment and say nothing about the others.
Step 3 — Treat findings by what the code does
Findings usually fall into a few broad shapes: access control issues, unchecked external calls, reentrancy exposure, oracle and price assumptions, and arithmetic edge cases. Rather than counting them, check which ones touch the path you will use. A finding in a function you will never call matters far less than a medium-severity issue in a withdrawal or mint path.
Two questions are worth asking for every finding you consider relevant: is it fixed, and is the fix verifiable? A project saying a finding is resolved is a claim in the same category as the audit badge. A verifiable fix shows up in the code, often in a change you can inspect, or in a later report that explicitly addresses it.
Step 4 — Note what an audit cannot tell you
An audit is a point-in-time review of a specific piece of code by a specific team. It is not a guarantee, and it does not cover economic design, governance decisions, oracle failure outside the reviewed logic, or the possibility that a later code change reintroduces an old problem. Projects that describe an audit as a guarantee of safety are making a claim that the report itself does not support.
Recording your conclusion
Write down the report link, the date, the scope, and which findings affect the path you plan to use. That note makes the review reproducible, and it lets you notice when the situation changes: a new report, a new deployment address, or a new finding on a previously reviewed contract. Without a record, an audit check tends to become a one-time impression that cannot be revisited later.