Reading an audit report
- Author
- CRYPTO PORT Editorial
- Published
- Updated
- Reading time
- 6 min
In short
The first things to find in an audit report are which version and which files were reviewed, and whether the findings were fixed. The word 'audited' on its own tells you nothing. Code changed after the audit, anything outside the stated scope, and external dependencies all sit outside what the report covers.
Key points
- Read in order: version and commit reviewed, scope, severity of findings, fix status, changes since
- A report is a snapshot; it says nothing about later changes
- Anything marked out of scope means 'not examined'
- A report with no findings is not proof that there are no vulnerabilities
Definition
A document in which an external auditor records the issues found, their severity and their resolution, for a specified version of a smart contract's code.
Get the report from the right place first: the project's own documentation, or the auditor's published list of reports. Reading only a summary on a marketing page shows you the flattering parts. You can also check that the auditor named on the cover lists the same engagement on their own site.
Then identify what was audited. Reports normally open with the repository, the commit hash and the files covered. What you want to know is whether that version matches the contract running now. Comparing it against the deployed contract's verified source is ideal; at minimum, compare the audit date with the contract's deployment and upgrade dates.
Next read the scope statement. Most reports set out explicitly what was and was not covered. Commonly excluded: the front end, off-chain operations, key management, and dependencies such as external protocols and oracles. Out of scope does not mean 'nothing wrong there' — it means 'not looked at'.
Then work through the findings by severity. You will see critical, high, medium and low categories along with how the project responded. Whether each item is 'fixed', 'acknowledged' or 'under discussion' matters more than the count. An acknowledged finding means the risk is still there in what you would be using.
Finally, the limits. An audit is an examination within fixed time and scope, not a demonstration that no defects exist — audited protocols have been exploited afterwards more than once. And where code can be swapped after the audit, the reviewed version may no longer be the one running. The existence of a report is one input, not a guarantee.
Watch out for
- · The label 'audited' reveals neither the version nor the scope. Read the report itself
- · If the code was changed or upgraded after the audit, the report no longer describes it
- · Fabricated reports citing real auditors exist. Cross-check against the auditor's own published list
Frequently asked questions
Are multiple audits safer?
More eyes help, but they do not guarantee anything. What matters is whether the audited version matches what runs now, how far the findings were fixed, and what was left out of scope. Read the contents rather than counting reports.