93% of Critical Vuln Disclosures Flow Through One Platform. Here's the Data.
What do live critical vulnerability flows look like in crypto? What happens to those vulns, and where do they get disclosed?
I’ve been tracking onchain hacks for years, and I run Immunefi, which means I have access to granular vulnerability disclosure data that doesn’t exist anywhere else. Combine that with some reasonable estimates for competitor platforms based on publicly available data, and we can begin to outline the onchain economy’s vulnerability flows.
So that’s what I did. Here’s what I found.
Where Do Critical Vulnerabilities Actually Get Disclosed?
This was the first question I wanted to answer. When a critical vulnerability is responsibly disclosed, where does it end up?
The answer surprised even me: about ~92.33% of all post-launch critical vulnerabilities in crypto flow through Immunefi.
Here’s the breakdown:
That’s a 381x gap between Immunefi and HackerOne, and a 87.9x gap between Immunefi and Cantina. Even against HackenProof, crypto’s 2nd biggest bug bounty platform, it’s roughly 14.5x based on generous assumptions.
It’s interesting that the user base sizes don’t explain the gap. Immunefi has around 60,000 registered researchers. HackenProof has 45,000. HackerOne claims to have millions. So Immunefi isn’t the largest platform by registered users, but it captures the vast majority of critical vulnerability flow. The difference in output far exceeds the difference in reach, which suggests that the researchers who find critical bugs are disproportionately choosing to submit them through Immunefi.
Methodology; how did we get to these numbers?
I want to be upfront about what I know precisely versus what I had to estimate. Bug bounty programs (BBPs) are only as transparent as their operating platforms make them.
Exact numbers (from Immunefi’s data):
7,695 confirmed BBP reports (audit competitions not included)
1,143 bug bounty program (BBP) confirmed crits for blockchain/smart contract assets
~14.9% crit rate on BBP valid reports
Estimated numbers:
HackenProof tends to split programs into multiple asset-specific programs, which inflates their overall program count, and most reports have low reward totals and activity. If we focus on blockchain and smart contract programs and count how many have total rewards exceeding their minimum listed critical bounty payout, the result is just 16 programs. If we look at these programs most generously and assume that the total rewards would only have been made up of the minimum reward critical bounties summed together, then we find a maximum of 79 critical bounty payouts across all these programs over the last 8 years of Hackenproof’s operation. In the absence of clearer report data, and in the interest of being charitable to Hackenproof, this is the number I used.
Cantina’s 13 BBP critical reports is their actual reported number, based on the total number of critical reports on their leaderboard, and with the understanding that criticals on Cantina can only be bug bounty reports. Almost all of their other reports are from audit competitions, not bug bounties.
Sherlock has 27 BBPs, but no critical reports that I am aware of and no transparency regarding report statistics. I conducted additional research using AI and was still unable to find any known critical reports. If a critical had been found through Sherlock, their insurance coverage would have been triggered to pay out the advertised $500,000 reward, and there has been no public indication that such a payout has ever occurred. Until demonstrated otherwise, my default assumption is that a critical report has never been submitted through Sherlock.
HackerOne has 6 live BBPs in web3, which have received a total of 3 critical vulnerability submissions. All 3 of these are on Coinbase’s program, and all 3 are ‘Business Logic’ criticals, not necessarily smart contract. Since they were high impact, we decided to include them anyway for completeness. Despite their massive general user base (millions), their blockchain bug bounty traction is minimal. I know for a fact that there was pre-Immunefi disclosure activity on HackerOne, but as we’re unable to view old/archived HackerOne programs, I cannot tally them.
A few limitations worth noting:
Competitor data is estimated based on publicly available data, not reported directly
Off-platform disclosures (researcher goes straight to project) aren’t captured; self-hosted bug bounty programs are known to be much less effective than working through a platform, but they will capture some unknown amount of vulnerability flow. I believe these reports are probably a minority of all valid disclosures. Unfortunately, they leave no publicly identifiable data trail, so I’m unable to create a data-backed estimate of them
Loss figures depend on publicly reported incidents; some may go unreported
TVL is a rough proxy for “value at risk”; actual value at risk is likely to be much higher, given all the other ways hacks damage projects. See ‘The Real Impact of an Onchain Hack’
These limitations don’t impact the overall picture, but they’re worth keeping in mind.
If more data on vulnerability disclosure flows is made public after this article is posted, I would be more than happy to include it here in my analysis.
Post-Deployment: Disclosed vs. Exploited
Vulnerabilities in live code go one of three ways: they get disclosed responsibly through a bug bounty program, they get fixed privately, or they eventually get exploited. We can’t assess how many live critical vulnerabilities get found by their team in emergency fixes, but we can track onchain exploitations.
Here’s how the numbers break down: ~1,238 critical vulnerabilities disclosed via bug bounty platform vs ~320 vulnerabilities exploited onchain by blackhat hackers, for a total loss of around $6.75 billion USD.
For every critical vulnerability that got exploited onchain, around four were caught and disclosed responsibly through bug bounty programs.
The 320 exploited vulnerabilities represent onchain exploits only: protocol logic errors, ecosystem attacks, and smart contract language issues. These are the bugs that more audits or better bug bounties could have caught. I’m excluding infrastructure incidents (private key compromises, social engineering) and rugpulls, which aren’t code vulnerabilities and couldn’t have been reported via a BBP.
Is the Onchain Economy Getting Safer?
Vulnerability data is interesting, but the real question is whether we’re actually getting safer as an industry.
To test this, I compared annual hack losses against average TVL to get a “loss rate”. In other words, what percentage of secured value gets stolen each year. I used DefiLlama as my data source on TVL over the last 5 years.
2022 was the worst year on record, with the highest absolute losses and highest loss rate. Everything was on fire: Terra, Ronin, Nomad, FTX-adjacent chaos.
2024 marked a turning point. TVL recovered to near all-time highs (it peaked around $130B in December). Losses dropped to $1.27B, the lowest since 2020. Loss rate fell to 1.5%, a 64% reduction from the 2022 peak.
2025 saw losses climb back to $3.4B, pushing the loss rate to 2.8%. But that number is heavily skewed by personal wallet compromises and exchange wallet hacks, just one of which accounted for $1.5B.
Remove those opsec vulnerabilities outliers, and the real blockchain vulnerability impact for 2025 drops to ~790M with a loss rate of 0.66%. The underlying trend remains very positive, and one infrastructure breach doesn’t change that trajectory.
Exchanges remain an area where the industry needs to grow. High-profile incidents show that operational security around key management and internal signing processes hasn’t kept pace with the scale of assets under custody. As the stakes get higher, closing that gap will be one of the more important challenges to solve.
But when it comes to real blockchain code security, 2025 was a high point for the industry with just 0.66% lost to smart contract and blockchain vulnerabilities.
What This Means For You
A few takeaways from this data:
1. Where you run your bug bounty matters.
If ~92.33% of critical disclosures flow through Immunefi, running your program elsewhere means your program is invisible to most of the researchers who find the impactful critical vulnerabilities. Why security researchers choose Immunefi is a topic for another post.
2. Post-launch coverage isn’t optional.
Over 80% of Immunefi customers receive critical vulnerabilities via their Immunefi BBP. Audits are necessary but not sufficient. If you ship code without continuous bug bounty coverage, you’re relying on luck, which isn’t justifiable when you’re directly handling user funds.
3. The security trendline is positive.
Despite continuing hacks, onchain loss rates are down significantly. TVL is up. The ratio of value-secured to value-lost is improving. This isn’t a solved problem, but we are moving in the right direction.
Final Thoughts
When I started this analysis, I wasn’t sure what I’d find. The data could have shown that security efforts weren’t working, that losses were scaling with TVL, that ecosystem security was held together with duct tape.
Instead, the data shows meaningful progress. Loss rates are down. Vulnerability disclosure is concentrated around platforms that work, and Immunefi is carrying the lion’s share (92%+) of that burden. The security infrastructure that’s been built over the past few years is generating massive positive impact.
The future of the onchain economy is bright.