How to Read an Audit Report — Darkwave Log

Most technical founders, CTOs, and legal counsel receive a smart contract audit report and navigate it the same way: they scan for a summary, look for a number that signals “safe,” and file the PDF with investors. This approach misses almost everything important about the document.

An audit report is a structured record of findings produced by a security firm at a specific moment in time, against a specific version of code. Reading it correctly means understanding the constraints of what was reviewed, the methodology used to review it, the precise meaning of each severity classification, and what the remediation record does and does not tell you. This article is a guide to doing exactly that.

The Audit Is Not a Certification

The first and most consequential thing to understand about a smart contract audit report is its legal and epistemic status. What is called an “audit” in the blockchain space is a security review by a team of experts—but there is no formal definition or certification for what makes someone an auditor or a security expert in this context. The word “audit” carries heavy professional weight in fields like accounting and financial compliance, where it implies a regulated, repeatable procedure with standardized outputs. Smart contract auditing carries none of those guarantees.

For those coming from industries where ISO standards are the norm, smart contract auditing will seem like the wild west—and that would be an accurate assessment. There is no governing body that licenses audit firms. There is no universal standard that defines what a “complete” audit must include. Two firms can both call their deliverable an “audit report” while one conducted two weeks of manual review by senior researchers and the other ran an automated scanning tool for an afternoon.

A smart contract security review report is a detailed technical document produced after auditing a smart contract. It outlines vulnerabilities, their severity levels, recommended fixes, and a high-level summary of overall security posture at the time of review. The critical phrase is “at the time of review.” Smart contract audits are always done on a frozen codebase—a snapshot in time with a specific commit hash. Any code changes made after that commit are not covered by the report, regardless of how the report is described or presented.

No review can guarantee total security. However, thorough review reports drastically reduce risk by identifying the most likely paths for exploitation. When combined with ongoing security practices like bug bounties and penetration testing, they form a powerful defense. The audit report is evidence of due diligence and a record of known issues—it is not a warranty, a clean bill of health, or a certification of any kind.

When presenting a report to investors, counterparties, or regulators, these distinctions matter. Describing a protocol as “fully audited and secure” based on a report is a misrepresentation of what the document says. What the document actually says is that a specific team reviewed a specific codebase and documented what they found.

Severity Classifications: What They Actually Mean

Every professional audit report classifies findings by severity. The deliverable classifies findings by severity (critical, high, medium, low, informational), including reproducible proof-of-concept exploits and concrete remediation recommendations. However, the definitions behind those labels vary significantly between firms, and reading them uncritically is a common mistake.

Here is how the major tiers are generally understood:

Critical findings represent direct paths to total loss of funds or complete compromise of protocol control. Critical findings impact the safe functioning of a protocol in the most direct sense: a critical-severity vulnerability is typically one that can be exploited by an unpermissioned, external actor without special preconditions, and the exploitation results in irreversible harm—funds drained, ownership transferred, contracts bricked. These are the findings that should stop a deployment.

High findings are serious but may require some preconditions to exploit. Critical findings impact the safe functioning of a protocol, while high-severity findings involve centralization and logical errors that can lead to a loss of user funds or protocol control. The line between critical and high is often contested between audit firms. Some firms rate anything with a direct path to fund loss as critical. Others grade down based on difficulty of exploitation.

Medium findings typically affect reliability or correctness without an obvious direct path to immediate loss. Medium-severity findings affect the performance or reliability of the platform. That characterization underplays the real-world significance of some medium findings—a medium finding around oracle manipulation or access control misconfiguration can become high or critical under specific market conditions.

Low findings and Informational findings describe issues that do not pose immediate security risk but reflect code quality, efficiency, or adherence to best practices. In addition to severity ratings, an audit will include information on purely informative issues. Although such cases will not leave the contract vulnerable to attack, resolving such issues could result in better overall performance or readability.

There is a critical dimension that experienced readers pay attention to but that rarely appears in executive summaries: the difficulty axis. Some firms, like Runtime Verification, classify findings along two axes—severity and exploitation difficulty. The issue classification system is based on two axes: severity and difficulty. An issue can be flagged with high difficulty if only trusted authorized users can perform the attack, or if performing the attack costs significantly more than the benefit—for example, if it costs ten times more to execute the attack than what is gained. A finding that is critical in severity but practically impossible to exploit without controlling the network is materially different from a critical finding that any user can trigger in a single transaction.

Different auditors might have varying classifications for vulnerability severity. Ensure you understand the specific criteria used in the report you are reviewing. Always read the definitions section at the start of any report before interpreting the finding list. Do not assume that “medium” means the same thing in a report from Firm A as it does in one from Firm B.

Evaluating Finding Quality: Well-Specified vs. Vague

The presence of findings is not sufficient. The quality of those findings—the specificity and actionability of how they are documented—tells you as much about the audit firm as it does about the protocol.

A well-specified finding has five components: a precise title that names the vulnerability class, a description of the root cause, an explanation of the impact (what can actually happen, to whom, under what conditions), a reproduction path or proof-of-concept, and a concrete remediation recommendation. Recommendations should be step-by-step guidance on how to remediate each vulnerability. Context and rationale should explain why a particular issue matters and how it could be exploited.

A vague finding looks different. It names a category of vulnerability (e.g., “reentrancy risk”) without specifying which function, which state variable, and which call path creates the exposure. It describes impact in abstract terms (“may result in loss of funds”) without modeling the scenario. It offers a remediation suggestion like “add a reentrancy guard” without specifying where or why that guard resolves the root cause. Well-written reports often include references to specific lines of code where vulnerabilities reside. This allows developers to pinpoint and fix the issues efficiently.

The practical test: could your development team implement a fix based solely on the finding description, without asking the audit firm any clarifying questions? If the answer is no, the finding is insufficiently specified.

Findings should be grouped by severity, with impact explained in real terms. Concrete remediation guidance should be provided—not just “fix it.” Explicit assumptions about what conditions are required for exploitation, and any known risk trade-offs associated with specific remediation approaches, should also appear.

Watch for one particular pattern: generic findings that could apply to almost any codebase and appear to have been lifted from a template. Some firms reuse generic audit templates with little project-specific analysis. These boilerplate reports often lack depth and actionable insights. If a finding describes a class of vulnerability but makes no reference to the specific contract architecture, function names, or protocol design of the system under review, it is almost certainly templated content.

What Remediation Verification Means—and Doesn’t

Most audit reports include a remediation verification section or a fix-review round. This is commonly misunderstood as the audit firm re-reviewing the entire codebase after fixes are applied. That is not what happens.

There is typically a period of time—usually two weeks—given for the project to fix vulnerabilities and address the findings contained within the initial report. On completion of fixes, the audit team will conduct a “Fix Review” to check the changes that have been made. That review is specifically scoped to the changes made in response to the initial findings. The auditors verify that the specific vulnerability identified in each finding has been addressed, and they check that the fix itself has not introduced a new obvious problem.

Fixing findings is often harder than finding them, because fixes can introduce new edge cases or break assumptions elsewhere. A strong partner will work with you through remediation, then re-test the exact fixes and mark them as verified. This step is where audits stop being theoretical. It is the difference between “we addressed it” and “we know it is addressed.”

What fix verification explicitly does not cover:

New code written during the remediation period that is outside the scope of the original findings
Systemic changes to architecture that may have been made alongside targeted fixes
Interactions between fixes that individually appear correct but create new problems in combination
Issues that were present in the original codebase but were not identified by the initial review

Re-auditing is mandatory after critical fixes are applied, as patches often introduce new vulnerabilities that require a fresh, independent review cycle. If significant architectural changes accompanied the remediation of critical findings, the fix-review round in the original engagement does not substitute for a new audit of those changes.

The final deliverable should be a closing report or updated version that clearly documents which issues were fixed, which were mitigated with trade-offs acknowledged, and which were accepted as known risk with rationale. A report that simply lists all findings as “resolved” without this differentiation is incomplete. Not all “resolutions” are equivalent—some findings are genuinely fixed, some are mitigated by adding documentation or configuration warnings, and some are accepted as known risk. These three outcomes carry very different implications for deployment decisions.

The status column in the findings table is one of the most information-dense parts of the document. Focus on critical and high-severity issues and whether they were fixed. Check the status for each finding. “Fixed” is good. “Acknowledged” means the team knows about the issue but didn’t fix it—which is concerning. “Disputed” means the team disagrees with the finding—which is a significant red flag. If multiple critical or high items are acknowledged or disputed, think twice.

Evaluating the Scope Section for Gaps

The scope section is the most under-read section of most audit reports. Executives look past it to get to findings. Legal counsel treats it as boilerplate. This is a mistake—the scope section defines exactly what the report does and does not cover, and the gaps in scope are often where the most significant risks live.

Smart contract audits fail quietly when scope is vague. A real process will lock a specific commit hash or tagged release as the audit target. It will define what contracts are in scope, what dependencies are assumed, and what is explicitly out of scope.

When reading the scope section, ask the following:

Which contracts are covered? How many contracts were reviewed? Were all system contracts audited? Often only a subset gets reviewed. It is common for audit scopes to exclude governance contracts, upgrade proxy logic, administrative multisig configurations, and deployment scripts—all of which represent real attack surfaces.

What external dependencies are excluded? Auditors must verify all external dependencies including imported libraries, oracles, and third-party integrations that the contract relies on at runtime. Many reports explicitly exclude third-party contracts, oracle integrations, and bridge dependencies from scope. If your protocol’s security relies materially on the behavior of any of these excluded components, that exclusion is a gap that matters.

What conditions and assumptions govern the review? Audits examine code under specific assumptions at a fixed moment, but real protocols exist in constantly changing contexts where those assumptions can become invalid without warning. A scope section should articulate what assumptions the auditors made about the operating environment—what oracle conditions, liquidity conditions, or governance assumptions the review was predicated on.

Was the documentation reviewed? The scope should specify whether the review included design documentation, whitepapers, and specification documents alongside the code. An audit that reviews only code without validating it against stated design intent will miss a significant category of bugs—where the code does what the developer wrote but not what the protocol is supposed to do.

Scope constraints become dangerous when protocols implement novel mechanisms or operate in rapidly evolving markets. DeFi protocols increasingly depend on cross-protocol composability and complex economic mechanisms that create emergent behaviors impossible to predict through static code analysis. Traditional audits excel at identifying implementation-level vulnerabilities—reentrancy patterns, access control failures, integer overflows. But they consistently struggle with protocol-level economic risks that only emerge in adversarial market conditions.

What an Executive Summary Should and Should Not Claim

The executive summary is the section most likely to be read by non-technical stakeholders. It is also the section most likely to make claims that the underlying report does not support. Knowing what a legitimate executive summary contains—and what it should never assert—is essential for anyone who reviews, shares, or signs off on audit reports.

A legitimate executive summary should include: an identification of the specific commit hash or tagged release reviewed, the dates of the engagement, a brief description of the methodology employed, a summary of findings by severity category, and a high-level characterization of the system’s security posture relative to what was reviewed.

The purpose section should explain the scope and limitations of the review. The disclaimer should emphasize that the report reflects the security posture at a specific time and does not replace ongoing security practices.

An executive summary should never claim:

That the codebase is “secure” or “safe to deploy” in absolute terms
That no vulnerabilities exist beyond those identified in the report
That the audit covers components or integrations that were explicitly excluded from scope
That a finding status of “resolved” means the entire system is now free of that class of vulnerability
That the report constitutes a certification of any kind

No audit can certify absolute security. Auditors must clearly communicate scope limitations and the residual risk that remains after their review is complete. An executive summary that implies otherwise—through selective language, vague superlatives, or the omission of scope limitations—is misrepresenting the report’s actual contents. This matters not just for technical accuracy but for legal exposure: presenting an audit report as security certification to investors or counterparties can create material misrepresentation risks.

An audit significantly reduces risk but doesn’t eliminate it entirely. No serious auditor guarantees the total absence of vulnerabilities. Any summary that suggests otherwise should be treated as a red flag about the audit firm’s professional standards.

Red Flags in Low-Quality Reports

Not all audit reports represent equivalent work. Several structural and content characteristics reliably indicate a low-quality engagement.

Absence of scope specificity. A report that does not name specific contract addresses, commit hashes, or file paths reviewed is a report that cannot be independently verified. Without this information, there is no way to confirm that the code reviewed matches the code deployed.

Zero or near-zero findings. If you find an auditor who reports zero findings, be suspicious: it is more likely they did not look carefully enough than that your code is perfect. A good sign is that the audit found issues—it shows thoroughness. Zero findings means either simple code or a superficial audit. A legitimate engagement on a reasonably complex codebase should surface at minimum a range of low and informational issues.

Vague finding descriptions. As discussed above, findings that lack specific code references, concrete impact modeling, and actionable remediation are indicators of template-driven or tool-only reviews.

No methodology section. Ask what tools were used, whether manual review was performed, and who the senior auditors are. A firm that cannot explain its process in plain terms is a red flag. Methodology transparency matters as much as results. A report that does not describe how the review was conducted—what tools, what manual techniques, how many auditors, what the review timeline was—provides no basis for evaluating the completeness of the coverage.

Implausibly short engagement timelines. Any firm offering a professional audit in less than two business days for a complex protocol should be avoided. Rushing audits is one of the leading causes of missed critical vulnerabilities before mainnet launch. Line-by-line manual review of a multi-contract DeFi protocol takes time—measured in weeks, not hours.

Generic, non-specific language. Generic audits often miss project-specific risks. Look for auditors who are willing to customize their methodology around your use case, architecture, and protocol design to uncover vulnerabilities that standard reviews overlook. If the report’s narrative sections could describe any DeFi protocol—if all specific protocol terminology, design intent, and architecture discussion have been removed—the engagement was not meaningfully customized to the system under review.

No post-finding communication process. Auditing does not end with report delivery. Firms that refuse to assist with remediation, re-audits, or clarifications leave you unsupported during critical phases. A quality firm documents findings in preliminary form, communicates them to the client team, provides a remediation window, and then verifies fixes.

How to Compare Reports from Different Firms

It is increasingly common for protocols to commission multiple audits—either concurrently from different firms or sequentially as the codebase evolves. Comparing these reports requires understanding why they differ and what those differences mean.

The most important thing to establish when comparing reports from different firms is whether they reviewed the same code. Scope alignment must be verified at the commit hash level. Two reports that reviewed different versions of the same contracts are not comparable without reconciling the changes between versions.

Once scope parity is established, look at:

Overlap vs. divergence in findings. It is expected that two competent auditors reviewing the same codebase will find some of the same issues and some different issues. At the heart of a quality audit, at least two security auditors should be assigned to review the same codebase. This ensures that each line of code undergoes multiple sets of expert eyes, catching issues that might slip past a single reviewer. When comparing across firms, findings that appear in one report and not the other are worth investigating. They may indicate that one firm’s methodology was more thorough in specific areas, or that one firm over-classified an issue that the other assessed differently.

Severity disagreements. If Firm A rates a finding as critical and Firm B rates the same issue as medium, neither is necessarily wrong—but the discrepancy demands resolution. Read both firms’ severity definitions and compare them against the specific issue. Often these discrepancies reflect different assumptions about exploitability prerequisites.

Methodology differences. OWASP SCSVS offers a security requirements framework for EVM-based smart contracts, and SCSTG complements it with test methodologies. The SCSVS defines levels of verification, with Level 1 aimed at baseline protection and higher levels intended for stronger assurance. Meanwhile, EthTrust provides a certification-oriented model for Ethereum smart contract reviews, separating automated checks from manual review and deeper logic analysis. Together, these frameworks help buyers compare audit depth more meaningfully. When firms align their methodology against recognized frameworks, cross-comparison becomes more structured.

Findings present in both reports but with different remediation statuses. If an issue was found by Firm A, marked as resolved, and then found again by Firm B, the resolution from the first engagement was either incomplete, applied to the wrong version of the code, or reversed by subsequent changes. This pattern should trigger an immediate conversation with the development team.

With over 100 active security firms, identifying a reliable partner requires looking at historical performance and specific technical capabilities. The disparity between these companies is high, ranging from automated scanning giants to boutique research firms. Volume of past audits and firm reputation are relevant but not sufficient criteria. Look at the quality of public reports a firm has published. Are the findings specific and well-reasoned? Do the reports contain genuine analysis of protocol-level risk, or are they primarily lists of standard vulnerability classes?

Questions to Ask After Receiving a Report

When you receive an audit report, the document is the beginning of a conversation, not the end of one. Here are the questions that matter most.

For the audit firm:

What commit hash was reviewed, and is that identical to the version being deployed to mainnet?
Which findings, if any, were accepted as known risk rather than fixed? Who made that decision, and was it documented?
Were any components of the system explicitly excluded from scope that interact with in-scope code? What assumptions were made about those excluded components?
Did the review include economic and game-theoretic analysis, or was it confined to code-level vulnerability detection?
For each finding marked “resolved,” can you confirm that the specific root cause was addressed—not merely that a surface-level mitigation was applied?
If significant code changes were made during remediation, was a full re-review of the changed modules conducted, or only a targeted fix review?

For your development team:

Have any changes been made to the codebase since the audit’s commit hash? If yes, what was changed and has it been reviewed?
Are there components in production that interact with the audited contracts but were out of scope? How are those components being managed?
Are all critical and high findings resolved? For those that are not, what is the accepted risk rationale, and who in the organization has formally accepted that risk?
What ongoing security practices—bug bounties, monitoring, incident response—are in place that supplement the audit?

For legal counsel evaluating the report:

Does any language in the executive summary make claims beyond what the findings and scope sections actually support? If so, those claims should be clarified or excised before the report is shared externally.
How is this report being characterized to investors or counterparties? Confirm that it is being presented as evidence of due diligence and point-in-time review, not as a certification of security.
Regulators increasingly look for evidence that projects have taken reasonable security steps to protect consumer assets. An audit by a reputable firm signals due diligence, improving trust and facilitating smoother adoption, fundraising, and partnerships. That signal is valuable only when the audit is accurately characterized.

The Ongoing Security Question

One final structural point that the audit report itself cannot answer: what happens next. A single audit is an essential snapshot, but security is a continuous effort. Any significant updates or new features added to your smart contracts require a new audit for the updated code.

This creates “assumption drift”—the gradual divergence between audit assumptions and operational reality. Teams make seemingly small adjustments that individually appear low-risk but collectively create new attack surfaces. Assumption drift is not addressed by the original audit report and is not visible in its findings. It is the responsibility of the team to recognize when the gap between the audited state and the current production state has grown large enough to require a new engagement.

The best projects combine auditing with bug bounty programs, real-time monitoring, and incident response capability. An audit report is one layer of a security posture, not the entire posture. The organizations that use audit reports most effectively treat them as a baseline and investment in ongoing security, not as a one-time checkpoint to satisfy external requirements.

Audit Report Evaluation Checklist

Use this checklist when evaluating the quality and completeness of any smart contract audit report you receive.

Scope and Version Control

The report identifies a specific commit hash or tagged release reviewed
The scope section names all contracts included in the review
The scope section explicitly identifies what is out of scope
The dates of the engagement are clearly stated
The version of the code reviewed matches the version being deployed

Methodology

The report describes how the review was conducted (tools used, manual review procedures, number of auditors)
Both automated analysis and manual review are described
Dynamic testing or fuzzing methodology is documented if applicable
The report identifies what documentation (specs, whitepapers) was reviewed alongside the code

Finding Quality

Each finding includes a specific title, root cause description, impact analysis, and remediation guidance
Findings reference specific contracts, functions, and code locations
High and critical findings include a proof-of-concept or explicit reproduction scenario
Remediation recommendations are concrete and actionable, not generic
No finding descriptions appear to be templated or non-specific to the protocol under review

Severity Classification

The report defines its severity scale at the outset
Classifications account for both impact and exploitability/likelihood
The rationale for high and critical classifications is explained
Any findings on the boundary between severity levels are discussed

Remediation Record

Each finding has a clear resolution status (Fixed / Mitigated / Acknowledged / Disputed)
The report differentiates between genuine fixes, mitigations with trade-offs, and accepted risks
Fix-review scope is documented—confirming what was and was not re-reviewed
Findings with “Acknowledged” or “Disputed” status have documented rationale
No critical or high findings are marked resolved without a description of the fix applied

Executive Summary

The summary characterizes the review as point-in-time, not as an ongoing certification
No language implies the codebase is “secure” in an absolute sense
Scope limitations are mentioned in the summary, not only in the body
The summary does not claim coverage over excluded components
The report includes a standard disclaimer clarifying its limitations

Red Flags (Presence of Any of These Should Trigger Scrutiny)

Zero findings on a non-trivial codebase
No commit hash or code version reference
No methodology description
Finding descriptions that could apply to any protocol (no protocol-specific language)
All findings marked “resolved” with no status differentiation
Executive summary language that claims unconditional security
Engagement timeline inconsistent with the codebase size and complexity
No post-audit support or fix-review process described

After Receipt

Development team has confirmed no changes since the audited commit
All out-of-scope components that interact with audited contracts have been identified and their risk characterized
Ongoing security practices (monitoring, bug bounty, incident response) are in place
The report is being communicated to external parties in a way that accurately represents its scope and limitations
A plan exists for re-auditing when significant code changes are made