A report says a contract has one Critical finding and twelve Informational findings.
Is that contract safe to interact with? You can't answer that from the numbers alone. You need to know what Critical means to the firm that wrote the report, and whether that finding was actually fixed before deployment.
The stakes for getting this wrong are real. Hacken's 2025 data puts total losses from blockchain hacks at $4.0 billion, with $512 million of that tracing directly to smart contract vulnerabilities and a further $2.12 billion to access-control failures. These loss categories show why due diligence must examine both contract-level access controls and operational key-management practices.
Audit findings form a key component of crypto risk evaluation, but audit quality should be assessed alongside tokenomics, ownership concentration, custody and compliance risks.
Understanding Severity Classifications
Most smart contract audit firms use a variation of a five-tier severity scale: Critical, High, Medium, Low, and Informational. However, individual audit firms or even individual reports from the same firm, such as Trail of Bits'LooksRare security audit, may customize tier definitions or omit specific tiers depending on the report's scope.
The definitions below are general interpretive guidance. The audit firm’s own severity methodology should control when reviewing a specific report.
- Critical: A Critical finding generally combines catastrophic impact with credible exploitability, such as unrestricted loss of funds, permanent protocol failure, or complete administrative compromise.
- High: A High finding generally creates a substantial risk of fund loss, privilege escalation or major protocol disruption, but may have a narrower impact or lower exploitability than a Critical issue.
- Medium: Medium findings often involve meaningful but limited impact, require uncommon conditions, or affect availability, accounting, or user protections without creating an immediate protocol-wide loss.
- Low: Limited security or functional impact, such as minor edge cases or small operational inconsistencies that do not directly expose assets.
- Informational / Optimization: Code quality, style recommendations, documentation gaps, and gas optimizations that pose no direct security threat.
A Worked Example, Reading a Real Severity Table
Numbers without context are easy to misread. Consider a real smart contract security review of a DeFi protocol, which produced the following exposure breakdown across its core smart contracts: 0 Critical, 5 High, 2 Medium, 4 Low, and 1 Informational finding.
Severity | Count |
Critical | 0 |
High | 5 |
Medium | 2 |
Low | 4 |
Informational | 1 |
Reading this table correctly requires asking key questions beyond the raw numbers:
- What were the High findings actually about? In this scenario, the High-severity issues centered on unvalidated input parameters and fee calculation edge cases during pool rebalancing.
- Were they fixed? A severity count alone shows the initial risk profile; it does not show the final deployment state.
- What was the audited commit versus the deployed version? Verification requires checking whether the final deployed bytecode matches the auditor's re-tested commit hash.
Start With Scope and Context
Before reviewing severity counts, confirm what the audit actually covered. A report showing zero Critical findings may simply reflect a narrow or restrictive audit scope. Always evaluate:
- Repository & Commit Hash: The exact code commit evaluated by the auditor.
- Included vs. Excluded Contracts: Which protocol files were in scope and which were explicitly left unexamined.
- Deployment Context: Targeted chain environments, compiler versions, and external dependencies or oracles.
- Finding Density: Evaluate findings relative to codebase size (e.g., lines of code or contract complexity) rather than relying on a raw count alone.
Why The Same Word Doesn't Mean the Same Thing Across Firms
This is where a lot of due diligence goes wrong. Not every audit firm uses an identical taxonomy, and assuming they do leads to miscomparing two reports that aren't actually using the same scale.
Audit firms do not share a single standardized scoring taxonomy. CertiK, for instance, uses Critical, Major, Medium, Minor, and Informational in its How We Audit guide.
CertiK’s Major tier is the second-highest category in its taxonomy, but it should not automatically be treated as numerically equivalent to another firm’s High tier. As seen in CertiK's published audit of Core DAO (0 Critical, 1 Major, 0 Medium, 3 Minor, 8 Informational), evaluating findings requires checking each firm’s specific methodology guidelines rather than assuming tier-for-tier equivalence.
The practical takeaway: when comparing audit reports across two different platforms, or across two different firms auditing the same platform, check each firm's own severity definitions before assuming a Major finding from one report is equivalent in risk to a High finding from another.
Remediation Status, The Part Most People Skip
A severity label describes how bad a finding is. Remediation status describes whether anyone actually did something about it. These are two separate axes, and conflating them is one of the most common due diligence mistakes.
Remediation status describes how a project responded to a finding. Common remediation labels include:
- Resolved / Fixed: The auditor verified code changes that address the finding in the source repository. (Note: This does not automatically confirm that the fix was compiled and deployed to mainnet).
- Acknowledged: The project has reviewed the finding, but the report does not confirm full remediation. This may reflect accepted residual risk, intended design, planned future updates, or economic trade-offs. The team’s response and deployed code must be examined to determine remaining risk.
- Mitigated / Partially Resolved: Code or operational controls were added to reduce exploitability without eliminating the root condition.
- Unresolved / Risk Accepted / Won't Fix: The issue remains in the audited source code without dedicated fixes.
An acknowledged Critical finding should be treated as unresolved unless later code, remediation evidence, or a follow-up review demonstrates otherwise.
Trail of Bits' publicly available LooksRare report shows this distinction in practice. Several findings in that report carry an Acknowledged response from the project team, with additional comments explaining why the team chose not to change the code, for instance, citing gas cost trade-offs or citing that a theoretical attack path wasn't practically exploitable given the contract's actual usage pattern. That's a materially different risk posture than a finding that was actually patched.
Verifying Deployed Code Against Audited Commits
Evaluating a "Resolved" finding requires verifying the chain of assurance:
- Project Internal Fix: Team claims the code was updated.
- Auditor Verification: Auditor re-examines the specific commit and marks it fixed.
- Mainnet Deployment: Remediated code is deployed on-chain.
- Bytecode Verification: Deployed bytecode matches the auditor-reviewed commit, implementation addresses are verified, and proxies or initializers are properly configured.
This is the single most important habit for reading any audit report: never treat a severity count as the final word. A protocol with three Critical findings, all marked Resolved with a verified follow-up commit, is in a fundamentally different risk position than a protocol with one Critical finding marked Acknowledged and left in production code.
What Tools Catch, and What Requires Human Judgment
One more layer worth understanding: not every finding in an audit report was found the same way, and that has implications for how much confidence to place in a report that used automated scanning alone versus one that combined automation with manual review.
The cited Trail of Bits analysis of 246 findings across 23 smart contract audits suggests that automated tools can detect many known technical patterns, while a substantial share of context-dependent findings still require manual analysis.
Economic, governance, and transaction-ordering risks often require protocol-specific reasoning, simulations, or custom invariants beyond generic static analysis. An automated scanner report should not be treated as a substitute for a full manual audit review.
The practical implication: an audit report generated purely from automated scanning output, with no evidence of manual review, is missing close to half of the finding categories that actually show up in real audits. When evaluating whether an audit is credible, checking whether the firm performed manual review alongside automated tooling is as important as checking the severity counts themselves.
How This Feeds Into the Overall Risk Score
Audit findings aren't a pass/fail gate on their own. They're one structured input into the broader quantitative risk-scoring framework, where severity, remediation status, and audit methodology combine with other factors like tokenomics and holder concentration into a single assessment. A platform with a clean-looking severity count but several Critical findings marked Acknowledged rather than Resolved should score differently than a platform with the same finding count but full remediation, even though the headline numbers might look identical at a glance.
Bottom Line
The severity label tells you the shape of a risk. The remediation status tells you whether that risk is still live. Reading only one of the two gives you half the picture, and the half most people stop at is the one that looks reassuring on its own. Before treating any audit report as a green light, check the actual severity definitions the firm used, confirm what happened to each Critical and High finding after it was reported, and look for evidence of manual review rather than automated scanning alone.
Frequently Asked Questions
Does a clean audit report mean a contract is 100% safe to use?
No. An audit is a point-in-time review of the code as it existed on the day the audit was conducted. It doesn't cover code changes made after that date, and it generally can't catch every category of risk, particularly economic design flaws like oracle manipulation or flash-loan-driven exploits, since those depend on how a contract behaves under adversarial market conditions rather than a line-by-line code defect.
A documented example occurred in August 2024, when Ronin Network's bridge was exploited for $12 million. Security analysis by Halborn highlighted how uninitialized state or misconfigured post-upgrade initializers in upgraded contracts can expose severe vulnerabilities if deployment procedures are not strictly verified.
How can you verify that an audit report is genuine?
Check the report on the auditor’s official canonical repository or website rather than relying on a project-hosted PDF or badge. Confirm the canonical report URL, audit date, project contract addresses, commit hash, and whether the document represents a draft or final release.
Does a contract need to be re-audited after an upgrade or fork?
Material upgrades and forks should undergo fresh security review. The depth of review should reflect the size and risk of the changes—a minor documentation update does not carry the same risk profile as altering core withdrawal or proxy logic.
Practical Audit-Reading Checklist
- Verify Official Source: Confirm the report on the auditor's canonical domain or repository.
- Check Scope & Commit: Match the reviewed commit hash and list of in-scope contracts.
- Read Firm Definitions: Review the auditor's specific severity scale and methodology.
- Examine High/Critical Issues: Check specific descriptions for all severe findings.
- Verify Remediation Evidence: Confirm code fixes were re-reviewed by the auditor, not just acknowledged by the project team.
- Match Deployed Bytecode: Verify that mainnet deployed contracts match the audited commit.
- Review Upgrades & Admin Keys: Check proxy upgrade permissions, multisig setups, and post-audit changes.
- Treat as Point-in-Time: Remember that an audit evaluates code state at a specific snapshot and is not a permanent guarantee.
Disclaimer: This article is for educational purposes only and is not financial, legal, investment, or security advice. Audit reports reflect a point-in-time review and do not guarantee a contract is free of vulnerabilities. Review the full report and current contract state before making any decision.
