How to Read a Smart Contract Audit Report
Most DeFi users see the words "audited by CertiK" and move on. They treat the audit badge as a seal of approval, a binary signal that the protocol is safe. It is not. An audit report is a detailed technical document that tells you exactly what was found, what was fixed, and what remains. Reading it takes ten minutes. Not reading it can cost you everything.
What a Smart Contract Audit Actually Is
A smart contract audit is a systematic, line-by-line examination of a protocol's code by independent security researchers. The goal is to identify vulnerabilities, logic errors, and design weaknesses before the contract goes live on a blockchain where it becomes immutable and publicly accessible to anyone, including attackers.
The process combines manual expert review (where experienced auditors read the code and reason about its behavior under adversarial conditions) with automated analysis (tools that scan for known vulnerability patterns like reentrancy, integer overflows, and access control flaws). The best audit firms also apply formal verification, a mathematical technique that proves certain properties of the code hold true under all possible inputs.
The output is a report. That report is what you need to learn to read.
An audit is not a guarantee. It is an expert assessment at a specific point in time, against a specific version of the code. If the protocol updates its contracts after the audit, the report no longer covers the current code. Always verify that the audit matches the deployed version.
Anatomy of an Audit Report
While every firm has its own formatting, the structure of professional audit reports is remarkably consistent. Here is what you will find in reports from CertiK, Hacken, OpenZeppelin, Trail of Bits, Quantstamp, and similar firms:
| Section | What It Contains | Why It Matters |
|---|---|---|
| Executive Summary | High-level overview, scope, methodology, overall assessment | Tells you what was audited and whether serious issues exist |
| Scope | Contract addresses, file names, commit hashes, chains covered | Confirms the audit matches the deployed code |
| Findings | Individual vulnerabilities with severity, description, recommendation | The core of the report. This is where the real information lives |
| Resolution Status | Whether each finding was resolved, acknowledged, or remains open | Shows if the team actually fixed the problems |
| Informational Notes | Code quality suggestions, gas optimizations, best practice recommendations | Low severity but reveals how carefully the code was written |
Start with the Executive Summary to get context. Then go directly to the Findings section. That is where the audit earns its value.
Understanding Severity Levels
Every finding in an audit report is classified by severity. The industry has converged on five levels. Understanding what each level means is essential for evaluating risk:
| Severity | Meaning | What to Look For |
|---|---|---|
| Critical | Direct threat to user funds or protocol integrity. Exploitable immediately or with minimal effort. | These must be resolved. An unresolved Critical finding is a deal-breaker. |
| Major | Centralization risks, logic errors that could lead to loss of funds or protocol control under certain conditions. | Requires resolution or a very strong justification for acknowledgment. |
| Medium | Issues affecting reliability or performance. Not directly exploitable but could become dangerous in combination with other factors. | Should be resolved. Acknowledged Mediums are acceptable if well-reasoned. |
| Minor | Inefficient code, non-standard patterns, or minor deviations from best practices that do not create a security risk. | Nice to fix but not a red flag if left open. |
| Informational | Style suggestions, documentation gaps, gas optimization opportunities. | Useful for code quality assessment. Ignore for security evaluation. |
If an audit report contains any Critical or Major finding with status "Unresolved" or "Open," do not invest until the team addresses it. No exception. An unresolved Critical finding means the auditors identified a way to steal funds or break the protocol, and the team chose not to fix it.
Resolution Status: The Most Important Column
Most people scan the severity levels. Fewer people check what happened next. The resolution status of each finding tells you more about a team's integrity than anything else in the report.
Resolved
The team implemented a fix, and the auditors verified that the fix works. This is the best outcome. A report where all Critical and Major findings are marked "Resolved" is a strong positive signal.
Acknowledged
The team reviewed the finding, understands the risk, and chose not to change the code. This is not automatically bad. Sometimes there are legitimate architectural reasons for accepting a known risk. What matters is the justification. A good acknowledgment explains why the risk is acceptable (for example, a temporary admin key during launch phase that will be revoked after stabilization). A bad acknowledgment offers no explanation or dismisses the finding.
Partially Resolved
The team addressed part of the issue but not all of it. Read the auditor's follow-up comment carefully. Sometimes a partial fix is sufficient. Sometimes it introduces new edge cases.
Unresolved / Open
The team did not address the finding at all. For Informational or Minor findings, this is common and acceptable. For Medium, it warrants scrutiny. For Critical or Major, this is a red flag that should stop your due diligence process entirely.
Common Finding Categories
Audit reports across hundreds of DeFi protocols reveal recurring patterns. Understanding these categories helps you quickly assess what a finding means for your funds:
Reentrancy
A vulnerability where an external contract can call back into the original contract before the first execution completes. This was the attack vector behind the DAO hack in 2016 that led to the Ethereum/Ethereum Classic split. Modern Solidity versions include built-in protections, but reentrancy still appears in cross-contract interactions and complex DeFi composability scenarios.
Access Control
Who can call which functions? If admin-only functions lack proper access restrictions, anyone could drain the treasury, pause the protocol, or change critical parameters. This category also covers privilege escalation, where a user with limited permissions can gain admin-level access through a sequence of transactions.
Integer Overflow / Underflow
Arithmetic operations that produce results outside the expected range. Since Solidity 0.8.0, the compiler includes automatic overflow checks by default. But contracts using earlier versions or unchecked blocks remain vulnerable. In financial applications, a single overflow can turn a small deposit into an astronomical withdrawal.
Oracle Manipulation
Protocols that rely on external price feeds (oracles) can be exploited if those feeds are manipulable. Flash loan attacks frequently target protocols that use spot prices from a single DEX as their price oracle. Reputable protocols use Chainlink or similar decentralized oracle networks with multiple data sources and tamper-resistant aggregation.
Centralization Risk
Admin keys, upgrade authorities, pause functions, and emergency withdrawal mechanisms all represent centralization vectors. An audit will flag these not as bugs but as design decisions that concentrate power. The question for you as an investor: who holds these keys, how many signatures are required, and is there a timelock?
Front-Running / MEV Exposure
Transactions on public blockchains are visible before confirmation. If a protocol's functions reveal profitable information (like large pending trades or liquidation thresholds), searchers can front-run these transactions. Auditors flag contract designs that are structurally vulnerable to MEV extraction.
After reading a few audit reports, you will start recognizing these categories instantly. That pattern recognition is what separates informed investors from those who simply trust the badge.
Red Flags That Should Stop You
Not every audit report is created equal. Here are the signals that should give you serious pause:
Unknown or unverifiable audit firm. If you cannot find the firm's website, their past reports, or their team, the audit may have been conducted by an unqualified party or fabricated entirely. Stick to established firms: CertiK, Trail of Bits, OpenZeppelin, Hacken, Quantstamp, Sherlock, Code4rena.
Scope that does not match deployed contracts. Check the commit hash and contract addresses in the report against what is actually deployed on-chain. If they do not match, the audit covers different code than what holds your funds.
No re-audit after significant changes. If a protocol launched V1, got audited, then deployed V2 with major changes, the V1 audit tells you nothing about V2. Look for supplementary audits or follow-up reviews.
Unresolved Critical or Major findings. As stated above, this is non-negotiable.
Single audit only. The most security-conscious protocols commission multiple audits from different firms. Each firm has different specializations and blind spots. Two independent audits catching different issues is significantly more reassuring than one audit catching everything.
No public report. If a protocol claims to be audited but does not publish the full report, treat the claim as unverified. Transparency is the baseline expectation in DeFi security. Reputable firms publish all reports publicly.
What Audits Cannot Tell You
Understanding the limits of an audit is as important as reading one. Here is what falls outside the scope of even the most thorough security review:
Economic design flaws. An audit verifies that the code does what it is supposed to do. It does not evaluate whether what it is supposed to do makes economic sense. A tokenomics model that is mathematically destined for collapse will pass a code audit with flying colors if the code faithfully implements the flawed design.
Off-chain components. Most DeFi protocols have front-ends, APIs, backend infrastructure, and administrative processes that exist outside the smart contract. An audit covers the on-chain code only. The front-end could be compromised, the API could leak data, and the team's operational security could be weak.
Future changes. An audit is a snapshot. Upgradable contracts can be modified after the audit. Governance votes can change parameters. New integrations can introduce unexpected interactions. An audit from six months ago may be irrelevant if the protocol has changed significantly since then.
Team integrity. A perfectly audited contract controlled by a malicious team with admin keys is still a rug pull waiting to happen. The audit does not evaluate the people behind the protocol.
Black swan scenarios. No audit can predict novel attack vectors, previously unknown compiler bugs, or cascading failures across interconnected protocols. Security is always relative, never absolute.
Think of an audit as one layer in a multi-layer security assessment. The code audit covers the smart contract layer. You still need to evaluate the team, the economics, the governance, the track record, and the broader ecosystem risk. Our DeFi Risk Scorer tool helps you evaluate these additional dimensions.
Your 10-Point Audit Reading Checklist
When evaluating any DeFi protocol, open the audit report and work through these questions:
| # | Question | Where to Find It |
|---|---|---|
| 1 | Who conducted the audit? | Cover page. Verify the firm is reputable. |
| 2 | When was the audit completed? | Cover page or executive summary. Older than 6 months? Check for updates. |
| 3 | Does the scope match the deployed contracts? | Scope section. Compare commit hash and addresses to on-chain. |
| 4 | How many Critical findings? | Findings summary. Zero is ideal. Any number above zero requires "Resolved." |
| 5 | How many Major findings? | Findings summary. Same rule: must be Resolved or have strong justification. |
| 6 | Are all Critical/Major findings Resolved? | Resolution status column. This is the single most important check. |
| 7 | Are there centralization warnings? | Finding descriptions. Look for admin keys, upgrade authority, pause functions. |
| 8 | Is there a timelock on admin actions? | May be in findings or scope. Timelock = users get warning before changes. |
| 9 | Was the contract verified on a block explorer? | Not in the report. Check Etherscan/Solscan. Verified = source code is public. |
| 10 | Is this the only audit or are there others? | Protocol documentation. Multiple audits from different firms = stronger. |
An audit report is not a certificate of safety. It is a diagnostic document. Reading it takes less time than most people spend comparing exchange fees, yet it tells you more about a protocol's risk than any influencer, marketing page, or community sentiment ever will.
The ten-point checklist above takes five minutes to complete. If you are putting real money into a DeFi protocol, those five minutes are non-negotiable. Read the report. Check the resolutions. Verify the scope. Then make your decision with actual data instead of assumptions.
About White & TT: White & TT is an independent DeFi research desk. We do not accept payment from protocols for coverage. We hold positions in tokens we analyze and always disclose this. Our research includes security analysis as part of our due diligence methodology. For commissioned research, visit whitett.info.
White & TT LLC · whitett.info · research@whitett.info