What does a smart-contract audit actually prove?

"Audited by" appears on nearly every DeFi front page, in the same visual position a padlock occupies on a checkout page. It is doing similar work: signalling safety in a way that discourages further questions.

An audit is a time-boxed review, by people, of a named set of files at a named commit, against a defined scope. What it produces is a list of findings and their resolution status. What it does not produce — and what reputable auditors say plainly in their own disclaimers — is a guarantee of correctness.

Six limits worth knowing by name

1. Scope. The report states which files and which commit were reviewed. Deployment scripts, off-chain keepers, oracle configuration, the front end, and third-party dependencies are outside it unless explicitly named. Many losses occur in components that were never in scope and never claimed to be.

2. Commit drift. The audited commit and the deployed bytecode are two different objects. Confirming they correspond is a separate check that almost nobody performs, and it is the single highest-value fifteen minutes available to a careful user.

3. Upgradeability. If the contract sits behind a proxy with an admin key, the reviewed logic can be replaced afterwards by whoever holds that key. The audit's shelf life is then exactly as long as the admin chooses.

4. Economic design is frequently out of scope. A large share of DeFi losses are not code defects at all. The code executed precisely as written while the incentive design failed — an oracle that could be moved, a liquidation cascade, a peg mechanism that assumed liquidity would be there. Reviewing whether the mechanism is sound under adversarial market conditions is a different discipline from reviewing whether the code matches its specification.

5. Findings are not fixes. Reports carry a resolution column: fixed, partially fixed, acknowledged, disputed. A critical finding marked "acknowledged" means the team read it and shipped anyway. That is sometimes reasonable and always worth knowing.

6. Adjacent assurances cover different ground. Formal verification proves specific stated properties — and only those; a property nobody thought to state is not proven. A bug bounty prices external discovery, and its cap tells you what the protocol thinks a critical bug is worth relative to what an attacker could take.

A concrete shape

A protocol's audit report lists a medium-severity finding: the contract derives prices from a single on-chain pool. The team responds that the risk is mitigated by using a time-weighted average price, and the finding is marked acknowledged. Everything so far is normal, competent practice.

Months later the pool's liquidity has thinned, the cost of moving the time-weighted price for the required duration falls below the value extractable, and the contract is drained. The auditor identified the risk. The team responded reasonably. The report was accurate. The money still left, because the mitigation depended on a market condition that changed and that nobody was monitoring.

The audit was a snapshot of the code; the risk lived in the environment.

How to read one in ten minutes

Date and commit hash. Scope section — what was and was not reviewed. Count of critical and high findings, and the resolution status of each. Whether the contract is upgradeable and by whom. And the disclaimer, which will tell you in the auditor's own words that this is not a guarantee.

Try it now

1. Pick any protocol with a public audit report. Find the commit hash in the report, then check the deployed contract's verified source on a block explorer and see whether they correspond.
2. In the same report, count the critical and high findings and read the resolution status of each. Note any marked "acknowledged" rather than "fixed," and what the stated reasoning was.
3. Determine whether the contract is upgradeable. If it is, find the admin address, and if that admin is a multisig, find its threshold and signer count. You now know how much the audit's conclusions are worth going forward.