Audit status is cited constantly as a security claim, and the actual scope of these reviews is narrower than the citation implies.
What an audit is
A time-boxed review of specified code by reviewers looking for defects.
Which is bounded by time, by the code included and by what the reviewers thought to look for.
It is not a guarantee and is not presented as one in the reports themselves.
Scope
Reports state which files and which commit were reviewed.
Which frequently excludes deployment scripts, off-chain components and dependencies.
Code changed after the audit is not covered, and this has been the cause of documented incidents.
Severity classification
Findings are graded, generally from critical down to informational.
Which is a judgement rather than a measurement, and classification varies between firms.
What matters more is whether findings were fixed and whether fixes were re-reviewed.
Acknowledged but not fixed
Reports frequently list findings the team accepted rather than resolved.
Which is a legitimate choice and is exactly what a reader should look at.
Accepted risks are stated openly in the report and are rarely mentioned in marketing.
Centralisation findings
Most reports include a section on administrative privileges.
Which describes what an owner or admin can do, including in the worst case.
This is generally the most practically important section and the least read.
What audits do not catch
Economic design flaws, oracle dependencies, governance attacks and interactions with contracts deployed later.
Which have caused a substantial share of losses at audited protocols.
Reviewers examine the code as specified rather than the economic system it implements.
Formal verification and bounties
Verification proves specified properties mathematically and depends on the specification being right.
Bug bounties provide continuous incentive after deployment, and payout size determines whether they compete with exploitation.
Both complement audits rather than replacing them.
Reading a report
Check the date, the commit, the scope, the unresolved findings and the centralisation section.
Which takes twenty minutes and is considerably more informative than a badge on a website.
Competitive audit contests
Open competitions where many reviewers examine code for prize money.
Which produces broad coverage and variable depth.
Several protocols now use these alongside traditional engagements rather than instead of them.
Reviewer incentives
Firms are paid by the projects they review.
Which is the same structural issue that affects credit ratings and is generally managed by reputation.
Firms that have audited protocols which subsequently failed carry that record publicly.
Time and depth
Engagement length relative to code complexity is a meaningful quality indicator.
Which is stated in most reports.
A short review of a large complex codebase covers less than the word audit implies.
Post-deployment monitoring
Continuous monitoring for anomalous activity complements pre-deployment review.
Which several protocols now operate with automated response capability.
Detection speed has determined the size of losses in multiple incidents.
What to conclude
An audit reduces risk and does not remove it, and its value depends entirely on scope, depth and what was done with the findings.
Dependencies
Contracts inherit from libraries and interact with external protocols.
Which extends the risk surface beyond the code reviewed.
A well-audited contract depending on an unaudited one inherits that exposure.
Deployment verification
Whether the deployed bytecode matches the audited source.
Which is checkable and is a step people assume rather than verify.
Mismatches have occurred, sometimes innocently through compiler settings and sometimes not.
Upgradeability
An audited contract that can be replaced by its owner provides limited assurance about future behaviour.
Which is why the centralisation section of a report matters as much as the vulnerability findings.
Timelocks on upgrades are what convert this from a trust assumption into a monitorable one.
Testing coverage
Reports frequently comment on test suite quality.
Which is a reasonable proxy for engineering discipline.
Low coverage on a protocol handling substantial value is a meaningful signal.
Practical use
Read the scope, the unresolved findings and the privileges section, and check the deployed code matches.
Reading between reports
Multiple audits by different firms cover more than one, and overlapping findings indicate genuine issues.
Which is why serious protocols commission several.
The absence of any audit on a protocol holding substantial value is a straightforward warning.
Closing
The badge means little and the report means a great deal, and the difference is twenty minutes of reading.
Who commissions the review
An audit commissioned by the project differs in incentive from one commissioned independently.
Which is the standard arrangement and is worth naming.
Reputable firms decline to soften findings, and the market for reputation is what enforces this.
Where to find reports
Most are published openly by the audit firm or the project, and older reports remain available.
The most useful section of most reports is the one describing what an administrator can do, because that describes the ongoing trust assumption rather than a bug that was fixed before deployment.