What a smart contract audit does and does not tell you

“Audited” appears on landing pages as though it were a certification with a defined meaning. It is not. It is a professional service with variable scope, and the difference between a thorough review and a cursory one is invisible from the badge.

What an audit actually is

A firm is engaged to review a specified set of contracts at a specified commit, over a specified period, looking for defects against a specified threat model. They produce a report listing findings by severity, the project responds, and a final report usually records what was fixed.

Every word of “specified” there is doing work. The scope is negotiated, and a report on three contracts says nothing about the fourth that holds the funds.

Read the scope section first

The scope tells you which files were reviewed and at which commit hash. Two questions follow, and both are answerable in a few minutes.

Does the scope include the contracts that actually hold or move value, or only peripheral ones? And does the reviewed commit match what is deployed? Code changes after an audit, and a report against a commit from before several upgrades describes software that no longer exists. Verifying deployed bytecode against the audited source is the check that closes this gap, and it is rarely done by anyone reading the badge.

Findings and their resolution

Reports classify findings by severity. What matters more than the counts is the resolution: fixed, acknowledged, or disputed.

“Acknowledged” means the project read the finding and chose not to change anything. That can be entirely reasonable — the finding may describe an accepted trade-off — but it means a known issue is live, and it will not appear in a summary that only reports the badge.

A report with no findings at all is not a triumph. It usually means a narrow scope or a shallow review. Competent reviews of non-trivial systems find things.

What audits are structurally poor at

Certain categories are hard to catch by reviewing code:

• Economic design flaws. Code that behaves exactly as written, where the incentives it creates are exploitable. This requires modelling the system’s economics, which is a different discipline and frequently out of scope.
• Composability. A contract can be sound alone and unsafe when combined with another protocol nobody anticipated.
• Oracle assumptions. Contracts relying on external price data inherit the reliability of that data, and the oracle is usually outside scope.
• Governance and keys. An upgradeable contract controlled by a small multisig has a risk that no code review addresses, because the code permits the upgrade by design.

That last one deserves emphasis. If a contract can be upgraded, the audit describes the current implementation and the holders of the upgrade keys can replace it. What matters then is who those holders are and what process governs them — a governance question wearing a technical badge.

What a good report looks like

Published in full rather than summarised. Scope stated with commit hashes. Findings with severity, description and resolution. A methodology section describing what was and was not examined. And a date, so you can compare it against the deployment history.

A project publishing all of that is doing something meaningfully different from one displaying a logo. The logo is the part that costs least.

How to use one

Treat an audit as evidence that a project spent money on scrutiny and was willing to publish the result, which is a real signal about how it operates. Do not treat it as a guarantee of safety, because the report does not claim to be one — the disclaimer in it usually says so explicitly, in the section nobody quotes.

The practical questions remain: what proportion of your holdings is exposed to this contract, could you tolerate losing it, and is the yield being offered plausibly compensation for that risk? Those are unchanged by the presence of a report, which is exactly why the badge is used the way it is.

Not all reviews are the same depth

“Audit” covers a range of activity with very different cost and rigour, and the report does not always make the distinction obvious.

A manual review by experienced engineers reading the code is the expensive end. Automated analysis catches known patterns cheaply and misses anything novel. Formal verification proves mathematically that code satisfies a specification, which is powerful and only as good as the specification. Competitive audit platforms crowdsource review, which finds a wide range of issues but produces less consistent coverage.

Each has a role. What matters is knowing which you are looking at, and the methodology section says so. A report that does not describe its method is asking to be taken on the strength of the logo.

Bug bounties tell you something a report cannot

An audit is a snapshot; a bug bounty is continuous. A project running a substantial, well-scoped bounty with a public payout history is exposed to ongoing scrutiny in a way that a one-off review does not provide.

The size matters. A maximum payout far below what an exploit would yield is not an incentive, it is a gesture — a researcher who finds a critical flaw in a contract holding a large sum faces an obvious arithmetic problem if the bounty is trivial by comparison. Bounties scaled to the value at risk are a genuine signal about how seriously a project takes the possibility that it is wrong.

Time in production is evidence too

Contracts that have held significant value for a long period without incident have been subjected to the most rigorous review available: sustained attention from people financially motivated to break them.

This is not proof — dormant flaws exist and several long-lived protocols have failed late. But a recently deployed contract with a report and no operating history has been reviewed by one firm for a few weeks. An older one with the same report has additionally survived years of adversarial interest, and that is a different quality of evidence.

Combining the two is the practical approach: read the report for what was examined, and weigh the deployment history for what the report could not cover.