Skip to content
Smart ContractsANALYSIS

What a Smart Contract Audit Does and Does Not Tell You

"Audited" is used as a binary safety claim. It is not one, and the useful information is in details that the badge deliberately omits.

The short version

  • An audit covers a specific commit. Code shipped afterwards is unaudited.
  • Scope is the most important section and the least read.
  • Unresolved and acknowledged findings matter more than resolved ones.
  • "Audited by" with no linked report is not a claim, it is decoration.

Audit badges are used in crypto marketing as a proxy for safety, which is a category error. An audit is a time-boxed review of a specific artefact by people with finite hours. It is evidence, and reading it properly gives you real information — but almost none of that information is contained in the word “audited”.

What an audit actually is

A group of specialists reads your code for an agreed number of weeks and writes down what they found. That is the entire product. It is genuinely valuable — good auditors find things teams have stared past for months — and it is not a certification, a guarantee, or a statement that the system is safe.

The distinction matters commercially as well as technically. An audit is evidence you can show a counterparty. A badge with no linked report is not evidence of anything, and treating the two as equivalent is how “audited” became a marketing word rather than a technical one.

Scope is the whole thing

Every report states what was reviewed. It is the section that matters most and the one nobody reads.

Scope is typically a list of files at a specific commit hash. Anything not in that list was not looked at. This routinely excludes the deployment scripts, the off-chain components, the oracle integration, the governance contracts and any dependency — which is to say, it frequently excludes where the failure will occur.

The commit hash is equally important. An audit covers the code as it existed at that commit. If the team shipped changes afterwards — and they nearly always do — that code is unaudited, whatever the badge says. Comparing the audited commit against what is actually deployed is a check anybody can perform and almost nobody performs.

Read the findings that were not fixed

Resolved findings tell you the process worked. The informative section is the one listing issues marked acknowledged, disputed or risk accepted.

Acknowledged means the team read it and chose not to change anything. Sometimes that is entirely reasonable — a theoretical issue with an impractical precondition. Sometimes it is a live risk the team decided to carry, disclosed in a document nobody reads. The reasoning is usually printed alongside it, and the quality of that reasoning is one of the better signals available about the team.

Centralisation findings deserve particular attention, because they are the most commonly acknowledged and dismissed. “The owner can pause withdrawals” marked as acknowledged is not a formality; it is a description of the actual trust model.

Severity is not standardised

There is no shared definition of “high” or “medium” across firms. One auditor’s high is another’s medium, and severity is frequently a negotiation between auditor and client. Comparing severity counts across reports from different firms tells you very little.

Read the description of each finding rather than the label.

What an audit structurally cannot catch

Economic design flaws. Code that does exactly what it was specified to do, where the specification is exploitable. Most audits review implementation against intent, not intent against reality.

Emergent interactions. A contract can be individually sound and unsafe in composition with a protocol that did not exist at audit time.

Off-chain failure. Compromised keys, a bad deployment, a misconfigured multisig, an oracle that behaves fine until it does not.

Governance capture. Contracts working precisely as designed while control of them changes hands.

Questions worth asking

Is the full report published, or only a badge? What commit was audited and does it match production? What is in scope and, more usefully, what was excluded? How many findings were acknowledged rather than fixed, and what was the reasoning? Was there a re-review after the fixes, or is the report pre-fix? How long did the engagement run — a two-day review of a large codebase is a different product from a four-week one.

A team that publishes the full report including the uncomfortable findings is telling you something more valuable than the audit itself.

Monogram avatar for Idris Karam

Idris Karam

Blockchain Technology Correspondent

Idris Karam covers blockchain infrastructure for TokenPR: consensus design, scaling architecture, smart contract security and the long unglamorous work of protocol upgrades. They write from a build background rather than a finance one, having spent several years as a backend engineer before moving into technical writing and then reporting. It shows in the coverage. Idris reads the specification, the client release…

More from this author

Keep reading

Related from the newsroom

Marketing intelligence, weekly

One email a week: the PR and growth tactics actually moving the needle for crypto teams, plus what the newsroom is watching. No shilling, no price calls.

We never sell your data. Unsubscribe in one click. See our privacy policy.

Leave a comment

Comments are moderated. Your email is never published.