.png){kind=logo}
An audit report is the most quoted and least read document in crypto. Projects put the word "audited" on a landing page, and most readers stop there. The report itself says something narrower: a named firm looked at a named set of files, at a named commit, for a fixed number of days, and found a list of issues graded on that firm's own scale. This guide explains how to read the three parts that matter most, the scope statement, the severity scale, and the closing caveats, and it sets out what an audit does not tell you. It is a factual reference and does not constitute investment or financial advice.
What does a smart contract audit report actually certify?
It certifies that specific code, at a specific moment, was reviewed against a specific set of checks, and nothing more. The Enterprise Ethereum Alliance's EthTrust Security Levels Specification, version 2, published on 13 December 2023, defines the object of review as "Tested Code", meaning the Solidity source for one or more related contracts plus the bytecode produced by compiling it with specified parameters. The same specification states plainly that "no amount of security review can guarantee that a smart contract is secure against all possible vulnerabilities". That sentence belongs at the top of every audit report, and in practice most firms include a version of it in their disclaimer section.
Three consequences follow. First, an audit is a point-in-time review, so any change deployed after the audited commit is unaudited until someone reviews it again. Second, the report only covers what the engagement letter put in scope, so code outside the listed files is not covered even if it sits in the same repository. Third, the grades in the findings table are the auditor's judgement under the auditor's rules, and those rules differ materially between firms and between competitive platforms. Each of these points is examined below.
How do you read the scope statement?
Start with the commit hash, then the file list, then the exclusions. Quantstamp's own guide to reading its reports puts it directly: a repository's commit hash "can be considered a digital fingerprint of the code within that repository", and if the hash changes after the audit, the repository "contains code that is out-of-scope (aka not reviewed by Quantstamp auditors)". The same guide explains diff audits, where the firm reviews only the differences between two commits, and any code outside that difference is not audited.
A serious reader therefore compares the audited commit against the deployed bytecode. Block explorers with verified source let you do this without tooling, because the verified source is tied to a compiler version and settings. If the deployed contract was compiled from a later commit, the audit covers an ancestor of the live code, not the live code. The security firm Zellic calls this gap "audit drift" and describes it as a well-known problem across the industry. Zellic is a vendor and this is a commercial blog, not a primary source, but the term is useful shorthand.
| Element | Where it usually appears | If it is missing or vague |
|---|---|---|
| Commit hash or tag | Front matter, "Source code" or "Scope" section | You cannot tie the report to any deployed contract. Treat the audit as unverifiable. |
| File list or contract list | Scope section, sometimes an appendix | You cannot tell whether the contract holding user funds was reviewed. |
| Explicit exclusions | Scope section, "Out of scope" subsection | Assume nothing outside the file list was reviewed, including libraries, proxies and deployment scripts. |
| Engagement length | Summary or "Timeline" | A short review of a large codebase is a shallow review, whatever the findings table says. |
| Diff audit flag | Summary, near the commit hashes | If two hashes are listed, only the delta was reviewed. Prior code carries its prior audit status. |
| Fix review or re-audit | Findings table "Status" column, or a second report | Findings marked "acknowledged" or "unresolved" remain in the live code. |
The Nomad bridge incident is the standard illustration. On 1 August 2022 attackers drained roughly 190 million dollars from the bridge after a routine upgrade initialised the trusted root value to 0x00, which the contract also used to denote an unproven message, so every message was treated as proven, according to the analysis published by Google Cloud's threat intelligence team. SecurityWeek reported that Quantstamp's earlier audit had found 40 issues including one flaw related to the exploit, rated low risk, and that Quantstamp said the Nomad team had misunderstood the issue and the exploited code differed from what was audited. A low-severity finding on the audited commit became a total loss on the deployed commit.
What do the severity labels mean, and why do they differ between firms?
They mean whatever the issuing firm's published scale says, and the scales are not interchangeable. The table below sets four published systems side by side. Immunefi's scale governs bug bounty payouts rather than audits, but it is the most widely referenced impact list and auditors often borrow from it.
| Organisation and scale | Top grade | Middle grades | Bottom grade | Distinctive rule |
|---|---|---|---|---|
| Immunefi Vulnerability Severity Classification System v2.3 | Critical: direct theft of user funds, permanent freezing of funds, protocol insolvency, unauthorised NFT minting | High: theft of unclaimed yield, temporary freezing of funds. Medium: griefing, unbounded gas consumption | Low: contract fails to deliver promised returns but does not lose value | Exploits that need elevated privileges or uncommon user interaction may be downgraded. Attacks needing privileged addresses are out of scope by default. |
| Code4rena | High: assets can be stolen, lost or compromised directly, or indirectly via a valid attack path without "hand-wavy hypotheticals" | Medium: assets not at direct risk but protocol function or availability impacted, or value leaks under stated assumptions | QA: low risk plus governance and centralisation risk | All roles assigned by the system are assumed trustworthy. User mistakes are capped at QA. |
| Sherlock | High: direct loss of funds without extensive external conditions, and the loss is significant (more than 1 percent and more than 10 dollars) | Medium: loss of funds needing external conditions or specific states, or breaks core contract functionality | Low: not accepted as a valid finding | "Likelihood is not considered when identifying the severity and the validity of the report." |
| Quantstamp | High: puts many users' sensitive information at risk or is reasonably likely to cause catastrophic reputational or serious financial impact | Medium: affects a subset of users or moderate financial impact. Low: small and not exploitable on a recurring basis | Informational: relevant to best practice, no immediate risk. Undetermined: impact uncertain | Adds an explicit "Undetermined" bucket rather than forcing a guess. |
Two structural differences deserve attention. The first is whether likelihood counts. Sherlock states outright that likelihood does not affect severity, so an unlikely but viable path to significant loss is High. Code4rena grades on the credibility of the attack path, and Immunefi lets privilege requirements pull a finding down. The same bug can be High on one platform and Medium on another without anyone being wrong. The second difference is the treatment of privileged roles. Code4rena assumes assigned roles are trustworthy, and Sherlock trusts internal roles by default unless the project's README declares them untrusted. An audit under those rules says almost nothing about what an administrator key could do to you. If the protocol has an upgradeable proxy and a multisig, the report's silence on admin risk is a scoping decision, not a clean bill of health.
Trail of Bits uses a different geometry. Its 2019 review of 246 findings from its own smart contract audits grades each finding on two axes, severity and difficulty of exploitation, and treats "high-low" (high severity, low difficulty) as the worst cell. The same review reported that 35 percent of high-severity findings were unlikely to be detected automatically, and that about 78 percent of the high-low findings could in principle be caught by combined static and dynamic analysis. Those figures come from one firm's own dataset and are seven years old, so they describe that firm's practice rather than the industry.
Why do likelihood, preconditions and trusted roles change the grade?
Because severity is a compressed judgement about impact under assumptions, and the assumptions are set by the engagement, not by the reader. When you see a Medium, ask which assumption is doing the work. Sherlock's Medium explicitly covers losses that need "certain external conditions or specific states". Code4rena's Medium covers value leaks "with a hypothetical attack path with stated assumptions". In both cases the preconditions are named in the finding, and you should read them, because a precondition that looks exotic to an auditor in a two-week engagement may be routine for a protocol that lists a new collateral asset every month.
The Euler Finance case shows how a single missing check slips through when it is added late. On 13 March 2023 an attacker used flash loans to drain about 197 million dollars from Euler, according to Chainalysis. The flaw sat in a donateToReserves function added by the eIP-14 upgrade in 2022, which let a user burn collateral without a solvency check, leaving unbacked debt that could then be self-liquidated at a profit. Cointelegraph reported on 14 March 2023 that the eIP-14 code had been audited in July 2022 under Sherlock's programme, that the audit missed the vulnerability, and that Sherlock's coverage vote approved a 4.5 million dollar claim with 3.3 million dollars paid the same day. Rekt, an industry newsletter rather than a primary source, notes that Euler listed six auditors on its documentation site. Six audits did not add up to one audit of the line that mattered.
What does "audited" not mean?
It does not mean the live code was reviewed, it does not mean the review covered the ways money is actually lost, and it does not mean the protocol is safer in any measurable way. Each of those claims has evidence behind it, of varying quality.
On the first point, the Nomad and Euler cases above are enough. On the second, the numbers are stark. Chainalysis's 18 December 2025 report recorded more than 3.4 billion dollars stolen in 2025, with the February compromise of Bybit accounting for about 1.5 billion dollars of that total. The FBI's public service announcement of 26 February 2025 attributes the Bybit theft to North Korean actors it tracks as TraderTraitor. The Bybit loss did not involve a smart contract bug at all. Chainalysis's mid-year update of 17 July 2025 put the first-half 2025 total at 2.17 billion dollars stolen from services, with Bybit alone about 69 percent of it. A June 2026 preprint by Stefan Beyer of Oak Security, which has not been peer reviewed and whose author works for an audit firm, combined 23,818 public audit findings from 22 firms with 218 exploit incidents between January 2022 and March 2026 and found that private-key compromise, phishing and social engineering accounted for about 49.6 percent of cumulative losses while representing a negligible share of published audit findings. The same preprint reports that 105 of the 218 incidents, or 48 percent, hit protocols that had at least one public audit beforehand, and that those incidents represented roughly 4.3 billion dollars of the 7.76 billion dollar aggregate.
On the third point, the peer-reviewed evidence is thinner than the marketing suggests, and it cuts both ways. Perez and Livshits, at USENIX Security 2021, examined 23,327 contracts flagged as vulnerable by six academic detection tools and found that only 1.98 percent had been exploited, amounting to at most 8,487 ETH, or 0.27 percent of the roughly 3 million ETH at stake. That tells you automated vulnerability labels overstate real risk, which matters when an audit report's Low and Informational sections are padded with tool output. Zhou and colleagues, at the 2023 IEEE Symposium on Security and Privacy, systematised 181 DeFi incidents with at least 3.24 billion dollars in losses between April 2018 and April 2022 alongside 30 audit reports and 77 academic papers, and built a common frame for comparing incidents rather than a headline audit-effectiveness statistic. Landsman, Lyandres, Maydew, Rabetti and Zhang, in a paper presented at the 2025 Journal of Accounting and Economics conference, studied audit reports and bounty programmes linked to more than 4,000 DeFi protocols launched between 2020 and 2025. Their reported findings are that having any audit at launch is not significantly associated with post-launch breach probability or hack losses, that audits by top-tier reviewers are associated with fewer breaches, and that audited protocols tend to attract larger total value locked. The strongest available evidence says who audited matters and that an audit merely existing does not. Note that only the working-paper text and search excerpts of that study were accessible for this article, so the exact effect sizes are not reproduced here.
| Incident | Date and loss | Audit status at the time | What the audit did not cover |
|---|---|---|---|
| Nomad bridge | 1 August 2022, about 190 million dollars (Google Cloud threat intelligence, SecurityWeek) | Quantstamp audit, 40 findings, related issue rated low risk (SecurityWeek, citing Quantstamp) | The upgrade that set the trusted root to 0x00 changed code after the audited version. |
| Euler Finance | 13 March 2023, about 197 million dollars (Chainalysis) | Multiple audits, eIP-14 upgrade audited in July 2022 via Sherlock (Cointelegraph) | The missing solvency check in donateToReserves was in scope but not caught. Sherlock paid a coverage claim. |
| Bybit | 21 February 2025, about 1.5 billion dollars (FBI IC3 PSA 26 February 2025) | Not a contract bug. Attributed by the FBI to North Korean TraderTraitor actors. | Signing interface compromise sits outside any smart contract audit scope by definition. |
Is there any legal standard that an audit must meet?
In most jurisdictions, no. There is no general statutory requirement that a DeFi protocol be audited, and no licensing regime for audit firms comparable to statutory financial audit. The closest thing to a binding technical standard in a major jurisdiction is narrow. Article 36 of Regulation (EU) 2023/2854, the EU Data Act, sets "essential requirements regarding smart contracts for executing data sharing agreements". It requires such contracts to offer access control and "a very high degree of robustness to avoid functional errors and to withstand manipulation by third parties", a mechanism to terminate or interrupt execution, archiving of transactional data and code on termination, rigorous access control at governance and contract layers, and consistency with the underlying agreement. Article 36(2) requires the vendor to perform a conformity assessment and issue an EU declaration of conformity. Under Article 50 the Regulation applies from 12 September 2025. Two limits matter: the requirements attach to smart contracts used to execute data sharing agreements under the Act, not to DeFi generally, and conformity is self-declared by the vendor rather than certified by a third-party auditor.
For financial institutions the pressure comes from prudential rules rather than audit mandates. The Basel Committee's crypto capital treatment, covered in our piece on Basel III crypto capital requirements, penalises unbacked crypto exposure regardless of any audit. Custody approvals, discussed in our coverage of FDIC crypto custody approval, focus on key management and operational controls, which is precisely the human-vector risk that audits do not address. Stablecoin issuers face reserve and disclosure rules, summarised in our Q2 2026 stablecoin regulation update, and here contract audits are one input among several rather than a compliance endpoint.
How should you weigh an audit when assessing a protocol?
Weigh it as one control among several, and read it for what it excludes before what it finds. A practical order of reading:
- Match the audited commit to the deployed, verified source on a block explorer. If they differ, list what changed.
- Read the out-of-scope section and the trust assumptions. Note every privileged role the auditor was told to trust.
- Read every High and Critical finding in full, including its preconditions and its status. "Acknowledged" means live.
- Check whether a fix review or second report exists for the resolved findings.
- Look at the engagement length against the codebase size, and at whether the firm has published prior reports in the same protocol category.
- Check for a live bug bounty, its maximum payout and its scope, because a bounty covers time after the audit ended.
- Separate contract risk from custody and signing risk, which the audit does not touch and which produced most 2025 losses.
The EthTrust specification offers a useful frame for the depth question. Its Security Level [S] is designed so that most conventional Solidity code "can be certified by an automated static analysis tool", Level [M] "mandates a stricter static analysis" with human judgement on whether certain features are justified, and Level [Q] adds analysis of business logic to confirm the code "correctly implements what it claims to do". Most audit reports do not state which of those depths they reached, so the reader has to infer it from the findings. A report with twenty Informational findings and no logic-level discussion was probably a Level [S] exercise, whatever the cover says.
The same scepticism applies to adjacent products. Tokenised collectibles, examined in our analysis of fractional NFTs, often cite audits of a vault contract while the valuation risk lives in the underlying asset. Funds marketed on sustainability criteria, covered in our review of ESG crypto funds, may hold audited protocols, but a fund-level audit and a contract-level audit are different documents with different scopes.
How strong is the evidence in this article?
Not uniformly strong, and the table below grades each claim honestly. The regulatory and scale definitions rest on primary text. The incident narratives rest on a mix of primary attributions and trade press. The claim that audits do not reduce breach probability rests on a single working paper whose full text could not be parsed in this session, so it is graded down accordingly.
| Claim | Evidence type | Strength |
|---|---|---|
| Audit scope is defined by commit hash and file list, and later code is out of scope | Auditor's own published guidance (Quantstamp), EEA EthTrust specification | Strong for the definition, though the sources are industry documents rather than law. |
| Severity scales differ materially between Immunefi, Code4rena, Sherlock and Quantstamp | Each organisation's current published criteria, opened in this session | Strong. Direct quotation of primary documents. |
| Trail of Bits figures on automated detectability (35 percent, 78 percent) | One firm's 2019 blog analysis of its own 246 findings | Weak to moderate. Single-firm sample, seven years old, not peer reviewed. |
| Nomad: upgrade changed code after the audit, related finding rated low | Google Cloud threat intelligence analysis, SecurityWeek reporting Quantstamp's statement, Zellic blog | Moderate. Root cause is well documented, the audit-scope detail is second-hand. |
| Euler: eIP-14 audited July 2022, vulnerability missed, Sherlock paid claim | Chainalysis analysis, Cointelegraph report, Rekt newsletter | Moderate. Trade press consistent with each other, no first-party audit report read. |
| Bybit was a signing compromise, not a contract bug, attributed to North Korea | FBI IC3 public service announcement, Chainalysis | Strong. Government attribution, consistent with industry forensics. |
| Human-vector attacks account for about half of cumulative 2022 to 2026 losses and most of 2025 losses | June 2026 arXiv preprint by an audit-firm author | Weak to moderate. Not peer reviewed, dataset drawn from rekt.news, author has a commercial interest. |
| Only 1.98 percent of tool-flagged vulnerable contracts were exploited | Peer-reviewed paper, USENIX Security 2021 | Strong for its dataset, but the data end in 2021 and cover tool output, not human audits. |
| Any audit at launch is not associated with lower breach probability, top-tier auditors are | Working paper presented at the 2025 JAE conference, full text not parsed here | Weak in this article. The finding was read from search excerpts and the abstract page could not be opened, so treat it as provisional. |
| EU Data Act Article 36 imposes essential requirements and self-declared conformity, applying from 12 September 2025 | Regulation (EU) 2023/2854 text via EUR-Lex and a mirror site | Strong. Primary legal text. |
Frequently asked questions
Does a "Critical" finding mean the protocol was hacked?
No. It means the auditor found a path to a critical impact in the reviewed code. Read the finding's status column. If it says fixed and a fix review confirms it, the path was closed before or after deployment. If it says acknowledged, the project chose to leave it.
Is an audit from a well-known firm enough on its own?
Not on its own. The working paper by Landsman and colleagues reports that top-tier reviewers are associated with fewer breaches, which supports paying attention to who audited. It also reports that merely having an audit at launch is not associated with lower breach probability, and both Euler and Nomad had reputable auditors.
What is the difference between an audit and a bug bounty?
An audit is a fixed engagement on a fixed commit. A bounty is an open, continuing invitation to report bugs in the live code, paid on a severity scale such as Immunefi's v2.3. The bounty covers the period after the audit ends and the code that shipped, which is why the two are complementary rather than substitutes.
Why do competitive audit platforms reject Low findings?
Sherlock's judging guidelines state that only High and Medium findings are valid, because those cause loss of user funds. Low and informational issues are handled elsewhere or not at all. This keeps the payout pool focused, but it also means a Sherlock report will not list the code-quality issues that a traditional firm's report would.
Does the EU Data Act require DeFi protocols to be audited?
No. Article 36 applies to smart contracts used to execute data sharing agreements under that Regulation, and it requires a vendor's self-declared conformity assessment, not a third-party audit. It says nothing about lending pools, exchanges or bridges.
How do I check whether the deployed contract matches the audited one?
Take the commit hash from the report, open the repository at that commit, and compare the source against the verified source on a block explorer for the deployed address. Differences in compiler version, constructor arguments or any file mean the live contract is not exactly what was audited.
Sources
- Immunefi, Vulnerability Severity Classification System v2.3: immunefi.com/immunefi-vulnerability-severity-classification-system-v2-3/
- Code4rena, Severity classifications: docs.code4rena.com/competitions/severity-categorization
- Sherlock, Criteria for Issue Validity: docs.sherlock.xyz/audits/judging/guidelines
- Quantstamp, How to Read an Audit Report, 22 June 2021: quantstamp.com/blog/how-to-read-an-audit-report
- Trail of Bits, 246 Findings From our Smart Contract Audits, 8 August 2019: blog.trailofbits.com
- Enterprise Ethereum Alliance, EthTrust Security Levels Specification version 2, 13 December 2023: entethalliance.org/specs/ethtrust-sl/v2/
- Regulation (EU) 2023/2854 (Data Act), EUR-Lex: eur-lex.europa.eu/eli/reg/2023/2854/oj. Article 36 and Article 50 text checked against data-act-law.eu/article/36/ and data-act-law.eu/article/50/
- FBI Internet Crime Complaint Center, North Korea Responsible for $1.5 Billion Bybit Hack, 26 February 2025: ic3.gov/psa/2025/psa250226
- Chainalysis, 2025 Crypto Theft Reaches $3.4 Billion, 18 December 2025: chainalysis.com/blog/crypto-hacking-stolen-funds-2026/
- Chainalysis, 2025 Crypto Crime Mid-Year Update, 17 July 2025: chainalysis.com/blog/2025-crypto-crime-mid-year-update/
- Chainalysis, Euler Finance Flash Loan Attack Explained, 15 March 2023: chainalysis.com/blog/euler-finance-flash-loan-attack/
- Cointelegraph, Euler Finance blocks vulnerable module, working on recovering funds, 14 March 2023: cointelegraph.com
- Rekt, Euler Finance: rekt.news/euler-rekt (industry newsletter, not a primary source)
- Google Cloud Threat Intelligence, Dissecting the Nomad Bridge Hack: cloud.google.com/blog/topics/threat-intelligence/dissecting-nomad-bridge-hack
- SecurityWeek, Nearly $200 Million Stolen From Cryptocurrency Bridge Nomad, August 2022: securityweek.com
- Zellic, You Could Have Found the Nomad Hack (audit drift): zellic.io/blog/audit-drift/ (vendor blog, not a primary source)
- Perez and Livshits, Smart Contract Vulnerabilities: Vulnerable Does Not Imply Exploited, USENIX Security 2021: usenix.org/conference/usenixsecurity21/presentation/perez
- Zhou et al., SoK: Decentralized Finance (DeFi) Attacks, IEEE Symposium on Security and Privacy 2023: arxiv.org/abs/2208.13035
- Beyer, The Audit Gap in Blockchain Security, arXiv preprint, June 2026 (not peer reviewed): arxiv.org/html/2606.15465v1
- Landsman, Lyandres, Maydew, Rabetti and Zhang, Auditing Smart Contracts, working paper, 2025 JAE Conference: accounting.wharton.upenn.edu (PDF), listed at accounting.wharton.upenn.edu/jae-2025/papers/
