How to Read a Smart Contract Audit Without Being a Developer

“Audited by” appears on nearly every protocol’s landing page, usually as a row of logos. Treated as a badge, it conveys almost nothing. Treated as a document to be read, an audit report is one of the most informative things available about a protocol — and reading it usefully does not require the ability to write Solidity.

Here is what to look at, roughly in order of importance.

1. Scope — read this before the findings

Every serious report opens with what was examined. This section is more important than the findings, and it is the section people skip.

Which commit? Audits examine a specific revision, identified by hash. If the team shipped changes afterwards, those changes are unaudited. A report against a commit that is not the deployed one describes code that no longer exists.

Which files? Reports list the contracts in scope. Anything absent was not looked at. It is entirely normal for an audit to cover the core vault while excluding the governance module, the price oracle adapter, or the upgrade mechanism — and equally normal for the excluded component to be where the risk actually lives.

What kind of review? A two-week manual review, an automated-tooling pass, and a formal verification of specific properties are very different products that all get called “an audit.”

If the scope section is vague or missing, that is itself the finding.

2. The severity taxonomy

Most firms use some variant of critical / high / medium / low / informational. The labels combine two things: how bad the outcome would be, and how plausible it is that someone triggers it.

• Critical — funds can be taken or permanently frozen, on a path an attacker can realistically reach.
• High — serious loss under conditions that are somewhat constrained.
• Medium — real harm requiring an unusual state or a privileged actor misbehaving.
• Low — genuine defects with limited impact.
• Informational — style, gas efficiency, clarity. No security consequence.

Firms are not consistent with each other. The same issue can be high at one firm and medium at another. Compare severities within a report, not across reports from different auditors.

3. Status — the field that actually matters

Findings carry a resolution: fixed, mitigated, acknowledged, or won’t fix.

“Acknowledged” means the issue is still there. The team read it and chose not to change the code. Sometimes that is entirely defensible — a documented tradeoff, a risk accepted deliberately. Sometimes it is not.

An acknowledged critical or high finding is the single most important thing in a report, and it is easy to miss because it sits in a table cell rather than in a headline. Go looking for it specifically.

Where fixes were applied, check whether the auditor re-reviewed them. A fix verified by the auditor and a fix the team says it made are different levels of assurance, and reports are usually explicit about which one you are getting.

4. Centralisation findings

Nearly every report contains findings about privileged roles: an admin key that can upgrade contracts, pause withdrawals, change fee parameters, or alter the oracle.

These are frequently rated medium or informational, on the reasoning that they are intended behaviour rather than defects. From a user’s perspective the rating undersells them. “The owner can upgrade this contract” means your funds depend on the honesty and operational security of whoever holds that key, regardless of how sound the code is.

Read these findings for what they describe, not the label attached. Then look for the operational answer: is the key a multisig, is there a timelock giving users a window to exit before a change takes effect, is the holder disclosed?

5. What an audit structurally cannot cover

• Economic design. Code can be flawless while the incentives are exploitable. Oracle manipulation, liquidation cascades, and governance capture usually live here.
• Dependencies. Integrations with other protocols are typically out of scope, but a protocol that composes with another inherits its failures.
• Off-chain infrastructure. The front end, the deployment keys, the domain registration. Users have lost funds to compromised websites in front of perfectly sound contracts.
• Post-audit changes. The report is a snapshot. It ages the moment anything ships.
• Absence of bugs. Auditors sample under time pressure. They find what they find. Plenty of audited contracts have been exploited afterwards, and the auditors were not necessarily negligent.

A practical checklist

1. Find the report itself, not the logo. If it is not published, treat the claim as unsupported.
2. Compare the audited commit hash against what is deployed.
3. Read the scope for what was excluded.
4. Search the findings table for anything acknowledged or unfixed.
5. Check whether fixes were re-reviewed.
6. Read the centralisation findings on their substance.
7. Check the date, and ask what has shipped since.
8. Look for a live bug bounty — ongoing incentive to disclose is a meaningful complement to a one-time review.

A protocol with one thorough audit, published in full, honest about its acknowledged findings and running a serious bounty is in better shape than one displaying five logos and no documents. The badge is not the assurance. The report is.

Educational content only. Nothing here is financial advice.