“Audited” has become a marketing word, but a real smart-contract audit is a structured security review with clear scope and limits. Understanding what one does — and does not — cover protects you whether you are commissioning an audit or evaluating a protocol that claims to have one.
Key takeaways
- An audit reviews specific code at a specific commit — not the whole project forever.
- Look for methodology, severity ratings and a resolution log, not just a logo.
- No audit guarantees safety; it reduces, not eliminates, risk.
- Re-audits matter after any material code change.
Scope
A good report names the exact files and commit hash reviewed, the time spent, and the techniques used — manual review, static analysis, and sometimes formal verification or fuzzing.
Findings and severity
Issues are graded (critical, high, medium, low, informational). What matters most is whether critical and high findings were fixed and re-checked — a resolution log tells you.
What it cannot promise
Audits cover the code in scope at a moment in time. They do not cover later changes, economic/design exploits outside scope, key management, or governance risk.
Reading a report as a user
Check the date, the commit, whether the deployed contract matches what was audited, and whether high-severity issues were resolved. A logo with no report behind it is not evidence of anything.
Treat an audit as one input among several — not a guarantee.