How to read a smart contract audit report (without being an auditor)

By Orivions Team · October 18, 2026

Key takeaways

Start with the scope: which programs, at which commit, and what was out of scope.
Severity levels rank impact and likelihood; read the auditor’s own definitions.
"Resolved", "acknowledged" and "partially resolved" mean very different things.
A fix review confirms the fixes; without it, the report describes code that no longer exists.
Audited means this commit, this scope, this time. Check that it matches what is deployed.

"Audited by a reputable firm" appears on many landing pages. Whether that means much depends on what is inside the report. You do not need to be an auditor to read one well; you need to know where to look. This guide walks through a typical Solana audit report from top to bottom.

1. Scope and commit

The first pages say what was reviewed: which programs, at which commit hash, over which dates, and what was explicitly out of scope. This is the most important section. Anything not listed, such as the frontend, off-chain keepers, oracles or later upgrades, was not audited, however the report is marketed.

2. Severity levels

Critical: funds can be stolen or permanently locked, or the protocol can be taken over, usually with little effort.
High: serious loss or breakage under realistic conditions.
Medium: real but limited impact, or requiring unusual conditions.
Low and informational: hardening, best practices and code quality. Worth fixing, rarely urgent.

Every auditor defines these levels slightly differently, and most include their definitions in the report. Read them before comparing reports from different firms.

3. Finding statuses

Resolved: fixed, and the fix was checked by the auditor.
Partially resolved: the risk was reduced but not removed. Read the remaining risk.
Acknowledged: the team chose not to fix it, usually with an explanation. Not the same as resolved.
Unresolved or open: no fix and no accepted explanation at the time of the report.

The fastest useful check: scroll to the summary table and look for any critical or high finding that is not "resolved". If there is one, read it and the team's response before you rely on the code.

4. The fix review

Findings are fixed after the main review, so a good report includes a fix review: the auditor checks the fixes at a later commit and updates the statuses. A report without one describes code that has since changed. Ask which commit the final version of the report covers.

5. Does it match what is deployed?

The last step connects the report to reality. The deployed program should come from the audited (and fix-reviewed) commit, ideally through a verifiable build that anyone can check. Changes after that commit, including upgrades, are not covered unless they were reviewed too. More on this in the Solana pre-launch security checklist.

Red flags in a report

No commit hash: there is no way to tell what was actually reviewed.
Only generic findings: a list of best practices with nothing specific to the program suggests a shallow review.
Very short review for complex code: a large DeFi protocol reviewed in a couple of days deserves questions.
The report is not on the project’s or auditor’s own channels: reports should be verifiable at the source.

Choosing an auditor? Read how to choose a Solana smart contract auditor and what drives audit cost.

Frequently asked questions

What do critical, high, medium and low mean in an audit report?

They rank findings by impact and likelihood. Critical and high usually mean funds can be stolen or locked, or the protocol broken; medium means real but limited damage; low and informational are hardening and code-quality notes. Each auditor defines the levels in the report, so read their definitions.

What does "acknowledged" mean on an audit finding?

The team saw the finding and chose not to fix it, usually with an explanation. It is not the same as "resolved". Acknowledged critical or high findings deserve a careful look before you rely on the code.

How do I know the deployed program is the audited code?

Check that the report names the commit, that every finding is resolved or explained in a fix review, and that the deployed program has a verifiable build pointing at that commit or a later reviewed one.

Need an audit you can rely on?

Describe your program and timeline. Smart Match suggests verified Solana security firms with a reason for each match. Free for teams.

Find an auditor →