How to Read a DeFi Audit Properly

An audit is not a guarantee of safety. It is a time-limited review by human auditors who may miss things. Always assess audit quality rather than just checking if an audit exists.

What Is a Smart Contract Audit?

A smart contract audit is a review of code by external security researchers. They look for bugs, logical errors, access-control issues, and economic exploits. At the end, they produce a report listing what they found, ranked by severity.

Audits are typically performed on a specific commit hash — a snapshot of the code at a particular time. If the code changes after the audit, the findings may no longer apply.

Understanding Severity Levels

Most audit firms use a similar severity classification:

Critical / High

Direct loss of funds, unauthorized access, or protocol insolvency. These must be fixed before deployment. If a protocol deployed with unpatched critical findings, treat it as a serious red flag.

Medium

Issues that could cause loss under specific conditions, or that degrade protocol functionality. Most protocols fix these, but some accept the risk with justification.

Low / Informational

Code quality issues, gas optimizations, or minor inconsistencies. These rarely affect user safety. It's normal for some to be acknowledged but not fixed.

What to Check in an Audit Report

  1. Scope — what contracts were audited? If only part of the protocol was reviewed, the rest is untested. Check if the scope matches the contracts you interact with.
  2. Findings count by severity — a protocol with zero findings may mean a thorough codebase or an easy-going auditor. Look for meaningful findings that were identified and resolved.
  3. Resolution status — do all critical and high findings say "Resolved" or "Fixed"? If findings are "Acknowledged" at high severity, read carefully why.
  4. Audit firm reputation — Sherlock, Trail of Bits, OpenZeppelin, Zellic, Consensys Diligence are well-known firms. Competition-style audits (Sherlock, Code4rena) have many eyes on the code.
  5. Date and commit hash — how old is the audit? Has the code changed significantly since? Check if the deployed bytecode matches the audited commit.
  6. Methodology — did they do manual review, automated analysis, or both? The best audits combine both approaches.

Red Flags in Audit Reports

  • Critical findings marked "Acknowledged" without a clear explanation
  • Audit scope doesn't cover the main contracts users interact with
  • Audit is very old and the code has changed significantly
  • Audit is done by an unknown firm with no track record
  • Report is not publicly available — only screenshots or summaries
  • Protocol claims "audited" but links to a questionnaire, not a full report

What an Audit Cannot Do

Even the best audit cannot guarantee:

  • No bugs exist — auditors are human and time-limited
  • The protocol is economically sound — auditors check code, not market dynamics
  • The team won't act maliciously — admin keys and governance are separate risks
  • Dependencies are safe — external libraries and oracles can introduce new risks
  • Future code is safe — any code change after the audit is unreviewed

Multiple Audits Are Better Than One

One audit is a starting point. Different auditors catch different things. Protocols that undergo multiple audits, fix review audits, and competitive audits have better coverage. Look for protocols that audit after major upgrades, not just once at launch.

For example, Exolane has been audited 7 times across its version history — including Sherlock competition audits, Zellic manual reviews, and fix reviews after changes. Every major version (V2, V2.1, V2.2, V2.3, V2.4) has been audited.

Related