How to Read a DeFi Audit Report: A Practical Guide for Investors
By Jorge Rodriguez — Risk Management
How to read every section of a DeFi audit report
How to spot red flags and green flags that signal protocol safety or risk
A repeatable framework for evaluating any protocol's security
Introduction
A protocol passes an audit, publishes the report on its website, and two months later gets exploited for $197 million. That is exactly what happened to Euler Finance in March 2023, when the exploited function had been introduced after one audit and fell outside the scope of another. The warning signs were there. They were just buried inside the audit report, and most investors never read past the headline. Knowing how to read a DeFi audit report is one of the most practical security skills you can develop as an investor. The report is not a seal of approval. It is a structured diagnostic that tells you what was tested, what was found, and what the team did about it. Every section contains signals that directly affect your risk exposure. This guide walks you through every section of a **smart contract audit** report, explains what each finding actually means, and gives you a repeatable framework for evaluating protocol security. Think of it as a deep-dive companion to our [DeFi Due Diligence Checklist](/blog/risk-management/defi-due-diligence-checklist), focused entirely on the audit-reading step. By the end, you will be able to pick up any audit report from any chain and extract the information that matters for your investment decisions.
What Is a DeFi Audit Report?
**What Auditors Actually Do** A DeFi audit report is the output of a professional security review conducted on a protocol's smart contract code. Auditors combine manual code review with automated scanning tools like Slither, Mythril, or Clippy (for Rust-based programs) to identify vulnerabilities, logic errors, and deviations from best practices. The process typically takes two to eight weeks depending on codebase complexity. Some firms also perform **formal verification**, which uses mathematical proofs to confirm that specific functions behave exactly as intended. The final deliverable is the audit report: a document that catalogs everything the auditors found, ranked by severity, with recommendations for each issue. **Why Audit Reports Matter for Investors** For investors, the audit report is your most direct window into a protocol's security posture. It tells you which parts of the code were reviewed, what problems were discovered, and how the team responded. A protocol with three independent audits and all findings resolved sits in a fundamentally different risk category than one with a single audit from an unknown firm and multiple unresolved issues. But here is the critical distinction: an audit is not a stamp of approval. It is a diagnostic snapshot. Annualized exploit-related losses dropped from over 30% of TVL in 2020 to under 0.5% in 2024, partly thanks to improved auditing practices. But exploits still happen on audited protocols. The report gives you data to make informed decisions, not certainty. **What an Audit Does NOT Guarantee** An audit covers the specific code, at a specific commit hash, at a specific point in time. It does not cover economic exploits like oracle manipulation or governance attacks. It does not account for code changes deployed after the audit. And it does not review off-chain components, admin key management, or the protocol's economic model. Understanding these limitations is just as important as understanding what the report contains. For a broader look at risks that fall outside audit scope, see our guide on [DeFi yield risks](/blog/risk-management/defi-yield-risks-explained).
Anatomy of an Audit Report: Section by Section
Every audit report follows a similar structure regardless of which firm produced it. Once you understand the anatomy, you can navigate any report in minutes.  **Executive Summary** The **executive summary** sits at the top of the report and provides the auditor's overall assessment. It includes the general sentiment (positive, cautious, or concerning), the total number of findings by severity, the audit duration, and any high-level observations about code quality. Read this section first. It tells you whether the auditors consider the protocol generally sound or found systemic problems. Pay attention to the audit duration too. A one-week audit on a complex lending protocol is far less thorough than a six-week engagement. **Scope and Methodology** The scope section defines exactly what was reviewed. It lists the specific contracts or programs audited, the **commit hash** (the exact version of the code), the tools used, and critically, what was excluded. This is where many investors make their first mistake: they see "audited" and assume everything was covered. A protocol might have fifteen smart contracts but only submit five for audit. Always check whether the **audit scope** covers the contracts you are actually interacting with. If you are depositing into a vault contract that was not part of the audit, that audit provides zero protection for your funds. **Findings and Vulnerability Details** This is the core of the report. Each finding includes a title, detailed description, severity level, affected code, the auditor's recommendation, and remediation status. A typical audit contains five to fifty findings depending on codebase maturity. Read the description to understand what could go wrong, the recommendation to see how it should be fixed, and the status to know whether it was addressed. We will break down severity levels and remediation statuses in the next sections.
Severity Classifications Explained
Audit firms use a **severity classification** system to rank findings by potential impact. While the exact terminology varies slightly between firms, the core framework is consistent across the industry.  | Severity | Impact | Typical Examples | |---|---|---| | Critical | Direct loss of user funds, protocol-breaking | Reentrancy allowing full drain, broken access control on withdrawal functions | | High | Significant risk under specific conditions | Privilege escalation, integer overflow in balance calculations | | Medium | Moderate impact, exploitable in edge cases | Front-running vulnerability, incorrect fee calculations | | Low | Minor issues, best practice violations | Missing event emissions, suboptimal gas usage | | Informational | Code quality suggestions, no security impact | Naming conventions, documentation gaps, unused variables | A critical finding means an attacker could directly steal funds or break the protocol entirely. A high-severity finding represents a serious risk that might require specific conditions to exploit. Medium findings are real vulnerabilities but typically affect edge cases rather than core functionality. Note that different firms use slightly different scales. The [Immunefi Vulnerability Severity Classification System](https://immunefi.com/immunefi-vulnerability-severity-classification-system-v2-3/) uses "Insight" instead of "Informational" and further subdivides smart contract impacts from website and application impacts. When comparing reports from different auditors, focus on the description of each finding rather than the label alone. The most important question is not how many findings exist, but how many critical and high findings were found and what happened to them. A report with thirty low-severity findings and zero criticals tells a very different story than one with three criticals and two highs.
Remediation Status: What Actually Happened After the Audit
The findings table is only half the picture. The **remediation status** column tells you what the protocol team did about each issue, and this is where the real signal lives. **Resolved** The team fixed the issue and the auditors verified the fix in a follow-up review. This is the best outcome. The vulnerability was identified, patched, and confirmed as properly addressed. When you see "Resolved" next to a critical finding, it means the system worked as intended. **Mitigated** The team reduced the risk but did not eliminate it entirely. They might have added a check that prevents the most obvious **attack vector** but left the underlying design pattern in place. Read the auditor's notes to understand what residual risk remains. **Acknowledged** This is the status that should raise your antenna. An **acknowledged finding** means the team saw the vulnerability and chose not to fix it. Sometimes the reasoning is valid: the fix would cost too much gas, the design trade-off is acceptable given the protocol's risk model, or the finding is theoretical with no practical exploit path. But sometimes "acknowledged" is a red flag hiding in plain sight. An acknowledged critical or high-severity finding is one of the strongest negative signals you can find in an audit report. It means someone identified a serious problem, the team was informed, and they decided to leave it in production. Before depositing funds, you need to understand why. **Partially Resolved** The team applied a fix, but the auditors still have concerns about the implementation. Treat partially resolved findings similarly to mitigated ones: read the auditor's notes carefully.
Red Flags in Audit Reports
Not every audit report signals the same level of confidence. Some patterns should make you slow down and investigate further before committing capital. Here are the warning signs experienced investors look for.  • Unresolved critical or high-severity findings. If the team left serious vulnerabilities unaddressed, your funds are exposed to known risks. • Very narrow audit scope. If only two or three contracts were reviewed out of a codebase with ten or more, the unaudited code could contain anything. • Extremely short audit period. A complex lending or DEX protocol audited in under one week did not receive thorough coverage. Quality audits take time. • No **re-audit** after remediation. If the team claims to have fixed issues but the auditors never verified those fixes, you are trusting the team's code changes without independent review. • Single auditor rather than a firm. One person reviewing code cannot match the coverage of a team with diverse expertise and internal review processes. • Unknown or unverifiable auditor. If the audit firm has no public track record, no portfolio of previous audits, and no industry reputation, the report carries less weight. • Audit is outdated and code has changed significantly. A report from eighteen months ago on a protocol that has shipped multiple upgrades since then tells you very little about the current codebase. • No commit hash specified. Without a commit hash, you cannot verify which version of the code was actually audited, making the entire report unverifiable. • Deployed code differs from audited code. This is the most dangerous scenario. The protocol published an audit for credibility but deployed different code to production. To understand what happens when these warning signs are ignored, read our analysis of [DeFi protocol exploit aftermath](/blog/risk-management/defi-protocol-exploit-aftermath).
Green Flags in Audit Reports
Certain patterns indicate that a protocol takes security seriously. These positive signals do not eliminate risk, but they significantly reduce it. • Multiple independent audits from reputable firms. When two or three different teams review the same code, vulnerabilities are far less likely to slip through. Each auditor brings different expertise and methodologies. • Active **bug bounty** program through platforms like Immunefi. A bug bounty means the protocol is paying ethical hackers to find problems continuously, not just during a fixed audit window. Major protocols offer bounties ranging from $100,000 to over $2 million. • Formal verification performed on critical functions. Mathematical proofs that core logic behaves as specified represent the highest level of code assurance available. • All critical and high findings resolved with auditor sign-off. The team took every serious finding through to a verified fix. • Re-audit performed after major code changes. The protocol treats security as an ongoing process, not a one-time checkbox. • Open-source code matching the audited commit hash. You can independently verify that the code running in production is the same code the auditors reviewed. • Detailed remediation responses from the team. Instead of terse "acknowledged" notes, the team explains their reasoning for each finding, demonstrating genuine engagement with the audit process.
How to Find Audit Reports for Any Protocol
**Where Protocols Publish Audits** Most protocols publish their audit reports in one or more of these locations. Start with the protocol's GitHub repository, where audit PDFs are typically stored in a dedicated /audits or /security folder. The Anza/Solana team, for example, maintains a [public security audits repository](https://github.com/anza-xyz/security-audits) that serves as a good reference for what transparent audit disclosure looks like. Protocol documentation sites often have a security page linking to all completed audits. Some projects also maintain dedicated security hubs that aggregate audits, bug bounty information, and incident response plans. If you cannot find audit information easily, that itself is a data point about the team's commitment to transparency. **Verification: Matching Audited Code to Deployed Code** Finding the audit report is step one. Verifying it is step two. Every serious audit report includes a **commit hash** that identifies the exact version of code that was reviewed. To verify, compare that commit hash against the code deployed on-chain using a block explorer like Etherscan or Solscan. On EVM chains, verified contracts display their source code publicly. On Solana, you can use the Anchor verifiable builds feature to confirm that the deployed program matches a specific source.  If the commit hash in the report does not match the deployed code, the audit tells you nothing about what is currently running. This is not theoretical. Multiple exploits have occurred on code that was modified after the audit. **What If There Is No Audit?** Unaudited protocols carry a meaningfully higher risk profile. If you encounter a protocol with no audit, check whether it has a bug bounty as a partial substitute, and consider the **TVL** (Total Value Locked) at risk. A protocol managing $500 million in deposits with no audit is a very different risk proposition than one with $50,000. Tools like the [Lince Yield Tracker](https://yields.lince.finance/tracker) can help you filter opportunities across multiple chains and evaluate protocols based on available security information alongside yield data. Combining yield analysis with audit verification gives you a more complete picture before committing funds.
Major DeFi Audit Firms by Ecosystem
Understanding who audited a protocol matters almost as much as what they found. The reputation and specialization of the audit firm directly affect how much weight you should give the report. **Multi-chain Firms** The largest audit firms operate across multiple ecosystems. Trail of Bits is widely regarded as one of the most rigorous, with deep expertise in both EVM and non-EVM codebases. OpenZeppelin has audited many foundational contracts the industry relies on. Quantstamp, Halborn, and CertiK offer broad coverage across Ethereum, Solana, Base, and other chains. **Solana-Focused Firms** The Solana ecosystem has specialized auditors with deep Rust and Anchor framework expertise. OtterSec (now osec.io) is one of the strongest Solana auditors, having reviewed the core Solana runtime along with major protocols across Solana, Sui, and Aptos. Neodyme brings deep Rust expertise with notable work on SPL Token-Lending. Kudelski Security has audited the Solana runtime and Marinade. The [SolSec resource collection](https://github.com/sannykim/solsec) on GitHub provides a curated list of Solana-specific audit firms, security tools, and exploit analyses. **How to Evaluate an Auditor's Reputation** Consider their track record: years of operation, portfolio quality, whether audited protocols were exploited post-audit (and if so, whether the exploit was within scope), and whether they publish reports transparently. A firm with hundreds of completed audits carries more weight than a new entrant.
Walkthrough: Reading a Real Audit Report
Here is a repeatable framework for reading any audit report, regardless of which firm wrote it or which chain the protocol runs on. **Step 1: Read the Executive Summary** Note the overall assessment, total findings by severity, and audit duration. If the summary mentions systemic design concerns, that is a significant flag regardless of individual finding severities. **Step 2: Check the Scope** Identify which contracts were audited and cross-reference against the protocol's full codebase. Confirm the contracts you plan to interact with were in scope. Note the commit hash for later verification. **Step 3: Scan the Findings Table** Count the criticals, highs, and their remediation statuses. If every critical and high is resolved, that is a strong signal. Acknowledged criticals deserve immediate detailed reading. **Step 4: Read Critical and High Findings** For each serious finding, understand the vulnerability, its potential impact, and what the team did about it. Did they implement the recommended fix, or take a different approach? Does the auditor confirm it was adequately addressed? **Step 5: Verify the Commit Hash** Take the commit hash from the report and compare it against what is currently deployed on-chain. If major changes have been introduced since the audit, the report's relevance diminishes. **Step 6: Form Your Assessment** Answer three questions: Was the audit thorough (scope, duration, auditor reputation)? Were findings properly resolved? Does deployed code match what was audited? Your answers map directly to your risk assessment.
Common Mistakes When Reading Audit Reports
Even experienced DeFi users fall into predictable traps when evaluating audit reports. Avoiding these mistakes will immediately improve your security assessments. **Treating "Audited" as "Safe"** This is the most dangerous mistake. The Euler Finance exploit in 2023 resulted in $197 million in losses on a protocol audited by multiple firms. The exploited function was introduced after one audit and fell outside the scope of another. "Audited" means "reviewed at a specific point in time," nothing more. **Ignoring the Scope Section** Skipping to findings without checking what was reviewed creates false confidence. The contracts you interact with might not have been included in the audit at all. **Not Checking Whether the Audit Is Current** An audit from a year ago on a protocol that ships weekly updates has limited relevance. Check when the audit was performed and how much the code has changed since. **Skipping Acknowledged Findings** Investors scan for "all findings resolved" and move on. But acknowledged findings are where real risk lives. These are known issues the team chose to leave in production. Read every one. **Only Checking If an Audit Exists** Two protocols can both be "audited" while sitting in completely different risk categories based on scope, auditor quality, finding severity, and remediation completeness. The report matters, not just its existence.
FAQs
### What is a DeFi audit report? A DeFi audit report is the documented output of a professional security review conducted on a protocol's smart contract code. It includes an executive summary, the scope of what was reviewed, detailed findings ranked by severity, and the remediation status of each issue. Audit reports are produced by specialized security firms after weeks of manual code review and automated analysis. ### How do I find the audit report for a DeFi protocol? Start with the protocol's GitHub repository, where audit PDFs are typically stored in a /security or /audits folder. Check the protocol's documentation site for a dedicated security page. Some protocols also link to audits from their main landing page or app interface. If you cannot find an audit after checking these locations, the protocol may not have been audited. ### What do severity levels mean in a smart contract audit? Severity levels rank findings by potential impact. Critical means direct loss of user funds or protocol-breaking bugs. High represents significant risk under certain conditions. Medium covers moderate-impact issues exploitable in edge cases. Low includes minor issues and best practice violations. Informational findings are code quality suggestions with no direct security impact. ### What is the difference between resolved and acknowledged in an audit? Resolved means the team fixed the issue and auditors verified the fix. Acknowledged means the team reviewed the finding and chose not to fix it. Sometimes the reasoning is valid, such as gas cost trade-offs or theoretical-only exploitability. But acknowledged critical or high-severity findings are a significant warning sign that warrants further investigation before investing. ### Can a protocol still be hacked after passing an audit? Yes. Audits are point-in-time reviews, not guarantees of permanent security. Code changes after the audit can introduce new vulnerabilities. Economic exploits like oracle manipulation or governance attacks typically fall outside audit scope. Some vulnerabilities may simply be missed. Multiple audits, bug bounties, and formal verification all reduce this residual risk but never eliminate it entirely. ### How many audits should a DeFi protocol have? There is no fixed number, but multiple independent audits from different reputable firms provide significantly stronger assurance than a single audit. Each auditing team brings different expertise, tools, and perspectives. For protocols managing large amounts of TVL, two to three audits from recognized firms is a reasonable baseline expectation. ### What should I do if a protocol has no audit? Proceed with extra caution. Check whether the protocol has a bug bounty program, which provides some continuous security coverage. Consider the TVL at risk and your own exposure. Review the team's track record and whether the code is open source. An unaudited protocol is not necessarily a scam, but it does carry meaningfully higher smart contract risk. ### Are Solana smart contract audits different from Ethereum audits? The core methodology is similar, but the technical details differ significantly. Solana programs are written in Rust (often using the Anchor framework) rather than Solidity, which means auditors need Rust-specific expertise. The vulnerability patterns differ too: Solana programs face risks like missing signer checks, account validation errors, and PDA (Program Derived Address) manipulation rather than reentrancy attacks common on EVM chains. Specialized firms like OtterSec and Neodyme have deep Solana-specific expertise.
Conclusion
DeFi audit reports are the single most information-dense document available for evaluating a protocol's security. But that information is only useful if you actually read the report and know what to look for. The executive summary gives you the big picture. The scope tells you what was actually covered. The findings and their remediation statuses tell you where the real risks live. The framework is straightforward: check the scope, read the severity table, investigate any unresolved or acknowledged criticals, verify the commit hash matches deployed code, and evaluate the auditor's reputation. Run through these steps consistently, and you will make better-informed decisions than the vast majority of DeFi participants. Audit reports are one piece of a broader security evaluation. Combine audit analysis with economic risk assessment, team evaluation, and ongoing monitoring for a complete picture. The [Lince Yield Tracker](https://yields.lince.finance/tracker) helps you monitor yield opportunities across audited protocols on multiple chains, giving you a starting point for identifying where to focus your deeper research. The next time you consider depositing into a DeFi protocol, find the audit report and spend fifteen minutes reading it. Start by checking the [Lince Yield Tracker](https://yields.lince.finance/tracker) for protocols that match your criteria, then pull their audits and run through the framework above. Those fifteen minutes could be the difference between a calculated investment and an expensive lesson.