Smart Contract Audits: What They Prove and What They Don't

What an audit actually is

A team engages a security firm for a fixed period — often one to four weeks — to review an agreed scope of code. Researchers read it, reason about how components interact, write tests and attack hypotheses, and produce a report: findings graded by severity, each with a recommendation and usually a note on the team's response.

Skilled work, and worth doing. But note the structural facts, because every limitation follows from them: fixed time, agreed scope, a specific commit, and human judgement. There is no standard, no pass mark and no licence at stake. "Audited" means someone was paid to look. It does not say who, for how long, at what, or what they found.

The four gaps

1. Scope

Reports state what was reviewed and, more revealingly, what was not. Excluded items are routinely the interesting ones: oracle configuration, governance and admin processes, off-chain components, economic assumptions, and dependencies on external protocols. A protocol can be fully audited within its scope and lose everything to something the scope explicitly excluded — and the report said so, on page two, where nobody reads.

2. Time

Attackers are not time-boxed. An auditor has weeks and a checklist of known classes; an attacker has as long as they like and an incentive proportional to the value locked. Once a protocol holds serious value, the adversary's effort budget exceeds the auditor's by a wide margin, and it keeps growing.

3. The commit

This is the gap that catches the most people. An audit covers one exact version of the code. Protocols upgrade, add markets, change parameters, deploy on new chains. None of that is covered by the earlier report, and the badge on the website does not change.

So the first thing to check is not whether an audit exists but whether the audited commit hash is what is actually deployed. Frequently it is not, and frequently nobody has looked.

4. Economics

Most audits examine whether the code does what it is meant to. Far fewer examine whether what it is meant to do is a good idea. An incentive design that unravels under stress, a redemption mechanism that is reflexive in a falling market, a reward token with no demand beyond the reward — all of these can be implemented flawlessly. Correct code, broken system, and the report was right about everything it checked. This category is covered further in DeFi risks.

How to read a report

Ten minutes on the actual document is worth more than any amount of looking at logos on a landing page:

1. Date and commit hash. Compare to what is deployed now. A mismatch is the finding.
2. Scope section. Read what was excluded. This is usually the most informative page.
3. Critical and high findings. Their presence is normal and healthy — complex code has bugs, and finding them is the point.
4. The resolution column. What matters is whether each was fixed, and the fix verified. "Acknowledged" means the team read it and chose to ship anyway — sometimes reasonable, always worth knowing.
5. Findings marked "won't fix" or "disputed". These are where the auditor and team disagreed about risk. Read them closely; you may side with the auditor.
6. Centralisation findings. Almost every report notes admin keys with significant power. Nearly everyone skips these, and they describe exactly who can take your funds without exploiting anything.

Stronger signals than an audit

Not replacements — additions, and several carry more weight:

• Time under load. A protocol that has held significant value through a violent drawdown has evidence. A new one has assumptions. This is the single best signal available and it cannot be bought.
• A funded bug bounty. A bounty large enough to outbid an exploit converts would-be attackers into reporters, and applies continuous adversarial attention to live code rather than a snapshot. Check that it pays meaningfully relative to value at risk — a $50k cap on a protocol holding $200m is not a deterrent.
• Timelocks. If privileged changes take effect after a delay, users can exit. This constrains both a malicious team and a compromised key, and it is verifiable on-chain rather than asserted.
• Immutability. Non-upgradeable contracts cannot be changed against you. The trade is that bugs cannot be patched either — a real trade, not a free win.
• Formal verification. Proof that code satisfies a specification. Much stronger than review within its scope, and narrow: a correct proof of a wrong specification is still a broken protocol.
• Published incident history. A team that has documented a past failure honestly, including what they got wrong, is demonstrating something no audit can.

The takeaway

Treat "audited" as the beginning of the question. The useful version is: audited by whom, when, against which commit, with what excluded, which findings were disputed, and what has changed since. That takes ten minutes and is the difference between using a signal and being reassured by a badge.