Reading a Smart Contract Audit Report as a Non-Engineer
An audit PDF tells you what was examined, what was not, and what the authors did not verify. Here is how to extract those three things.
This article may contain affiliate links. Commercial relationships are disclosed in the affiliate policy.
Start with the scope box, not the severity table
Most readers open an audit looking for the severity table, and that is the last place to start. The scope section states which contracts, which commit hash, which branches and which configuration the auditors actually examined. Without it, every finding in the report is detached from the code you are running.
Check the commit hash against the deployed contract. If the report names a commit and the deployment is at a different commit, the audit describes a version of the code you are not using. This is the single most common way an audit turns out to be irrelevant, and it is entirely verifiable in a minute.
Three questions that extract most of the value
First: what was out of scope? Integrations, oracle implementations, governance contracts and deployment scripts are frequently excluded because auditing them requires a different specialism. An audit that covers only the main vault contract has not told you anything about the price feed feeding it.
Second: how many findings are unresolved? Reports list findings by severity and then a project publishes a response to each. The count of findings marked not fixed or acknowledged tells you more than the severity of any single one, because a project that acknowledges and documents an accepted risk is in a different position from one that quietly leaves a finding open.
Third: what did the auditors assume? Assumptions about admin keys, upgradeability, oracle behaviour and liquidity depth determine how much weight each finding carries. A finding rated medium under the assumption that governance is trusted reads differently once you know governance is a multisig you cannot inspect.
Findings are not verdicts
A finding describes a condition that was observed in the examined code. It does not describe exploitability in production, and severity labels in different firms’ methodologies are not comparable across reports. Two firms can classify the same condition as high and medium respectively without either being wrong.
The practical use of a report is narrower than people expect: it tells you which properties the authors tried to break, and therefore which properties nobody has yet tried to break. The absence of a critical finding is weak evidence. It is evidence that a competent adversary did not find a critical path within the budget and time of the engagement.
Verify the report exists and is this one
Audits are real documents, and citing them is a normal practice. What is not normal is a report attributed to a firm that never published it, or a report for a project with the same name. Look for the firm’s own publication, a link from the project’s documentation, and a contract address in the scope section that matches the deployment.
Marketing copy that says “audited by” is weaker than a link to the report itself. If the link is absent, treat the audit claim as unverified.
What this article does not claim
This does not evaluate any specific audit, firm or project, and it does not tell you whether a contract is safe. It does not cover economic attacks that an audit structurally cannot catch, such as oracle manipulation under market conditions, and it does not cover the risk of an upgrade key that the auditors examined and accepted.
This material is educational and is not financial, legal, tax or security advice. Audit methodologies and deployed code both change; check the current report and the current deployment.