What 360 Critical Bugs Taught Us: Audit Findings Statistics
Quick answer. Most of the 360 Critical findings in Guardian's 337 published audit reports are errors in a protocol's own logic. 57% are labeled Logical Error, only two Reentrancy, and the most common titles describe something blocked or stuck.
Video transcript
Most Critical smart contract bugs are not textbook exploits. In Guardian's own published audits, they are errors in a protocol's own logic.
We counted every finding in Guardian's 337 published reports, more than ten thousand in all. That gives 360 Criticals, and 97 of those reports contain at least one.
Fifty seven percent are labeled Logical Error. Denial of service follows at twelve percent, then validation and access control. Only two are labeled reentrancy.
By what their titles describe, the biggest group is something blocked or stuck. Then come fee and reward accounting, drained funds, and miscounted shares or debt.
Availability is a security property. A protocol that cannot liquidate can become insolvent, even if nobody steals a token.
The split appears to follow complexity. Perpetuals, DEX, vault and launchpad reports contain a Critical far more often than stablecoin or bridge reports, many of which are deployment reviews.
Teams fix most Criticals, about four in five within the report. But nearly one in five was not fully resolved. Read the status, not just the count.
Write invariants for your own bookkeeping. Prove liquidations and withdrawals keep working under attack. Bind every external input to its trusted source. And fuzz from empty and first states.
Vanguard puts two independent teams on your code, one with manual review and invariant fuzzing, one driven by Helix, Guardian's AI auditor. Read the full report, or get a quote at guardian.security.
Smart contract audit findings statistics are hard to come by. Reports are published one at a time, and aggregate studies are rare.
This report counts every Critical finding in Guardian's public audit portfolio. Every report is public at guardian.security/portfolio, so any count can be traced to the findings behind it.
Two companion reports cover the rest of the lifecycle: Critical bugs in post-launch updates and Guardian's offchain findings.
Dataset and Method
The dataset is Guardian's published reports as of November 4, 2026. That is 337 reports for 100 clients, dated March 2022 to October 2026.
They hold 10,086 findings, and 360 of them (3.6%) are Critical.
How we counted:
- Source. The portfolio's JSON entries, counted with a Python script.
- Categories are as each report labels them, with spelling variants merged.
- Sectors are the report's own, or the client's when it lists none. They overlap.
- Title themes are keyword matches on finding titles. 144 of the 360 match none.
Limitations. These are published reports only, so work clients kept private is missing. Severity and status are what each report recorded; a later round can change them.
The portfolio does not record which technique found each finding. So this data cannot rank manual review against fuzzing or AI.
The data is also concentrated. GMX accounts for 74 of the 360 Criticals across 52 reports, and the five clients with the most hold 45.6% of them.
What the Criticals Are
97 of the 337 reports (28.8%) contain at least one Critical. 48 of the 100 clients have had one.
By label, 57.2% are Logical Error, 11.7% DoS, 6.9% Validation and 5.3% Access Control. Logical Error is the label for a protocol breaking its own rules.
The classic bug classes are rare at Critical severity. Two Criticals are labeled Reentrancy, two Oracle Manipulation, one Signatures and one Inflation Attack.
Labels are coarse, so we also counted what each title says happens. Themes overlap, so the column does not sum to 360.
| The title names | Criticals | Share of 360 |
|---|---|---|
| Something blocked, stuck or bricked | 63 | 17.5% |
| Fees, rewards, vesting or claims | 40 | 11.1% |
| Funds drained or stolen | 34 | 9.4% |
| Shares, debt or double counting | 33 | 9.2% |
| Liquidations | 22 | 6.1% |
| Access control and authorization | 22 | 6.1% |
| Oracles and prices | 21 | 5.8% |
| Rounding, decimals, overflow or underflow | 19 | 5.3% |
| Cross-chain messaging | 14 | 3.9% |
| Signatures, nonces and replay | 5 | 1.4% |
| Reentrancy | 3 | 0.8% |
Availability is a security property. The largest group describes something that stops working, such as liquidations that cannot execute.
A protocol that cannot liquidate can become insolvent without anyone stealing a token.
Bookkeeping of value (fees, rewards, shares and debt) also produces more Criticals than any single attack technique.
Three examples
GMX V2.2 Crosschain, Part 1 (C-04): GMX read the bridged token's address from a message that carries user-supplied data. A user could bridge one token and be credited for another.
Dolomite GMX V2 Module (ITVF-1): a borrower could keep a full withdrawal pending with a minimum output that could never be met. Resubmitted after every cancellation, it meant no liquidation could pass.
MUX Perps (C-01): an attacker holding 1 wei of liquidity could front-run a victim's liquidity order with a donation that inflated the LP price. The victim would receive zero shares, and the attacker could withdraw both amounts.
All three were resolved.
Sectors, Fixes and Trends
Protocol type and language
The split appears to follow complexity. 42.4% of DEX reports contain a Critical, as do 39.8% of perpetuals, 38.5% of yield vault and 45.8% of launchpad reports.
Only 3.4% of stablecoin and 7.7% of bridge reports do, partly because many are deployment and configuration reviews. USDT0 alone has 35 published reports, none with a Critical.
The perpetuals figures lean on one codebase: 49 of the 83 perpetuals reports and 72 of their 126 Criticals are GMX's.
Rust reports fare about the same as Solidity: 30.0% of the 20 that list Rust contain a Critical, against 30.9% of the 301 that list Solidity. The Rust sample is small.
Fix status
Teams fix most Criticals. Four in five (80.6%) were resolved in the report itself, against 68.3% of Highs and 49.3% of all findings.
Still, 70 of the 360 (19.4%) were not fully resolved: 11 partially resolved, 41 acknowledged and 18 with no final status.
Acknowledged means no fix was recorded in that report. It can reflect a design decision, a later fix or code that never deployed, so read the resolution text.
Trend by year
The portfolio grew almost eightfold from 2023 to 2025. Over the same period, Criticals per report fell from 4.19 to 0.74, and to 0.34 so far in 2026.
The data cannot say why. The mix of work changed: 2025 and 2026 include many re-reviews of mature codebases and deployment checks, and 2026 is a partial year.
New code has not stopped producing Criticals. Veranta's V2 review, published on October 26, 2026, contains four.
Lessons Developers Can Act On
- Write invariants for your own bookkeeping. Fuzz properties such as total shares matching the sum of balances.
- Prove the protocol keeps working under attack. Test liquidations and withdrawals with pending requests and reverting callbacks.
- Bind every external input to its source. Take the token from the trusted sender; require every oracle field.
- Test empty and first states. Fuzz from first deposits and empty pools, not only a funded steady state.
- Read status, not just counts. Before relying on an audit, read the resolution of every Critical and High.
- Keep reviewing after launch. 11 of 49 published update reviews contain a Critical; see the post-launch updates report.
Contracts are not the only surface, either. See where crypto hack losses came from.
How Guardian Finds Criticals Before Launch
Guardian's flagship audit, Vanguard, puts two independent teams on the same scope. Team A uses expert manual review and an exhaustive invariant fuzzing suite.
Team B is driven by Helix, Guardian's AI auditor. Only human-verified findings reach the report.
The invariant suite targets accounting, rounding, solvency, math and edge states, where this report finds most Criticals. It stays with the team as a regression harness.
Guardian also reviews changes to the audited scope for six months after production. For more on invariant testing, see why audited teams are getting hacked.
Frequently Asked Questions
What are the most common critical vulnerabilities in smart contract audits?
In Guardian's 337 published reports, 57% of the 360 Criticals are labeled Logical Error. By title, the largest groups are something blocked or stuck (63), fee and reward accounting (40), drained funds (34) and miscounted shares or debt (33).
How many smart contract audits find a Critical vulnerability?
97 of the 337 published Guardian reports (28.8%) contain at least one Critical. That rises to 42.4% of DEX and 39.8% of perpetuals reports, and falls to 3.4% of stablecoin reports.
Is reentrancy still a common critical bug?
Not in this data: two of the 360 Critical findings are labeled Reentrancy, and three titles mention it. Most Criticals are errors in a protocol's own logic and accounting.
Do teams fix Critical findings?
Mostly: 80.6% of Criticals were resolved in the published report, 3.1% partially resolved, 11.4% acknowledged and 5.0% left with no final status. For Highs, the resolved share is 68.3%.
Sources
- Guardian: Public audit portfolio, 337 reports and 10,086 findings (as of November 4, 2026)
- GitHub: GuardianAudits/Audits, the published report PDFs
- Guardian: GMX V2.2 Crosschain, Part 1 (July 26, 2025)
- Guardian: Dolomite GMX V2 Module (January 11, 2024)
- Guardian: MUX Perps (February 6, 2025)
- Guardian: Veranta V2 Review (October 26, 2026)
- Guardian: Vanguard audit
Find your Criticals before launch
Vanguard puts two independent teams and an invariant fuzzing suite on your code, then keeps reviewing every change for six months.