How to Read a Smart Contract Audit Report
Protocols advertise that they are audited. The useful information is in what was audited, when, by whom, and what the team did about the findings.
Protocols advertise that they are audited. The useful information is in what was audited, when, by whom, and what the team did about the findings.
An audit reviews a specific commit of specific contracts during a fixed window. To read one, check the scope section for which contracts and which commit, compare that commit against what is deployed today, read the findings by severity with the team's responses, and note the disclaimer. A protocol described as audited without any of those details has told you nothing.
Audited is the most overworked word in DeFi marketing. Euler was audited before losing $197m. Balancer was audited before its November 2025 Composable Stable Pool exploit took well over $100m. Neither audit was fraudulent; both covered code that was not the code that failed, or missed a class of bug within scope. Reading the report tells you which of those you are looking at.
Every serious report opens with a scope section listing the files reviewed and a commit hash. This is the most important page and the one nobody reads.
Two questions follow from it. Does the scope include the contracts holding funds, or only peripheral ones — a token contract and a staking helper while the vault logic went unreviewed? And does the commit match what is deployed now? Protocols ship after the audit; if the deployed code is fifty commits ahead of the reviewed hash, the report describes something else.
You can check this yourself without reading code: the deployed contract address on a block explorer shows verified source and a deployment date, and the report shows a hash and a date. If the report predates a major version, look for a second audit covering the new one.
Findings are graded, usually critical, high, medium, low and informational. Critical and high mean funds could be lost. Medium usually means a condition-dependent loss or a serious griefing vector. Low and informational are code quality.
What matters more than the count is the resolution column. Fixed with a commit reference is a real answer. Acknowledged means the team read it and chose not to change anything — sometimes reasonable, sometimes the finding that later becomes an incident. A report with three highs marked acknowledged deserves a specific explanation from the team, and most protocols publish one if asked.
A clean report with zero findings is not the reassurance it appears to be. It usually means a narrow scope or a short engagement, and experienced reviewers treat it as a flag rather than a gold star.
Firms differ enormously in rigour, and the same firm differs across engagements depending on budget and timeline. Look for the duration of the review and the number of reviewers, which good firms state. A two-day review by one engineer on a complex protocol is a different product from a three-week review by three.
Also look for what else the protocol does: a live bug bounty with a meaningful maximum payout, formal verification of core invariants, and multiple independent audits of the same code. EigenLayer and Aave both stack these, which is a different security posture from a single report published at launch.
Every report ends with language stating that it does not guarantee the absence of bugs, covers only the reviewed code, and is not an endorsement. This is not boilerplate to skip: it is the auditor accurately describing the product. An audit is evidence of diligence during a window, not a warranty.
The Curve case makes the point precisely. The July 2023 exploit came through a compiler bug in specific Vyper versions rather than Curve's own logic — code that no application-level audit examines. Shared tooling, dependencies and compilers sit outside the scope of nearly every report you will read.
Before depositing into anything, answer these. Which contracts hold my funds, and were they in scope? Does the audited commit match what is deployed? Were any critical or high findings left unfixed, and what did the team say about them? What else supports the code — bounty, second audit, time in production with real value?
That last one is worth more than people expect. A protocol that has held significant value for four years without incident has passed a test no report can simulate, which is why time in production carries real weight in our DeFi protocol rubric and why we describe audits in reviews as evidence rather than assurance, in line with our published methodology.
Whether the team can rug you. Upgrade keys, admin functions, proxy patterns and multisig thresholds are governance facts, not code bugs, and a report may note them as informational while your entire exposure sits there. Check who can upgrade the contract and how quickly, because that is a bigger determinant of your risk than most findings in the report.

Most wallet losses are not stolen keys. They are approvals granted months ago to a contract that later turned hostile — and revoking them takes about a minute.
Every major stablecoin publishes reserve reports. Almost none of them are audits, and the difference decides what the document is worth.

Smart contracts can't see the outside world on their own. Oracles are the systems that feed them prices, events, and data — and getting that design wrong has cost DeFi protocols hundreds of millions.