What a Smart Contract Audit Does and Does Not Tell You
"Audited" is used as a binary safety claim. It is not one, and the useful information is in details that the badge deliberately omits.
The short version
- An audit covers a specific commit. Code shipped afterwards is unaudited.
- Scope is the most important section and the least read.
- Unresolved and acknowledged findings matter more than resolved ones.
- "Audited by" with no linked report is not a claim, it is decoration.
Audit badges are used in crypto marketing as a proxy for safety, which is a category error. An audit is a time-boxed review of a specific artefact by people with finite hours. It is evidence, and reading it properly gives you real information — but almost none of that information is contained in the word “audited”.
What an audit actually is
A group of specialists reads your code for an agreed number of weeks and writes down what they found. That is the entire product. It is genuinely valuable — good auditors find things teams have stared past for months — and it is not a certification, a guarantee, or a statement that the system is safe.
The distinction matters commercially as well as technically. An audit is evidence you can show a counterparty. A badge with no linked report is not evidence of anything, and treating the two as equivalent is how “audited” became a marketing word rather than a technical one.
Scope is the whole thing
Every report states what was reviewed. It is the section that matters most and the one nobody reads.
Scope is typically a list of files at a specific commit hash. Anything not in that list was not looked at. This routinely excludes the deployment scripts, the off-chain components, the oracle integration, the governance contracts and any dependency — which is to say, it frequently excludes where the failure will occur.
The commit hash is equally important. An audit covers the code as it existed at that commit. If the team shipped changes afterwards — and they nearly always do — that code is unaudited, whatever the badge says. Comparing the audited commit against what is actually deployed is a check anybody can perform and almost nobody performs.
Read the findings that were not fixed
Resolved findings tell you the process worked. The informative section is the one listing issues marked acknowledged, disputed or risk accepted.
Acknowledged means the team read it and chose not to change anything. Sometimes that is entirely reasonable — a theoretical issue with an impractical precondition. Sometimes it is a live risk the team decided to carry, disclosed in a document nobody reads. The reasoning is usually printed alongside it, and the quality of that reasoning is one of the better signals available about the team.
Centralisation findings deserve particular attention, because they are the most commonly acknowledged and dismissed. “The owner can pause withdrawals” marked as acknowledged is not a formality; it is a description of the actual trust model.
Severity is not standardised
There is no shared definition of “high” or “medium” across firms. One auditor’s high is another’s medium, and severity is frequently a negotiation between auditor and client. Comparing severity counts across reports from different firms tells you very little.
Read the description of each finding rather than the label.
What an audit structurally cannot catch
Economic design flaws. Code that does exactly what it was specified to do, where the specification is exploitable. Most audits review implementation against intent, not intent against reality.
Emergent interactions. A contract can be individually sound and unsafe in composition with a protocol that did not exist at audit time.
Off-chain failure. Compromised keys, a bad deployment, a misconfigured multisig, an oracle that behaves fine until it does not.
Governance capture. Contracts working precisely as designed while control of them changes hands.
Questions worth asking
Is the full report published, or only a badge? What commit was audited and does it match production? What is in scope and, more usefully, what was excluded? How many findings were acknowledged rather than fixed, and what was the reasoning? Was there a re-review after the fixes, or is the report pre-fix? How long did the engagement run — a two-day review of a large codebase is a different product from a four-week one.
A team that publishes the full report including the uncomfortable findings is telling you something more valuable than the audit itself.
Keep reading
Related from the newsroom
Smart Contract Upgrade Patterns and How They Fail
How proxy upgrade patterns work, the storage collisions and initialiser bugs that break them, and why the admin key is the real…
Leave a comment