In 2023, we published our first comprehensive analysis of the true cost of onchain hacks, covering the 2021 to 2023 period. That analysis produced Amador’s Hack Impact Estimate, a framework for quantifying what a hack actually does to a project beyond just the stolen funds. Two years later, we have new data, and the picture has shifted in important ways.

Updated hack impact estimate for 2024-2025: If your protocol suffers a hack today, the data suggest you will lose roughly $25,000,000 USD in direct theft, watch your token shed 61% of its value over the following six months, and face sustained price depression that 84% of hacked tokens never recover from within that window. The organizational toll remains unchanged: expect at least 3 months of lost productivity, roadmap delays, and team disruption.

The headline numbers tell a story of an industry that is maturing but still deeply vulnerable. The overall count of hacks has stayed high. The median theft per incident has dropped. But the largest exploits have grown even larger, and the market punishment for getting hacked has become more severe, not less.

What changed since 2021-2023?

Our original study covered 234 publicly known hacks across three years, totaling $7.2 billion in stolen funds. The 2024-2025 dataset now adds another 191 hacks, totaling $4.67 billion. Taken together, that gives us 425 hacks and $11.9 billion in damage across five years of onchain security incidents.

A few high-level shifts stand out.

The frequency of hacks has plateaued at a high level. In 2024, there were 94 known hacks, and in 2025, there were 97. For comparison, 2021 saw 71, 2022 saw 66, and 2023 saw 97. The industry is not seeing fewer exploits year over year. If anything, the number of incidents has settled into a steady, elevated baseline.

The median hack has gotten smaller, but the tail risk has gotten worse. The median theft during 2024-2025 was $2,200,000, roughly half the $4,500,000 median from 2021-2023. That might sound like progress, but it is misleading. The average theft in 2024-2025 was $24,500,000, which is 11.1 times the median. In the earlier period, the ratio was 6.8 times. That widening gap reflects a power law distribution that has become even more extreme. A small number of catastrophic exploits now account for a disproportionate share of total damages.

The concentration at the top is staggering. The five largest hacks in 2024-2025 accounted for 62% of all funds stolen. The ten largest accounted for 73%. At the very top, the Bybit exploit alone, at $1.5 billion, represented 44% of all funds stolen in 2025 and 32% of the entire two-year total.

Funds stolen

Over 2024-2025, the 191 publicly known hacks impacted a combined $4,670,000,000 USD. Breaking that down by year: $1.27 billion was stolen in 2024 across 94 incidents, and $3.4 billion was stolen in 2025 across 97 incidents.

The year-over-year jump in 2025 is substantially attributable to a handful of massive exploits. Remove the Bybit hack and 2025’s total drops to roughly $1.9 billion, still a significant figure that underscores the breadth of the problem even outside the largest single incident.

The average hack in 2024-2025 resulted in the theft of $24,450,550 USD. The median hack resulted in the theft of $2,200,000 USD.

Compared to 2021-2023, the average has dropped from $30.8 million to $24.5 million, and the median has dropped from $4.5 million to $2.2 million. Both shifts suggest that the typical hack is extracting less value than before. But this is cold comfort when a single Bybit-scale event can wipe out in one afternoon what two dozen smaller hacks would take months to accumulate.

The power law distribution we identified in our original analysis has only become more pronounced. Many hacks are small. But the catastrophic ones are now larger than anything the 2021-2023 period produced.

Where the money went: Centralized exchanges accounted for just 20 of the 191 hacks in 2024-2025, but those 20 incidents were responsible for $2.55 billion, or 54.6% of total stolen funds. DeFi protocols and other targets made up the remaining 171 hacks but accounted for 45.4% of the dollar volume. The Bybit, DMM Bitcoin, WazirX, and BtcTurk exploits alone demonstrate that centralized custodial risk remains one of the most consequential attack surfaces in crypto.

Market impact

In our 2021-2023 study, we covered 176 hacks with token price data and found a median six-month decline of 53%. For this update, we tracked 82 hacked tokens across 2024-2025 and measured their price performance at five time intervals after the exploit.

The updated numbers:

The initial shock is roughly the same. Within two days, a hacked token drops about 10% at the median, consistent with the earlier period. But from that point forward, the 2024-2025 data tells a darker story. The six-month median decline has worsened from 53% to 61%. That is a meaningful shift. It suggests that the market has become less forgiving of security failures, not more.

Looking at the severe end of the distribution, the numbers are equally grim. At the three-month mark, 47.3% of hacked tokens had lost more than half their value, and 8.1% had lost over 90%. At six months, 56.5% were down more than 50%, and 14.5% were down more than 90%.

Perhaps the most telling statistic: 83.9% of hacked tokens showed sustained price suppression six months after the exploit. That is up from 77.8% in the 2021-2023 data. Only about 16% of hacked tokens managed to trade above their hack-day price six months later.

In the previous analysis, we noted that market impact likely continues to intensify beyond six months. The 2024-2025 data confirms this suspicion. The decay curve does not flatten at six months. It steepens. Whatever trust a token commanded before the hack, the market extracts a lasting penalty that compounds over time.

The caveat from our original analysis still applies: we cannot fully isolate hack impact from broader market conditions. A token that fell 61% over six months may have been affected by sector-wide drawdowns, project-specific governance failures, or other factors. But the consistency of the pattern across 82 different tokens, in both bull and bear conditions, strongly suggests that hack-driven damage is the primary force at work.

What this means practically: Most token projects rely on their liquid tokens as treasury reserves and growth capital. A 61% median decline in token value translates directly into a 61% reduction in a project’s financial runway, its ability to hire, its capacity to fund development, and its leverage in partnerships. The market impact of a hack is not an abstract price chart problem. It is an operational crisis that compounds the direct theft.

Dependency and organizational impact

Our original analysis described dependency impact (second-order effects on interconnected protocols) and talent/organizational impact (lost time, personnel turnover, and roadmap disruption). These categories remain difficult to quantify with precision, but the 2024-2025 period offers additional evidence for how severe they can be.

On the dependency front, the growing interconnection of DeFi protocols has expanded the blast radius of individual exploits. Cross-chain bridges continue to represent systemic risk. Liquid staking tokens, restaking derivatives, and composable lending markets have created new dependency chains that did not exist during the 2021-2023 period. When a protocol at the base of one of these dependency stacks is compromised, the cascade of damage can extend far beyond the initial exploit.

The collapse of Elixir’s deUSD stablecoin in November 2025 illustrates this dynamic with painful clarity. When Stream Finance disclosed a $93 million loss from an external fund manager, the damage did not stop there. Elixir had parked roughly 65% of deUSD’s collateral with Stream. As Stream’s own stablecoin xUSD dropped 77%, deUSD’s backing effectively vanished. What followed was a textbook dependency cascade: Stream froze withdrawals, deUSD redemptions halted, panic selling hit Curve pools, and over $30 million was dumped onchain as holders raced to exit. deUSD ultimately lost more than 97% of its value, and Elixir was forced to sunset the stablecoin entirely, coordinating with Euler, Morpho, Compound, and other protocols to manage the liquidation process. A single loss event at one protocol cascaded through collateral dependencies to destroy a stablecoin and disrupt multiple lending markets.

On the organizational side, the pattern we described in 2023 has held steady. Hacked projects consistently lose their security leadership within weeks of the incident. The recovery period consumes at minimum three months of focused effort. Core product development stalls. Hiring becomes harder as the hack signals weakness to prospective talent.

The estimate remains: if you get hacked, expect to lose at least 3 months of forward progress to remedial security work, leadership turnover, and organizational recovery.

Updated estimate: the total cost of a hack in 2024-2025

Bringing the numbers together, here is the updated picture:

1. The average hack steals $24,500,000 USD at the moment of exploit. The median is $2,200,000, but the distribution is heavily skewed toward rare, massive events.

2. The median hacked token loses 61% of its value within six months, up from 53% in the 2021-2023 period. 84% of hacked tokens show sustained price depression six months post-hack, up from 78%.

3. Dependency risks have grown as DeFi composability has deepened, expanding the potential blast radius of any single exploit.

4. The organizational cost remains roughly 3 months of lost time and effort, consuming the team’s attention, delaying the product roadmap, and often costing the project its security leader.

The updated Amador’s hack impact estimate: if your protocol gets hacked today, expect to lose approximately $25,000,000 USD, see your token price decline by 61% over six months, face an 84% probability that your token price never recovers within that window, and burn at least 3 months of organizational effort on response and remediation.

What the data tells us about the state of onchain security

The comparison between the two periods reveals a mixed picture. On one hand, the median theft per hack has declined, which may reflect the gradual maturation of smart contract security practices, more widespread auditing, and the growth of bug bounty programs. On the other hand, the market punishment for getting hacked has grown harsher, the concentration of damage among the largest exploits has intensified, and the overall number of hacks remains stubbornly high.

The industry has not yet solved the security problem. It has shifted its shape. Smaller exploits are somewhat less damaging than they were three years ago. But the largest exploits are now enormous, and the market has become less willing to give hacked projects the benefit of the doubt.

This has a clear implication for how protocols should think about security investment. The question is not whether your protocol can survive a typical hack. The question is whether your protocol can survive being in the tail of the distribution, because the tail is where the real destruction happens.

Closing thoughts

The initial theft is the start of the damage, not the end. Behind every headline number sits a longer, quieter story of collapsing token prices, evaporating treasuries, departing team members, and roadmaps that never get built. The 2024-2025 data makes this even clearer than the 2021-2023 data did.

The only durable defense is sustained investment in security at every layer: rigorous code review, comprehensive auditing, active bug bounty programs, and the continued development of better automated detection and prevention tools. A new onchain security stack is forming, and it works, but only if protocols adopt it.

That is the work we are doing at Immunefi: building effective security across the full onchain stack, so that hacks stop being an inevitability and start becoming a rarity.

TLDR: War rooms are inevitable if you’re building anything worth protecting onchain. Prepare now or get rekt later.

You’re solving for two things simultaneously: stop the bleeding and preserve user trust. Lose either, and recovery becomes exponentially harder.

Parallel execution wins. Sequential thinking kills. Delegate accordingly to three: Ops Lead, Security Analyst, Comms Lead.

The Call Always Comes at the Worst Time

It was 5:50pm on a Saturday in Lisbon when I messaged Alexander Angel at Primitive Finance. Two words: “U up?” His response was instant. “Don’t scare me like that.” I told him this was not a drill.

That message kicked off 48 hours of nonstop crisis management and a war room that pulled together some of the best security minds in DeFi to save over $1.2 million in user funds. I’ve been in dozens of these since founding Immunefi, and each one reinforced the same hard truth: you will never feel ready. The protocols that survive are the ones that built muscle memory before the punch landed.

Here’s everything I’ve learned about running a war room that actually works.

Before the Breach: Preparation You’ll Probably Skip but Really Shouldn’t

Have an incident response playbook written and distributed before you need it.

Know how to reach every critical party at 3am on a Sunday. If their phones have the do not disturb feature on, you need to configure exceptions.

Decide operational roles in advance. Know who knows how to do what, before you need it.

Map your entire infrastructure: every contract, every admin key, every multisig signer.

And if at all possible, run a simulation/war game first.

You probably won’t do any of this. Most teams don’t. That’s why they get rekt when the call comes.

The Primitive Finance war room succeeded in part because Alex Angel knew exactly who to pull in. He tapped the Dedaub team for deep technical analysis, me for comms and coordination, and Emiliano Bonassi for his leadership under fire. That roster was very intentional. Alex had been watching the security community, noting who showed up in previous postmortems, and who had the temperament for battle stations. There’s an important lesson here: build your war council before the war starts.

What You’re Solving For

Every war room serves two masters: stop further losses and preserve user trust. They are equally important, and they often pull in opposite directions.

Pausing contracts might stop the bleeding but triggers panic in your community. Going silent while you investigate preserves operational security but erodes confidence by the hour. Losing trust can be fatal even when funds are recovered. I’ve seen protocols survive nine-figure exploits because they communicated well, and I’ve watched smaller hacks destroy projects because the team went dark.

You need both tracks running from minute one.

Step 1: Confirm and Pause

The first thing you do is verify the exploit is or appears real in any way. If there is even a hint of reality to it, then pause affected contracts, lock down permissions, and cut off every possible drain vector. Speed matters here more than certainty. A false positive costs you some inconvenience. A slow response costs you millions.

At Primitive Finance, we confirmed the vulnerability within 15 minutes of the Dedaub team’s disclosure. But here’s what made that war room uniquely terrifying: Primitive was a truly decentralized protocol. No admin keys. No multisig. The contracts couldn’t be paused or changed. That constraint shaped every decision that followed.

Step 2: Assemble the War Room (Three Roles Only, No More)

A small, trusted group moves faster than a crowd. Every additional participant slows decision-making and increases leak risk. You need three roles. That’s it.

The Ops Lead is the conductor. They timebox decisions, manage workflows, maintain composure, and enforce frequent sync cycles. Without this discipline, the room spirals haphazardly. Arguments metastasize. Recovery stalls. Emiliano Bonassi filled this role for Primitive, and within minutes of joining he was designating players, assigning timezones, carving out responsibilities, and building the roadmap forward. No hesitation. No committee.

The Security Analyst finds the truth. Use as many analysts as you need to find the root cause. They identify the attack vector and scope, build mitigations and patches, monitor for secondary attacks, and validate readiness to unpause. At Primitive, the Dedaub team (Yannis Smaragdakis and Neville Grech) worked through the entire night building the whitehack. Yannis didn’t sleep.

The Comms Lead manages trust. Clear, calm, factual updates on a predictable cadence. No silence. Poor communication causes bank-run behavior faster than the exploit itself. I built out the full comms plan for Primitive’s disclosure while the technical team developed the whitehack in parallel. One bad tweet from the wrong person can undo hours of technical progress.

Step 3: Parallel Execution (Not Sequence)

This is where most war rooms fail. Teams instinctively want to finish forensics before making decisions, and finish decisions before communicating. That sequential thinking is catastrophic.

Everything gets parallelized to minimize response times and act fast.

Here’s your comms cheat sheet; prepare them all as soon as you can:

First, document everything. War room transparency is a key part of demonstrating professionalism and post-exploit transparency. It sends the right message. AI makes this easier than ever.

Second, make a plan for things going horribly wrong; how do you fastest stem the bleeding and communicate that your protocol is frozen? If you can’t, how do you protect users by guiding them to a near-effortless way to protect their funds? The clock is ticking, and you need to protect users as much as possible the moment you learn there is no other option.

Third, chart out the happy path, where you buy time until you can make a transparent post-mortem report to share with the broader community. That starts with messaging that inspires confidence and patience. It should go live on socials and whatever community channels you have... but only after you confirm that the exploit is mitigated.

Only having covered the immediate needs, do you begin working on long term posts like the post-mortem (using your war room documentation) and confidence-inspiring messaging.

That’s it. And you want all this messaging ready, in parallel, before you know what you need to do. If you’re lucky, you won’t end up needing any of it. If you’re not, you’ll be happy you already know exactly what to say, to whom, and how.

Remain Calm (Seriously)

This sounds obvious, but it isn’t. When you’re staring at potentially millions of dollars in exposed user funds, with no guarantee your whitehack will work, composure is by far the hardest skill to express in the room.

But it’s what you’ll need every time. You can’t make the right calls without it.

The Postmortem: 24 to 48 Hours After

Within a day or two of resolution, publish a full postmortem, which should at minimum include a root cause, attack timeline, fix applied, and prevention roadmap.

The worst postmortems I’ve read are by teams who refuse to acknowledge their own responsibility. They strip the timeline of context, blame everything on “sophisticated hackers” as if that explains away months of ignored warnings, and publish something that reads like a legal filing rather than an honest accounting. I’ve watched this pattern destroy communities faster than the original exploit.

Consider CertiK and Kraken. A security firm drained roughly $3 million from Kraken over several days, claiming it was whitehat research, when a $4 demonstration would have proven the vulnerability. Kraken called it extortion. CertiK called it responsible disclosure. That kind of postmortem theater, where neither side owns the full truth, poisons the well for everyone. Or look at Poly Network, which lost around $600 million, eventually recovered funds through a “bug bounty” offer, and then treated the whole episode as if it were a legitimate whitehat engagement from the start. Everybody knew it was theft first. It’s ok (even wise) to negotiate with hackers, but gaslighting the community didn’t help their credibility.

I helped the team at PAID Network when they suffered an exploit in 2021. The temptation was there: minimize the damage, obscure the timeline, deflect blame. I pointed out the absolute necessity of owning how they got to that point. Thankfully, they listened. They took full responsibility, reported honestly, and their community stuck with them. But many teams don’t have someone in the room who can push them toward that honesty. A postmortem that hides the truth doesn’t protect you. It guarantees that when the real story leaks (and it always leaks), the trust damage is permanent.

Primitive Finance published their postmortem within 72 hours. It named names, credited contributors, laid out the exact timeline down to the minute, and explained the vulnerability in full technical detail. That postmortem became a case study in how to rebuild trust after a crisis.

When You Need to Negotiate With Blackhats

Not every war room ends with a successful whitehack. Sometimes the attacker gets there first. When that happens, you open communication channels (onchain messages work), offer safe return paths, and structure incentives that make cooperation more attractive than running. The Safe Harbor framework that I helped create through SEAL exists specifically to formalize this process, as I wrote about in “Preventing Crypto Armageddon“.

I’ve sat on both sides of these conversations. With Cream Finance, after roughly $8 million was stolen, we identified that the hacker was based in China and negotiated the return of funds by making clear we could expose his identity. He returned the money. That one worked. But I’ll be blunt: negotiation fails far more often than it succeeds. The KyberSwap exploit is a sobering example, where the attacker demanded full governance control of the protocol in exchange for returning $50 million in stolen funds. An unhinged demand that left no room for productive resolution.

If negotiation fails, you escalate: public warnings → forensics firms → exchange freezes → legal action → criminal filings. Each step must be thoughtful and proportional. Reckless escalation burns bridges you might need later. Hackers can be convinced to return the money.

The Primitive Finance Outcome

At 1:05am on a Sunday, Alex took a deep breath and pushed the whitehack button. It worked. We then scrambled to reach the biggest depositors to reset their remaining approvals. 0xMaki from SushiSwap jumped out of dinner and bribed his cab driver to get home faster. Calvin Liu reset his approvals from the chat.

Within hours, all user funds were safe. The Dedaub team earned a $250,000 bounty through the Founders Bounty program hosted on Immunefi, plus $25,000 directly from Primitive. Emiliano received $10,000 for leading the war room. The incentives aligned, and the system worked.

This story had a happy ending. Not all war rooms do. The difference, almost every time, comes down to preparation, the right people in the room, and the discipline to execute in parallel under pressure.

Build the Muscle Before You Need It

If you’re reading this and you don’t have an incident response playbook, write one this week. If you can’t reach your key security contacts at 3am, fix that today. If you haven’t mapped your infrastructure end to end, that’s your next task.

If you need help getting ready, book a call with me and I’ll get you on the right track.

War rooms are inevitable. Your survival depends on what you built before the call came.

For more on how Immunefi protects the onchain economy and the role of bug bounties in preventing the next crisis, visit immunefi.com. And if you want the deep data on what hacks actually cost, read “The Real Impact of an Onchain Hack“ on my Substack.

In short, the protocols that didn’t get hacked run what’s called “defense-in-depth,” and you should too.

The Swiss Cheese Model, Applied to Crypto

The defense-in-depth concept, also known as the Swiss cheese model, comes from risk engineering. Every security measure is a slice of Swiss cheese: each one has holes, no single layer is perfect. But stack enough slices together and the holes stop lining up. An attacker has to pass through every layer simultaneously to reach your funds, and the probability of that trends toward zero (though it will never reach it) with each layer you add.

This is not theoretical. I’ve seen the security setups of hundreds of protocols. The ones running a full defense-in-depth stack simply are the ones that are surviving, and that’s borne out in real smart contract impact rates which are (counterintuitively?) their best yet in 2025 at just 0.66% of TVL. The strategy is working.

The only barrier is adoption.

The New Onchain Security Stack, Layer by Layer

Here’s what a complete onchain code security stack looks like, ordered by when your code encounters each layer. In my view, every serious protocol should be running all of these within two years.

1. CI/CD Pipeline Security

Every pull request, every commit to a major branch, gets reviewed for vulnerabilities before it touches production. Automated vulnerability detection plus peer review on every code change. At Immunefi, we run this as PR reviews integrated into your GitHub workflow, with a combination of elite whitehats and AI vulnerability scanners.

Most vulnerabilities should die here, quietly, before anyone outside your team sees them. The cheapest place to mitigate an exploit is always the development pipeline.

2. Private Audits

A thorough point-in-time code audit from qualified security researchers who understand your system’s architecture and logic. You need this for major releases, protocol upgrades, and any significant change to how funds flow. The findings stay between you and your auditors until you’ve fixed them.

3. Audit Competitions or a Private Bug Bounty

Different from a private audit, and deliberately so. A competition opens your code to a broader pool of researchers competing against each other under a time constraint, surfacing a different class of bugs because you’re getting dozens or hundreds of independent perspectives instead of one team’s methodology. The competitive structure attracts top talent who might not be available for traditional engagements.

You could also structure it as a private bug bounty, wherein you invite top security researchers to break your code. It gets the same result if you structure the program right.

Run these before major launches. They complement private audits but they don’t replace them.

4. Public Bug Bounty Programs

Your permanent, always-on security layer. Every security researcher in the world has a financial incentive to find and responsibly disclose vulnerabilities in your live code, 24/7/365. This catches what audits missed, what changed since your last review, and what emerges from novel attack vectors nobody anticipated.

At Immunefi, ~92% of all critical crypto vulnerability disclosures flow through our platform. If you’re not running a bug bounty, you’re relying on attackers to find your bugs before whitehats do. That’s a bet you’ll lose eventually.

5. Safe Harbor

A legal framework that protects whitehat researchers who rescue funds during an active blackhat exploit. Without it, a researcher who spots an ongoing attack and moves funds to safety could face legal liability for touching those assets. Safe Harbor removes that barrier.

It costs you nothing to implement, and gives you another emergency response tool. It’s saved millions of dollars already. There’s no reason not to adopt.

6. Monitoring

Real-time observation of onchain and offchain activity around your protocol. Social monitoring catches coordinated attack chatter, and transaction monitoring catches anomalous fund movements.

This is your early warning system. It doesn’t prevent an attack by itself, but it could buy you the minutes that make the difference between a contained incident and a catastrophic loss.

7. Firewalls

Smart contract firewalls that pause or block suspicious transactions before they execute. If an attacker somehow passes through every previous layer, the firewall catches the anomalous transaction pattern and stops it. The final slice of cheese before the funds.

How to Sequence It

Building a full security stack takes time. You shouldn’t expect to have all layers running in place on day one. But there is an order of operations, and getting it wrong has cost billions to others.

First: Audits. Before anything else. Your auditors are not only reviewing code, but also educating you on how your security stack should work and helping you think through protocol architecture. This is where you learn what you’re protecting and how it can break. Start here.

Second: Audit competitions or a private bug bounty. Broader coverage, more eyes, different methodologies. This is your stress test before going live.

Third: Public bug bounty program. Your permanent layer goes up before or at launch. From this point forward, every researcher in the world can earn money by finding your vulnerabilities before attackers do.

Fourth: CI/CD pipeline security. Get your automated vulnerability detection and PR reviews into your development workflow so that every future code change is screened before it ships. If you can get this setup pre-launch, even better.

These four should be in place by launch day, or as close to it as you can manage. Safe Harbor, monitoring, and firewalls can follow, but don’t let “later” turn into “never.” Every week without a layer is a week where that slice of cheese is missing entirely.

Why This Matters Now

Security is the last great unsolved problem for crypto. When we solve it, tokenization eats the world, trillions move through crypto infrastructure, and every company becomes a web3 company. That’s the trajectory of the next five years, and the protocols that survive it will be the ones that made security a system rather than a specific event in time where they got an audit and stopped measures there.

No single product on this list is sufficient. An audit without a bug bounty leaves you exposed the moment your code changes. A bug bounty without monitoring means you might not notice an attack in progress. A firewall without underlying code review is a bandage on a wound you haven’t examined.

The whole point of defense-in-depth is that no individual layer needs to be perfect. Each one stops some attacks, and together, they stop nearly all of them. 2025 demonstrated that conclusively.

And the sooner we get these layers stood up across every major protocol in the space, the sooner we’ll unleash crypto to achieve its fullest and greatest potential.

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.

I’ve spent almost 600 hours in a hyperbaric oxygen chamber (HBOT), more than anyone you’ll ever meet. Today I’ll share what I did and why, to help you understand an understudied tool on your journey to total well-being.

Note: None of this is medical advice. I’m not a doctor, and don’t pretend to be one. I’m just trying to live the best life I can. I studied HBOT as much as I could, but you should always consult a medical professional before risking your health.

Hyperbaric Oxygen Therapy, or HBOT, is a treatment in a high-pressure capsule where you breathe purified oxygen. The pressure boosts your body’s ability to uptake oxygen into your cells. This extra oxygen seems to accelerate many physical processes.

You are delivering more oxygen to your cells than they have ever had before.

We don’t fully understand the effects of taking in extra oxygen, but what happens seems magical. Imagine faster healing for wounds and injuries. This includes tough hard-to-treat cases, like inflamed joints and deep brain injuries.

That healing process is exactly why I wanted to push HBOT to its limits.

Some context: I learned about HBOT years ago, as a way to improve health, boost metabolism, and treat chronic illness. I hypothesized that I could use HBOT to heal myself, and optimize my performance in the process.

I was not gifted with the world’s strongest constitution. A lifetime of allergies, illnesses, and eye problems, along with intense lifestyle stress, set me back. Decades of accumulated injuries and sufferings had taken their toll.

That’s where HBOT came in: I hoped it might rejuvenate my body, energy, and cognitive function in the process. Such had been reported anecdotally across many case studies… why not for me?

After 600 hours and hundreds of sessions, I can say this: IT WORKED. The gains I made from sustained HBOT years ago never faded. HBOT transformed my health for the better, from the inside out.

The Setup

I started with a soft-shell hyperbaric chamber. A plastic, zipper-sealed capsule designed for daily, repeatable use. It worked with an oxygen concentrator, providing about 93% purified oxygen through a mask. The chamber used regular air, pressurized by an air compressor. This design made it safe and fire-resistant.

I ran the chamber at 1.5 atmospheres of pressure, which is as high a pressure as you can go with a soft-shell chamber.

That number matters. At 1.5 ATA, your body experiences the equivalent of being about 3 meters (or 10 feet) underwater. Not enough to be harmful, but enough to change how oxygen acts on your body.

You feel it right away: a not-so-gentle squeeze on your body, pressure in your ears, and a tightness in your stomach. You feel something strange happening, and it’s not pleasant.

Each session lasted between 45 and 150 minutes. I did this almost daily for years. At peak usage, I’d be doing HBOT five days a week. During periods of extreme stress, or when I needed a boost, I did it daily to give me the edge I needed.

My protocol was simple:

• Mask on, oxygen flowing continuously.

• Occasional air breaks: Some people take air breaks every 15 minutes to stimulate a hormetic response. In my earlier tests, I didn’t see much change, so I only do it when comfortable or it seems right.

• Slow pressurization and depressurization help clear ears safely and prevent injury. After about a hundred hours, my body got used to rapid depressurization, which is great for air travel. But slow depressurization was crucial at first.

• I worked and took calls in the chamber when needed, but I mostly spent the time meditating or light reading. The pressure made intense reading difficult.

• No stimulants beforehand; even smoking can significantly alter the experience. I would do red light therapy from time to time pre-session, but that’s about it.

Now you know exactly what I did.

Here’s what happened.

What came next wasn’t random, and it wasn’t subtle. The experiment played out in three phases. I didn’t plan it that way; it was my biology reacting to the stress placed on it.

I experienced three stages:

• First, an adaptation period for the initial 1 to 15 sessions.

• Second, an acclimatization period for the following 15 to 70 sessions.

• Third, an optimization period covering all sessions after that first hundred or so.

Stage 1: Adaptation

This phase was intense and unmistakably physical.

• I felt deep joint and bone pain in my legs. It was unlike anything I had faced before. I can only describe it as “deep in my bones,” similar to the bone-chilling cold when you’re soaked in cold weather.

• I felt significant ear pressure, imbalance, and disorientation. It was like my senses were being slightly disoriented.

• Blurred, unstable vision, especially after prolonged early sessions.

• A heavy feeling of pressure made digestion slow. It was uncomfortable but still bearable.

• Mild claustrophobia inside the chamber that only passed with accumulated experience.

These early sessions had a distinctly medical feeling. Over time, I realized that this “adaptation” was my body healing old injuries.

As this phase ended:

• Joints became looser and more flexible.

• Long-standing pains disappeared.

• Vision stabilized and mildly improved.

• Pressure tolerance increased significantly.

By session 8:

• After each treatment, I felt focused and energized. I was almost euphoric for 6 to 8 hours.

• Sleep was very deep and restful, especially with evening sessions.

But these mild benefits were only the beginning.

Stage 2: Acclimatization

Most of the exotic symptoms faded through the acclimatization stage, sessions 15 to 70. By session 70, I experienced almost none of the early symptoms. Instead, I felt an intensification of the effects of high oxygen exposure. I felt better and better.

At the time I was under great stress, working far too much, often staying up until 4 a.m. My circadian rhythm was destroyed, my appetite poor. I was gaining weight. I wasn’t exercising enough. I had too many obligations, an overwhelming amount.

During this time, there were many crises. I dealt with challenges like fundraising, exchange collapses, and stablecoin depeggings. I took part in more than a hundred war rooms to stop and prevent onchain hacks. It was a rough time.

The hyperbaric oxygen chamber was a lifesaver. It helped my body heal faster. It also lowered my stress and gave me more energy and focus. Even after a full day of work, an HBOT session would consistently give me hours of extra concentration and working attention. This proved critical to both the survival and eventual success of @immunefi.

Stage 3: Optimization

By around session 100, something had forever changed. The benefits were no longer coming and going; they had become ingrained. My joints were as flexible as they had been in my teenage years. My thinking, focus, and memory improved in a way that stayed consistent. My vision got sharper, my tolerance for pressure grew, and my energy levels rose.

I was no longer bothered by ear or body compression from pressurization. What was once uncomfortable had become mild, leaving me functional in the chamber. I could work, take phone calls, read, write, meditate, or do whatever else I wanted in the chamber.

My eyes became problem-free. HBOT, along with other steps I took for eye health, made my vision the best it has been in years. My stress headaches subsided, and my weight stabilized.

At that point, hyperbaric oxygen felt less like the main driver. Instead, it acted as a modest amplifier, giving me an extra 15% energy per day and a few extra hours of focus. The real change was that the benefits didn’t seem HBOT-dependent anymore. They felt permanent, like a new, higher baseline.

What Went Wrong

The same healing power that made HBOT so compelling also forced me to confront its limits. When you apply that much oxygen to the body, it doesn’t amplify health alone.

Once, I tried hyperbaric oxygen when I was sick. I hoped it would help me recover faster. It appeared to help at first... but then it didn’t. HBOT didn’t create the problem, but it did accelerate the time to medical crisis.

The symptoms I experienced during my first HBOT sessions were real. The exotic sensations were real. Temporary blurriness of vision was real. The pressure and claustrophobia of being in a pressurized chamber was very real. Early on, it was a frightening experience, and it took a lot of courage to continue.

And yet, I don’t see these moments as failures of HBOT. I view them as reminders of its strength. Deep healing is usually a difficult, strange process.

There is risk here. HBOT demands caution, awareness, and restraint. But acknowledging that doesn’t diminish HBOT’s value: the net result was transformative. The benefits not only outweighed the downsides, but persisted long after. These benefits made the entire experiment unquestionably worthwhile.

The Benefits I Experienced

What surprised me most wasn’t any single effect, but how many parts of my life changed at the same time. The improvements didn’t stay isolated to one part of my body. They were wide-ranging and persistent.

I had more energy day to day. Focus came easily, lasted longer, and didn’t buckle under pressure. I remembered names better, faces stuck, and important details surfaced without effort.

At the same time, my health improved. My vision improved. Pain diminished. Allergies became less severe. My joints grew limber, which let me train harder and recover without feeling beaten up. I felt calmer, more stable, better able to handle stress, and happier.

Short-term session effects remain intense but less noticeable now. Many of these effects seem to have become ingrained. It feels as if my body now oxygenates more effectively all the time.

Bringing it all together

So, is this something you should try?

I want to make it clear that I’m not a doctor, and this isn’t medical advice. However, my own experiment shows that HBOT can be powerful. There are benefits (and risks) that you won’t find anywhere else.

If you’re interested in trying HBOT, it’s not cheap; it’s genuinely expensive. Individual sessions usually cost $50 to $200. If you want your own machine, expect to pay between $7,000 and $100,000. It’s not a casual hobby.

There are also real restrictions to consider. Many machines and countries have specific rules you must follow. Most need special technical or medical training, especially hard-shell machines. These add complexity that is essential to safely using HBOT.

Is this for everyone? Definitely not. But if you’re chasing peak performance and long-term health, it’s worth exploring HBOT.

So there you have it. That’s the story. How I did 600 hours of high-pressure oxygenation so you don’t have to. I don’t think anyone needs to spend as much time and energy as I did. I read studies, explored case studies, and reviewed hundreds of anecdotal stories. Most people can get real, tangible benefits in far less time and with far less effort.

If someone could have told me that at the start, I’d have been forever grateful. So that’s what I did for you: shared the lived HBOT experience I would have wanted someone to share with me. I hope it helps.

Subscribe now

The Immunefi team and I have just launched the first dispute resolution system for onchain bug bounties, and the odds are good that it changes the bug bounty world for the better. Through Immunefi Arbitration, security researchers and projects receive globally enforceable (covering 172 countries) resolutions by some of the best arbitrators in the world, provided by the London Chamber of Arbitration and Mediation. Such arbitration ensures that good faith security players will be protected from abuse.

Summary: 

• We created the world's first dispute resolution system (a court, if you will) for vulnerabilities, focused on onchain critical vulnerabilities.

• We had to do this, or billions of dollars will probably be lost to future hacks as a result of fearful security researchers refusing to disclose (or worse, executing the hacks themselves).

• Immunefi Arbitration sets a new high bar for security in bug bounty transactions globally; rulings are legally binding and enforceable worldwide. There are no comparable solutions, either onchain or in Web2.

• We believe Immunefi’s court will bring a gradual end to the problem of bad faith projects, making bug bounties safe for all future waves of security researchers.

But what does that even mean? And why should you care? To answer this, I’ll reveal a few of the big challenges of running a bug bounty platform, why no one has made a serious effort to protect whitehat interests, and why we think we’ve built a strong solution for safeguarding both projects and security researchers.

But let’s start at the beginning.

In the beginning, there was the bug bounty program. It was a great idea; bug bounty programs let you hunt on all sorts of different projects and technologies whenever you feel like it. You can become a security champion, proactively reviewing code and disclosing groundbreaking vulnerabilities before they can be exploited. The results of web3 bug bounties are undeniable: They reliably surface critical vulnerabilities that other security measures miss and prevent countless billions of dollars in damages. Web3 bounties bring security researchers fame, fortune, and respect.  

But there’s a big problem with bug bounty programs: despite being binding legal agreements between counterparties, they still depend on trust to work. The project hosting the bug bounty program has to trust that security researchers will responsibly report vulnerabilities rather than exploit them, and security researchers have to trust that projects will actually pay out the bounties they’ve promised at an appropriate level, per the terms of their bounty programs.

The counterparties must trust each other to execute the contract as expected, and relying on trust is not easy between two absolute strangers. But it gets worse, because trust is diminished from the start by the following factors:

• The counterparties are typically unknown to each other, differing in just about every way. They are random internet strangers.

• Bug bounty programs are contracts designed to surface and specify rewards for unknown vulnerabilities. Since these desired vulnerabilities are unknown by definition, specifying their validity and appropriate reward tier criteria is challenging.

• Counterparties are incentivized to disagree with one another. Security researchers are financially incentivized to inflate severity to maximize bounty size and reputation, and security professionals running bug bounty programs are incentivized to minimize bounties to safeguard project treasuries and any perceived error on their side.

• Security researchers have to disclose their vulnerability upfront for it to be evaluated for a bounty, and this removes much of the negotiating leverage they might have in determining reward amount and payout.

This is not an ideal start to what should be a positive-sum transaction that makes everyone better off, and if not managed, this dynamic can lead to negative consequences.

For example, in some cases, security researchers who would otherwise find and disclose high-impact vulnerabilities choose not to do so. The second-order consequence is that hacks that could have been prevented instead occur. This is caused by:

• Security researchers refusing to hunt.

• Security researchers finding vulnerabilities, but refusing to disclose due to lack of trust in bug bounties.

• Security researchers (blackhats) finding vulnerabilities and exploiting them due to lack of perceived safety in responsibly disclosing via a bug bounty.

These consequences lead to data breaches in web2, but in the onchain economy, they lead to billions of dollars in losses, and millions of ordinary people are caught in the crossfire. 

Bug bounty platforms like Immunefi are designed to solve these problems. As Immunefi has shown with $110m+ in payouts to security researchers, some platforms do succeed in bringing trust and security to these transactions. 

But it’s not enough; a single missed hack can compromise billions of dollars. Bug bounties need to operate at maximum effectiveness so that the absolute maximum number of vulnerabilities are disclosed and mitigated. 

That requires that trust in bug bounties be maximized, and these problems as mitigated or resolved as is possible. And we’re just not there yet; even though whitehats get paid every single day on Immunefi, I still get such questions from security researchers as to whether Immunefi still has a payment enforcement problem, and whether it's really safe for them to spend time bug hunting. 

These are fair questions. Even though the vast majority of cases end well, a relevant minority of cases leave some security researchers dissatisfied.

So, we need a solution that provides the maximal trust assurances to bug bounty transactions, minimizing the possibility of abuse and thereby making bug bounties as safe as they can practically be. Such a solution would have the following necessary qualities:

1. In case of uncertainty or dispute, it must be possible to objectively evaluate vulnerability disclosures and assess their severity and reward amount according to the bug bounty program.

2. It must be able to deliver legally enforceable rulings; the conclusions should be able to withstand scrutiny in any legitimate court of law and be recognized by existing legal systems globally.

3. It must enable realistically enforceable bounties; the rulings should be practically enforceable according to the means of most security researchers.

You might think that a solution would already exist, given that bug bounty platforms have existed for over a decade. Instead, I’ve only found all the reasons why they haven’t existed.

Since the rise of the bug bounty platform and the relatively small amounts paid (typically five-figure amounts), projects have had all the leverage. Rarely has a bounty been worth going through the immense hassle that a traditional court case and enforcement entails when the typical case lasts years and can easily cost tens of thousands of dollars. If the case is international or against a large corporation, then you could expect the costs to be hundreds of thousands. There have been some notable cases in this area, and when they happen, the process itself virtually kills any win-win outcome because of cost and time.  

Disputes over the occasional web2 six-figure bounty have occurred, but web2 bug bounty platforms have had little incentive to develop a comprehensive trust assurance solution. Development would be expensive, time-consuming, and require expert skills, and its enforcement could harm customer adoption. 

Furthermore, far more hackers were available to work than companies hosting programs. The incentives simply pushed in the direction of protecting whitehat interests, given that it would create such a big headache for traditional web2 bounty platforms.

But what about crypto? Trust assurance is a normal commercial problem, so it seemed safe to assume solutions would be available for use, but this was not so. Here are a few examples of things I found that didn’t work, and why:

1. Traditional court systems: There were many problems with relying on existing courts to secure whitehat interests. First, they are incredibly slow, taking years to resolve cases. Second, they are expensive, and variably so; a case appealed over and over could cost enormous sums. Third, they are necessarily local; you could win a local case but fail to have it enforced against a counterparty in their jurisdiction. Fourth, they have no understanding of crypto, and generally disdain the subject; getting tried by a judge who hates you from the start is a recipe for bad judgments.

2. Zero-knowledge proof of exploit: Zkpoex is a much-loved topic in the onchain security community because it seems like a panacea to this whole problem, through letting security researchers prove impact without disclosing the vulnerability until it has been paid for! Practically, there are many problems with this. First, most projects have no interest in using this technology in this way, due to the obviously extortionate feeling of its use in this context. Second, Zkpoex does not work for all (most?) types of vulnerabilities, where impact can be challenging to demonstrate in a Zkpoex VM environment. Third, Zkpoex does not help you resolve complicated edge case scenarios, which bug bounties routinely involve. Fourth, Zkpoex technology remains experimental and needs further investment before it can be applied to bug bounty platforms at scale. Fifth, Zkpoex-proven impact may not comply with the terms and requirements of the program. Sixth, Zkpoex turns the tables on projects by forcing them to put up capital first, and if in case of an edge case, you still need some kind of dispute resolution solution to evaluate and make legal judgments. In my view, Zkpoex may have a future place in the bug bounty workflow (it’s certainly an interest of mine!) but it does not actually solve the trust problem meaningfully; it just flips the power dynamic in a similarly dysfunctional way.

3. Onchain dispute resolution: Dispute resolution native to crypto has been proposed by a few projects, most notably Aragon, Kleros, and UMA’s optimistic oracle. However, all such courts have failed to deliver reliable dispute resolution. Aragon Court has shut down with the wind-down of the Aragon DAO, Kleros is thoroughly compromised by scandals and has subordinated rulings to its own financial interests (as its token model dictates), and UMA’s optimistic oracle is incapable of making contextual, fine-grained judgments. Furthermore, none of these courts have real and reliable enforceability in most jurisdictions, never mind international enforceability of judgments.

4. A crypto-native security council: This was my original idea, but I would find out later that it doesn’t work well at all. The first major detriment of this approach is the fact that security experts, while very knowledgeable of the underlying vulnerabilities, tend to be poor interpreters of the underlying contract (the bug bounty program) that takes primacy, unless they’ve managed such programs before. Second, rulings by such small groups create a huge opening for legal challenge on grounds of partiality and poor process; I would expect that any dispute resolution system of this type to be challenged by either projects or security researchers in their local court of law and found wanting and liable as a result. When bug bounty payouts can land in the millions, the chance of disputing lawsuits are very high. Third, it’s very difficult to make rulings by such groups legally enforceable in a meaningful way; you can get some powers under local contract law, but they are unlikely to extend beyond local borders, where most disputes actually occur and need enforcement. Fourth, projects generally feel that they cannot trust the impartiality of such adjudicators because the onchain security community is small and everyone knows each other, which is a very legitimate concern. For all these reasons, I concluded (painfully) that this approach would lead to reliably poor outcomes for security researchers.

It became clear that there could be only one solution: We would have to build a hybrid, onchain-offchain dispute resolution system that included international legal enforceability – all in a crypto-native manner that would be readily adoptable by our customers.

Subscribe now

Immunefi Blockchain Arbitration System 

Enter Immunefi arbitration, the world’s first bug bounty arbitration system (and software vulnerability court generally, as far as I know) with legal and practical enforceability worldwide. 

The Blockchain Expedited Arbitration Rules, designed with the brilliant legal experts over at Greenberg Traurig and the London Chamber of Mediation and Arbitration, solves the problem of ensuring global legal enforceability and impartial and objective evaluation of disputed bug reports, all within the means of the typical security researcher.

• We built the entire legal system on the New York Convention to achieve global enforceability. By basing it on the core requirements of the convention, legal rulings created through the Blockchain Expedited Arbitration Rules make judgments enforceable across all the New York Arbitration Convention’s signatories, which amount to 172 countries today. This means that Immunefi arbitration awards have legal force across all countries colored gray in the map below; that’s as global as it gets!

• We chose to base the arbitral system on English law to deliver judgments of the highest standard. The UK, for context, is the world’s leading hub for arbitration expertise and resolutions. There would be no better place to create a court that is the first of its kind.

• To ensure both impartiality of arbitrators as well as the best combination of speed and cost, we partnered with the London Chamber of Mediation and Arbitration (LCAM). In addition to having a great roster of world-class arbitrators, LCAM is the arbitral house eager to move into the onchain age. They’ve also been the core party in determining how to make disputes both as fast as possible and as low cost as possible, resolving cases in weeks to months, not years (which is lightspeed as far as most courts are concerned), and bringing costs safely into the thousands with flat case fees.

• As an added and crypto-native bonus, Greenberg Traurig figured out how to conduct proceedings with maximum privacy, ensuring that identities are only shared on an as-needed basis, allowing for pseudonymous use of Immunefi Arbitration. To the best of my knowledge, our arbitral system is the only one in the world that is safe for anons to use.

This gives us a first-of-its-kind hybrid Arbitration system for bug bounties that enables fast, low-cost dispute resolution from LCAM’s blockchain court.

We are exploring additional features for the Arbitration system that make rulings even more enforceable and meaningful to security researchers, yet stays entirely true to our crypto-native roots where projects control their own funds.

If this Arbitration system works, the bug bounty dispute problem will be solved in a fair and transparent way that preserves the crypto ethos of self-custody of funds. Every security researcher in the world will receive the strongest possible trust assurances that if they hunt with Immunefi, their interests will receive the strongest possible protections in turn.

And adoption is looking good! We’ve found that many newly onboarding projects agree to arbitration. And it makes sense that they would! Arbitration is a far safer solution for them as well. Not only does it play a meaningful role in protecting them against the greatest and most deadly risk of all, getting hacked, but it does so while eliminating the risk of costly cross-border disputes, wasted time and money on lawyers, and allows for a trustworthy and reputable party to resolve the dispute amicably so that they can get back to building. From the perspective of most projects, these benefits far outweigh the costs.

And that’s how it should be; just as security researchers show themselves to be good faith actors by participating in the bug bounty program according to the rules, projects prove themselves to be high-integrity partners by adopting Immunefi arbitration.

If projects continue adopting Immunefi Arbitration, the era of low-trust bug bounty transactions will come to an end, and the entire onchain world will benefit from reduced hacks. Success in adoption will mean billions saved from hacks that could have happened, but were instead prevented because whitehats could count on being rewarded for their good deeds.

Finally, it’s worth noting that Immunefi Arbitration puts onchain bug bounties into a league of their own. Not only do we have the best payouts and mediations in the bug bounty world, but we will also have the best and most effective protections in the entire cybersecurity world. How’s that for raising the bar for the cybersecurity industry worldwide?

I’m beyond excited to launch this product into the world. It is now live and applies to reports submitted to arbitration-enabled bug bounty programs after January 21st 2025.  

To learn more about how to use Immunefi Arbitration as a project or security researcher, read the guide here.

Before you leave, do me a favor and hit the Subscribe button to receive my research going forward. I don’t send anything except my research, typically once every month or two.

Subscribe now

Before we begin, do me a favor and hit the Subscribe button (it’s free!) to receive my future research (typically on a monthly cadence). Thanks for your support!

Subscribe now

High Level Summary:

1. The onchain economy will soon consist of thousands of interconnected but independent blockchains. The major categories will be smart contract platforms (Ethereum, Solana, Avalanche, Layer 2 blockchains), brand-specific blockchains (Flow, Soneium), and use case-specific blockchains (Bitcoin for most of its history, DePin networks, private blockchains like Pineapple).

2. New blockchains will bootstrap with one core use case, which is overwhelmingly likely to be one of the following: store of value and investments, trading and exchange, payments, collectibles. These core use cases have been the historical revenue drivers of the onchain economy, and will continue to be.

3. There are chain-localized competitive advantages that accrue to specific types of dApps, which I call ‘defensible primitives’. They consist of the following: the dominant DEX, the primary crosschain bridge, the leading lender, the leading name service, and the leading stablecoin. More may emerge. Defensible primitives are capable of venture-scale returns today.

4. Investors and founders can outperform the broader market by investing in and building defensible primitives on winning chains. Winning chains can be probabilistically identified by the salience of their competitive advantage vs other chains in the same category. Platform risk remains a real risk.

We are rapidly approaching a future of a thousand blockchains.

United by chain abstraction solutions like the Superchain, Polygon Agglayer, and Everclear, and made cheap to launch by new blockchain frameworks and rollup-as-a-service platforms, these chains will transform the onchain economy and let users and assets travel freely across borders, chains, and applications. Most consumer activity will migrate to rollups and other Layer 2 (L2) and Layer 3 (L3) solutions.

With this shift comes opportunities, and the key challenge for builders and investors lies in identifying which blockchains are poised for success and capitalizing on these emerging ecosystems early.

Looking ahead, we can expect to see different types of chains emerge around different types of value propositions:

1. Smart contract platforms: These are the main types of high-value blockchains today, including heavyweights such as Ethereum, Solana, Avalanche, BNB, and many others. The central value proposition of these chains is overwhelmingly financial. The finance sector is likely to adopt blockchain technology as a ledger system, with major institutions developing their own chains to maintain control and meet regulatory requirements, which will increase the number of such platforms.

2. Brand-specific chains: More intriguingly, we may see major consumer brands launching their own blockchain ecosystems. Flow, developed by Dapper Labs, is an early example of this trend, although it's somewhat limited in its technological scope. The consumer electronics giant Sony announced Soneium, its own Ethereum L2. As brands recognize the potential of blockchain for customer engagement, loyalty programs, and digital asset management, we will see a proliferation of brand and IP-centric chains.

3. Use case-specific or novel coordination chains: Another exciting class of blockchains will be those that coordinate disparate and disagreeable parties in a trustless way, and which require a chain to maximize value capture. Every DePin network can be such a chain, as are some of the more unique private chain implementations, such as Pineapple. The most famous example of this type of chain was Bitcoin itself.

Here's a few and where they could fit; of course there are far too many blockchains now to list, proving the point.

There are already hundreds of independent blockchains, but the major growth is still to come. That growth doesn’t need to be from new use cases; niche economies where a winner would like to control the financial system of record to better monetize their assets will be reason enough to launch a blockchain for many brands.

To bring color to this picture, many dApps will be incentivized to build their own chains: Whether a chain is designed to handle fungible commodities or non-fungible collectibles, whenever use of blockchain creates a potential financial market where onchain assets reach a certain amount of value, the asset creator will be incentivized to create their own blockchain platform to better monetize interaction with their assets. With so many ways to create high-value digital assets, from finance to brand IP to collectibles and more, this makes a world of countless blockchains inevitable.

I call this inevitable world, the world of a thousand and one blockchains, and it is upon us.

The Real Money Generators

Each of these new blockchains will revolve around a primary revenue driver that forms the initial anchor of the ecosystem. Since the birth of Bitcoin, the core use cases that drive onchain value and popularity have remained stable: as a store of value and for investing purposes, trading and exchange, making online payments, and as collectibles.

While the crypto community still asks for "real use cases" and hunts for brand-new concepts, we shouldn’t overlook the profitability of proven use cases. Traditional use cases are delivering compelling financial results, and to be distracted from them is to harm one’s own investment performance. Despite the constant influx of new projects and ideas, these fundamental financial applications still account for the lion's share of cash flows in the onchain economy. They've withstood the waves of change in narratives, regulatory outlooks, and technological advancements, emerging as the bedrock of the onchain economy. They are robust.

That’s where we as founders and investors need to pay most attention, because the future 100x returns are already here. The past indicates that these real money generators are the chief places we should be looking for asymmetric returns.

Returning to the world of 1000 blockchains, we should expect almost every major blockchain to fit this historical cast in some way. The blockchain will launch, and initial use cases will center around several core applications that act as what I call ‘defensible primitives’. These foundational protocols enjoy real moats and network effects within their respective blockchain ecosystems, which I call blockchain-localized advantages. As a particular blockchain economy grows in value, it will incentivize creation of functioning DeFi markets and interchain commerce to service and better monetize its onchain value. There will be the same products, built and rebuilt, across every chain.

This story of blockchain birth and growth also shows us how to best navigate this world of 1000 blockchains, since we need only follow the historical money and invest where the market has already proven the defensible advantages to be.

But before we dive into the defensible primitives in the onchain world, let’s talk about why the onchain economy creates truly incredible businesses in the first place.

Pushing COGS to Users at Limitless Scale

What sets onchain protocols apart from all other internet businesses is the ability to push cost-of-goods-sold to end-users, alongside scalability bounded only by the underlying blockchain platform. For traditional internet companies, the cost of servicing individual users is often negligible, but DeFi platforms charge users for the compute through gas fees instead. Compare this to Google, which, despite having near-zero marginal costs for individual queries, must operate 37 data centers and spend $50 billion on CAPEX in 2024 alone.

The beauty of decentralized onchain projects lies in their ability to generate revenue without relying on traditional web infrastructure. These projects can earn money directly from user interactions without the need for centralized servers or extensive physical infrastructure. This decentralized nature allows for a lean and efficient business model that's unprecedented even for internet companies.

A prime example is Uniswap, a decentralized exchange protocol. Uniswap generates over $640 million in annual recurring fees for its stakeholders. Following a recent rewards proposal, Uniswap could distribute between $62 million and $156 million in annual dividends to UNI token holders. The project itself owns almost 40% of all tokens ($2.46 billion held in reserve) out of the fully diluted valuation of $6.198 billion. In a mere six years, Uniswap created enormous value for its owners. Because of its moat, the monthly trading volume on L2s has also tripled since last year.

Onchain projects like Uniswap represent the pinnacle of internet business efficiency. They've managed to create a model that generates substantial cash flow with virtually zero marginal spending. This sets them apart from traditional businesses of all kinds. This staggering figure underscores that Uniswap has essentially become a pure cash machine within the onchain economy. And there are others.

Defensible Primitives

A defensible primitive like Uniswap exists in a winner-take-all market, with power law distribution of market share and user adoption due to network effects. Those network effects are largely bound to the blockchain where they have dominance. I call such network effects blockchain-localized advantages.

To put this dominance into perspective, Uniswap's market share is nearly three times larger than that of its closest DEX competitor on Ethereum, Curve. Being a defensible primitive makes it increasingly difficult for newcomers to challenge the established leader on local blockchain.

When users need to swap one token for another, they gravitate towards the DEX with the most liquidity and trading pairs: the platform with the most capital in its liquidity pools can offer the best exchange rates and minimize slippage, creating the best end-user experience. As more users make this same choice, they further entrench Uniswap's position, creating a virtuous cycle of growth and dominance that has brought Uniswap to its leadership position on the Ethereum blockchain, and act as a self-reinforcing cycle of success.

But these advantages end at the border of their home chain, and Uniswap’s advantages have not gone far beyond Ethereum; they have been outcompeted on Ethereum L2 blockchains like Optimism and Base by much smaller competitors (Velodrome and Aerodrome, respectively) and this seems to be the pattern, not the exception. Their advantages are blockchain-localized, though they may have such advantages on multiple chains if they are able to dominate the competition fast enough.

These are the big categories of defensible primitives that I know of today; you can argue that block explorers and MEV tooling could also deserve a place here, and I'm sure there are others yet undiscovered.

There are many types of dApps that seem to share Uniswap’s blockchain-localized defensibility. The key categories typically include:

1. A dominant DEX: The aforementioned Uniswap is a good example of a winner-take-all DEX dominating an ecosystem.

2. A primary bridge for cross-chain transactions: Circle CCTP, a bridge allowing USDC to flow between chains, processes over $30 million every 24 hours, and it dominates bridge volumes where USDC dominates.

3. A leading lending provider: Aave operates over $11Bn in total volume locked, and it is harder to find a safer lending platform on Ethereum.

4. A widely adopted domain name service: over 2,000,000 domains were created with ENS, Ethereum Naming Service, which has become an embedded standard.

5. A leading stablecoin: Whichever stablecoin is dominant on a particular blockchain is likely to remain so for the future, barring surprises. On Ethereum, that’s MakerDAO. On Tron, that USDT. On Base, that’s USDC.

It's important to note that each blockchain ecosystem has limited space for these defensible primitives; each are winner-take-all competitions. Notably, a brand can win these blockchain-localized advantages across multiple chains (as bridges and naming standards often do) if they can get to a big enough scale and their network effects take hold on that chain. Winning these blockchain-localized advantages for the long term is all about building those network effects fast enough.

Given the limited number of these positions and the power of narrative within market cycles, the historical strategy has been to differentiate from direct competitors by inventing new categories or rebranding existing ones. For instance, some projects rebrand bridges as "transport layers" to avoid direct comparisons. But at their core, these services focus primarily on moving assets between different chains, and participate just as much in these winner-take-all competitions.

Thriving in the World of a Thousand Blockchains

If you’re a founder or investor and want to take advantage of these natural, blockchain-localized advantages, you can do so by creating or investing in the leading defensible primitives on a chain-by-chain basis. While many of these positions have already been filled, there will be countless vacancies in the onchain world to come; multiple for every blockchain, in fact.

The challenge will not be selecting the leading defensible primitives (since their leadership position should be fairly obvious) but selecting which blockchain itself to bet on!

Of course, this strategy won’t always work (the Uniswaps, ENSs, and Circle’s of the world will successfully muscle into some of the new chains), but the odds of making a compelling return will be much, much higher than they would be for the median blockchain startup. Moreover, they will tend to scale and grow alongside their underlying blockchain: the venture-scale outcomes available to L1 blockchains gives defensible primitives a similar venture-scale return profile, critical to founders and investors alike.

One question remains: How does one choose a winning blockchain to invest or build on? To answer this, we need only return to our initial categories and ask: what kind of blockchain is this, and do we have reason to believe it will stand out in a crowded market?

• Smart contract platforms are generally assessed on the weight of their technical innovations and GTM teams.

• Brand-specific blockchains can be assessed on the market strength of their sponsoring brand, and the appropriateness of their core use case for their IP.

• Use case-specific and novel coordination blockchains (like most DePin networks) can be assessed on the strength of their founders, existing access to market, and TAMs.

Comparing the salient advantages of blockchains against their competitors has proven a reliable enough heuristic for picking winners in the past, and I expect it will continue to. Big funding rounds for the protocol can be a good signal, but not a definitive one. Winning patterns are unlikely to change, but more intense competition between more blockchains fighting for market attention means that the bar for salience is constantly rising.

As of October 2024, L2Beat now shows 96 operational L2s with an additional 87 L2s and L3s in development, and Coingecko lists hundreds more operational L1 blockchains.

Here's the best map of the industry that I know, and we're still just getting started. The world of a 1000 blockchains is almost here.

Some people call this “oversupply” due to excessive investor interest. I look upon this as the natural beginning of the world of 1000 blockchains, and a decade’s worth of founder and investor opportunities.

If you like my blog, please subscribe & share it with your friends. I write in my free time, so seeing more people read these posts motivates me to write more. I don’t send anything except my research, typically monthly.

Subscribe now

To date, no one really knows. But could discover a predictive estimate by analyzing historical hacks. In this post we’ll go through the historical data of the last several years to build a representative estimate for the typical future hack across impact categories (it’s not just money stolen). From there, we’ll create a heuristic for estimating what the typical hack would cost your favorite protocol, which I’ll call Amador’s hack impact estimate.

Before we begin, do me a favor and hit the Subscribe button (it’s free!) to receive my future research (typically on a monthly cadence). Thanks for your support!

Subscribe now

Summary:

• To date, no one had a great estimate on the expected cost of an onchain hack, and that’s unfortunate. But we can make one by statistically analyzing hacks over the last few years! I analyzed hacks from 2021 to 2023 to come to a representative estimate of the real cost of an onchain hack. Let’s call it Amador’s hack impact estimate.

• Amador’s hack impact estimate: if your protocol gets hacked, you should expect to lose approximately $16,000,000 USD, see your token price decline by 52% of market cap, expect depressed token prices to persist for at least 6 months (and likely much longer), and lose 3 months of time and effort recovering. 

• If your product is a platform (either as a L1/L2 blockchain or a financial primitives protocol), expect your protocol and its dependents to be wiped out as suggested by antecedent cases like Terra-Luna.

• We aggregated these findings together at https://stats.immunefi.com/. Go check it out! We’ll be adding more statistics and datapoints there as they become available.

But let’s back up: the first shocking thing is that we don’t have good hack impact estimates today, despite crypto suffering hundreds of hacks in the last three years alone. For that, we must blame the difficulty of measuring the true impact of a hack.

The reality is that net value stolen, which is the standard widely used figure, grossly underestimates the damage caused. It misses all the other ways hacks wreak damage, many of which are more financially damaging than the hack itself, though they are more difficult to quantify. The contributors to total hack damage that are most unrecognized by non-security practitioners are:

• Market impact: Market impact is the damage to the publicly trading token (or hypothetically equity) prices caused by the hack, which can last over long periods of time. This impact is much less known than the value immediately hacked, and its importance remains under-appreciated by most security practitioners. 

• Dependency impacts: Dependency impact refers to second-order effects stemming from the original hack that cause damage to other assets. There are three major categories of dependency impact: Platform dependency, financial dependency, and reputational impact. The hack of a blockchain itself in such a way that it compromises all assets/contracts built on that blockchain is an example of platform dependency impact. The decline in Luna pricing destroying the value of the Terra stablecoin is a good example of financial dependency impact (though it is not a hack in the way most DeFi hacks are). Perceived lack of security of a platform (such as with BNB Chain) that diminishes user growth and adoption of that platform is an example of reputational impact.

• Talent & organizational impact: Damage here is challenging to quantify, typically taking the form of lost time, money, and talent due to post-hack response and recovery. Given that a hack and its recovery can consume months of work for a small startup team, the organizational impact alone is always costly and sometimes fatal. All but the most preemptively prepared organizations must deal with this impact post-hack.

In other words, the typical hack is much more damaging than mere funds stolen would suggest! 

The remainder of this article describes estimates for assessing each type of impact in the case of a typical hack by looking at historical medians or, where data is unavailable, by making an estimate informed by my firsthand experience.

Impact from funds stolen

The data tell us there were 107 hacks in 2021, 134 hacks in 2022, and 247 hacks in 2023, for a total of 488 publicly known hacks from 2021-2023. 

These hacks impacted $2,334,863,067 USD in 2021, $3,773,906,837 USD in 2022, and $1,699,632,321 USD in 2023, for a total of $7,808,402,225 in funds impacted from 2021-2023. 

For clarity, funds impacted means funds hacked, stolen, or otherwise lost, but it doesn’t include funds returned or reclaimed by whitehats and investigators.

Using these numbers, some simple math on this 2021 to 2023 dataset gives us the following insights:

• The average hack resulted in the theft of $16,000,824 USD

• The median hack resulted in the theft of $1,000,000 USD

• There is a power law distribution to hacks; many hacks are small, but when the big ones happen, they are a hundred times larger than the median hack.

Market impact

Estimating market impact has been a historical challenge. Immunefi made the very first such report, found here, reviewing hacks and their impact in 2022 on a sample of 63 hacks from 2022. This sample showed an average drop in underlying token price of 13% 2 days after a hack and an average drop of 19.5% 5 days after a hack.

To flesh out our review, we decided to update this dataset with as many of the 2021, 2022, and 2023 hacks as we could collect evidence for. We'll refer to median price movements moving forward. With the extended dataset, the median is a more predictable estimate considering rare outliers that could grow or drop much more severely.

The new dataset covers a total of 176 hacks. The results are pretty shocking:

The data shows median price declines and prolonged price depression post-hack of:

• -10% two days after the hack, 

• -19% five days after the hack, and 

• -27% one month after the hack

• -43% three months after the hack

• -53% six months after the hack

Looking past the median toward the most severe cases, the results are even more staggering. Three months after the hack, 32% of hacks had token declines in excess of 50%, and 11% had declines over 90%. Six months after the hack, 35% of hacked projects continued to experience sustained price declines of over 50%, and 16% had declines over 90%.

This showcases the power law distribution of hack impact and that a single, severe hack can be fatal. Moreover, it shows that hack impact intensifies over time, inflicting ongoing market impact for at least six months post-hack.

It is likely that the market impact continues to intensify to the 1-year mark, but as our dataset covers only three years worth of hacks, we will have to wait until 2024 numbers are fully tabulated before validating that hypothesis.

A caveat: we can’t be 100% sure that this impact is caused by hack impact. Any number of factors can put downward pressure on token prices, including ones that we might not be aware of in this study. The most obvious confounding factor is token price correlation with macro market conditions. But the numbers are so severe and striking as to suggest that they are primarily hack-derived, and so that’s the position we’re taking.

Reviewing all the data together, we’d expect the typical hack to cause a median market impact to their token price of approximately -19% over the first five days and intensifying to -53% over the following six months (probably lasting indefinitely into the future), with a 16% chance of that damage being in excess of 90% of the project’s market cap. 

Clearly, market impact can be pretty scary!

Once you appreciate that most token projects use their liquid tokens as treasury and growth fuel, you understand why security practitioners take market impact so seriously. Even if the hack doesn’t get you, too much market impact can prove just as fatal.

Dependency (or second-order) impacts

There is a major type of unappreciated hack impact, which we call dependency impact or occasionally second-order impact. It describes the cascade of damage triggered by the initial hack. A few examples of this type of impact:

• Platform-dependent impact is the damage caused by the underlying platform going down (in a blockchain DoS attack, for example, that comprises money market or perpetuals markets living on top of affected platforms), which can wreak havoc on all applications operating on that platform. Despite its commonality (there are countless platforms in crypto), the limited links between the onchain and offchain economy have limited incidence of this type of impact to date, and the blockchains have proven themselves to be remarkably resilient pieces of technology. As the onchain and offchain economies link up, we should expect such impacts to become more common and severe.

• Financial dependency impact concerns hacks that cause second-order impacts to dependent assets. Assets with financial dependency risk include stablecoins (like MakerDAO, CDP liquidations), liquid staking tokens (like LIDO, Rocketpool, etc), derivatives protocols (like Pendle), and almost any token paired on liquidity pools. Financial dependency impact is one of the harder categories to assess, as it can go easily unnoticed; almost any hack involving theft of tokens will create dependency on other tokens that are directly or indirectly related.

The quintessential example of dependency impact is the collapse of Terra-Luna. The financial attack on the stablecoin protocol’s equity token depegged the stablecoin and drove a downward spiral, from which it never recovered. The collapse of Terra-Luna destroyed not just the $40 billion USD in Luna equity, but also the $1 billion in outstanding UST Terra stablecoin, and all the value in Terra-Luna dependent DeFi, like the $1.5 billion USD equity value of the Anchor Protocol, alongside countless other Terra-based protocols. The harm to the Terra ecosystem was near total; the Terra ecosystem is 99% down today, basically defunct.

Some colleagues and I are actively engaged in research here to understand the true incidence of dependency impacts. Seeing that this research is in progress, we won’t draw premature conclusions by including the typical dependency impact in our rule on hack impact. When the research is done, we’ll share our findings here and update this post. Tentatively, dependency impacts appear to be much more severe than is commonly understood. 

Talent and organizational impact

Talent and organizational impact typically take two forms: Loss of talent and operational or procedural changes.

Talent impact concerns personnel loss post-hack, either due to perceived fault or incompetence, a perceived need for fresh security talent, or demoralization as a result of the hack. Either way, it’s not uncommon for hacked projects to lose their former security leaders. 

Compounding the problem, a hack makes it more challenging to hire new security leaders, as it signals organizational weakness. 

The second form is unplanned operational or procedural investments (almost always security-oriented) made as a result of the hack. While these are positive, they slow down progress on the core product by distracting valuable attention from growth to security.

Quantifying impact here is challenging, but I do have some first-hand experience war rooming with a number of projects and will make estimates based on those experiences.

In my experience, the pre-hack security leadership is typically lost as a result of the hack. This could be a CISO, a security engineer, or even an engineering leader who was placeholding the security role. Their departure can be mutually agreed, as experiencing a hack on one’s own watch is a very demoralizing event, or it can be for cause. They also tend to be let go prematurely, in my view, because it will take an organization 1.5 to 4 months to hire an effective security replacement. This becomes lost time for the hacked project.

A hack also tends to freeze the team in a state of shock that far outlasts the hack itself. Organizations will devote themselves to at least two weeks of damage survey and control and two to three months of remedial security work (which suddenly becomes the most important thing on everyone’s to-do list), which will result in deprioritization of the core product roadmap.

The above example numbers are the more positive outcomes. Talent impact can be much more severe as it impacts the financial runway of a project, as exemplified by Kyberswap: In November 2023, KyberSwap suffered a $49M exploit. Understandably, they wanted to reimburse their users, but to do so, the team had to cut 50% of its workforce to keep the firm’s business operations up and paused its liquidity protocol initiatives and KyberAI project. The 10% bounty Kyber offered to the blackhat ultimately did not help. 

It’s impossible to compute these impact factors into a simple impact calculation, so we’ll have to settle for summarizing the unique impacts and leave them as is: If you get hacked, expect to burn 3 months on remedial security work, lose 3 months of progress on your core product roadmap and objectives, lose your present security leader, and get a replacement for them 3 months later. It’s as if 3 months of effort are lost into the ether. This is some intense damage for any startup, although it is not typically fatal.

So, what’s the cost of a hack?

Pulling it all together, we now have the data to build out our estimate. Let’s sum it up in order of the quantified damage and severity:

1. The average hack impacts $16,000,000 USD million at the moment of exploit.

2. The median hack causes a dramatic 52% price decline in the underlying token market capitalization over 6 months. 79% of hacked projects continue to experience price depression 6 months later, with the ultimate duration of this hack-induced market impact being unknown and possibly indefinite.

3. The median hack does not create dependency impacts of either a financial or platform nature, but when such impacts do occur, they tend to be absolutely catastrophic, risking total destruction of assets dependent on the underlying platform. In critical bug reports with dependency impact of either kind, the typical potential impact is up to the sum total of extractable value on that platform!

4. While harder to estimate, the median hack should cause around 3 months of lost time and effort across remedial security work, lost roadmap time, team churn and replacement, the loss of whoever is the present security leader, and a great deal of anxiety in attempting to ensure you never get hacked again.

We now have everything we need to create a simple rule for assessing the real cost of an onchain hack. If your protocol gets hacked:

1. Expect value stolen of approximately $16,000,824 USD

2. Expect price suppression of 52% of your token’s market cap, and for that price suppression to last at least 6 months, and expect to never recover from this price suppression (77.8% of hacked tokens appear show sustained price suppression 6 months later)

3. Expect to lose 3 months of time and effort recovering and rebuilding post-hack

A corresponding real-life example of the above estimate is the Indexed Finance hack, in which $16 million USD was stolen on October 14, 2021. The token market cap was $11m at the time of the hack, and was $3.8m 6 months later, showing sustained price depression post-hack. The team never fully recovered from the incident, and Indexed Finance was basically dead by mid-2022. So, our estimate of probable hack impact appears to predict hack impacts effectively.

If your product is a platform (either as a L1/L2 blockchain or a financial primitives protocol) and you get hacked, the typical hack severity profile is one of absolute fatality: your protocol and its dependents are at risk of being entirely wiped out.

Scary stuff.

Concluding thoughts

Getting hacked is the beginning of the damage, not the end. The millions lost to the hack immediately anticipate even larger losses, caused by market impact and dependency impact, alongside many months of lost time spent rebuilding your emotionally shattered team and operations. Not fun.

There is no solution to these problems except investing in onchain security and progressively hardening our entire industry. 

Of those measures, bug bounties are the most quantifiably proven to prevent hacks and hack impact at massive scale. I’ve done a quick review on the impact of bug bounties in demonstrably preventing tens of billions in hacks, and you can read more about that here in my Retrospective on Immunefi.

But looking beyond that, we need more and better code review from more 100x hackers, more and better security standards, and more and better automated security technologies. Only hardening across the stack will prevent hacks. 

That’s what we’re building at Immunefi: effective security across every layer of the onchain security stack until hacks become a thing of the past.

If you like my blog, please subscribe & share it with your friends. I write in my free time, so seeing more people read these posts motivates me to write more. I don’t send anything except my research, typically monthly.

Safe Harbor: The Making of a New Security Standard

Summary: 

• Immunefi has just launched Immunefi Safe Harbor, the first product implementation of SEAL’s Safe Harbor standard. Immunefi Safe Harbor is available today onwards (July 3rd, 2024) as an opt-in feature for all future Immunefi bug bounty programs. Immunefi Safe Harbor makes it effortless to launch and manage a Safe Harbor as part of your bug bounty program on Immunefi. 

• Immunefi itself is the very first project to adopt Immunefi Safe Harbor, which will be used to further protect Immunefi’s Vaults infrastructure. We use our product to strengthen our own security.

• Safe Harbor deputizes the global security community to rescue funds at active risk from hacks-in-progress, using whatever means available to them. Safe Harbor provides a legal framework that protects whitehats from legal harm if they successfully rescue and return funds under active threat, and allows for bounties to incentivize whitehats to brave what risks remain.

• In this post, I describe the history of hacks that could have been mitigated by Safe Harbor and how these historical hacks shaped its evolution, the history of how Safe Harbor was developed by SEAL and the whitehat security community, and I predict the conditions determining whether Safe Harbor succeeds in protecting the global onchain economy. 

• You can go here to get started with your Immunefi Safe Harbor. Post-signature, setup takes just a few minutes and inherits the setup of your bug bounty program for effortless management and maintenance.

Today, we patch a long-standing gap in the onchain security stack: the nightmare-tier challenge of mitigating an onchain hack-in-progress. We’re doing this by launching Immunefi Safe Harbor, the first product implementation of the Whitehat Safe Harbor Agreement developed by the Security Alliance (SEAL), which will make it nearly effortless to launch and manage a Safe Harbor program according to the highest standards available.

To illustrate the problem: how do you prevent a hack when it is already in progress? Think of the original DAO hack, or the Nomad bridge hack, where money was gradually stolen over many blocks. This is where Safe Harbor provides a solution. 

Safe Harbor is a legal agreement that deputizes the whitehat security community to rescue funds when under proven threat, providing financial incentives and legal protections in exchange for being a final line of defense against hacks. The deputized security community is pre-emptively given consent to rescue these funds, and rescued funds are immediately repatriated to a pre-designated address controlled by the affected project. This gives every adopting project a final protective defense after all other measures have failed, providing they can attract and engage the security community ahead of time.

Safe Harbor rallies all the world’s MEV searchers to watch for and intercept hacks, repurposing their incredible capabilities to serve the good of the onchain economy by returning stolen funds. Picture all the worlds’ hundreds of onchain security firms being incentivized to deploy their onchain monitoring tools toward blocking hacks mid-motion. Envision a world where every time a widely forked codebase is compromised, the entire security community can instantaneously rally to protect users wherever they are. Safe Harbor has the power to 10x the global whitehat community overnight, if only it would be widely adopted.

To make this vision a reality, Immunefi has just launched the first product implementation of Safe Harbor (called Immunefi Safe Harbor) that makes it maximally easy to:

1. Set up Safe Harbor as an extension of your bug bounty program, using the same disclosure dashboard, Immunefi vaults, and emergency alerting system that projects use today.

2. Engage the onchain security community at scale by driving continuous security attention to your Safe Harbor program while quality controlling these interactions for more eyes on code and less risk.

3. Immunefi takes care of and maintains your Safe Harbor, providing safeguards to minimize any negative security events whenever it should be used.

Our hope is that Immunefi Safe Harbor will become a default part of the onchain security stack, providing a real solution to a hellish problem that the whole industry suffers from today.

The rest of this post describes how Safe Harbor came to be, with a short history of the hacks that prompted its creation and overview of its creation. Finally, I’ll close with some predictions on the factors that will either make or break the success of the adoption of Safe Harbor as a whole.

How hacks shaped Safe Harbor

So, how do you mitigate the damage from a hack-in-progress? The attacker has breached your defenses already, so what options do you have? This is the nightmare scenario that every security leader has to walk themselves through, and hope for the best.

Many security leaders presume that no immediate response is possible, and that their best bet is to pick up the pieces after the fact. But it turns out that there is an alternative: you can rope in the broader security community. The attacker may have circumvented your protections, but that doesn’t mean they’ve outmaneuvered the security community at large. The global onchain security community is always awake, highly capable, and under the right circumstances, very willing to help.

The Nomad Bridge Hack nicely illustrates the ability of the security community to intercept (for the better) a hack-in-progress. To quote the Immunefi analysis: “The Nomad bridge was hacked on August 1st, 2022, and $186m in funds were drained. After one attacker first managed to exploit the vulnerability and struck gold, other dark forest travelers jumped to replay the exploit in what eventually became a colossal, “crowdsourced” hack… Unfortunately, the simple and replayable nature of the transaction led others to collect some of the illicit profit.”

But it was not just blackhats that took notice; the global security community also observed, and when Nomad put out an open call to the whitehat security community to rescue funds in the same way, they sprang to action, ultimately saving over $37m in their own right. Had only they been pre-emptively empowered to intervene, far more could have been saved. 

There have been many similar cases. Clearly, the security community has proven more than capable of being a final, emergency-use-only line of defense when all else fails. And there could be no greater protective force than the 100x hackers around the world and the immense arsenal of security techniques and technologies at their disposal.

But engaging the whitehat security community isn’t a trivial task, because legally these whitehacks are seen as a form of vigilantism. Even in cases where all funds are returned, the whitehats could theoretically be charged criminally or sued privately for engaging in an ostensible and de jure theft of property. Without some type of unequivocal consent and a pre-designated address to return rescued funds, every whitehat rescue risks criminal charges. That’s quite the reward for doing a good deed!

These legal risks meaningfully limit whitehat participation in onchain defense and make the whole ecosystem more insecure. Historical rescues have proven this out. Consider the Primitive Finance Rescue.

During the Primitive Finance Rescue, a small group of whitehats (including yours truly) worked together over 48 strenuous hours to save millions trapped in vulnerable and un-upgradeable contracts. But when the time came for us to execute the rescue, we experienced war roomers could not proceed. Despite the considerable technical prowess of the war room participants (including such auditing greats as the Dedaub security team), the legal risks were too much to bear. 

We had to push technical execution of the rescue to the talented but warroom-inexperienced Founder of Primitive Finance, Alex Angel. Thankfully, he executed the rescue successfully (with the collective support and guidance of the war room), but we lost valuable hours that a blackhat could have exploited to steal the funds at risk, and there was always the risk of the rescue being incorrectly executed leading to loss of funds. Without the extensive support provided by the war room, the legal risk could have caused a more tragic outcome.

So it becomes clear that inviting the security community to help protect funds at risk (as Nomad did) is not enough; the security community also needs meaningful legal protections to justify the risk of engaging in whitehacking.

But these legal protections are also insufficient; you also need compelling financial incentives that justify the risks and the efforts needed to attempt rescues. Without meaningful financial incentives, you find yourself quite literally dependent on the charity of the security community, and charity makes for a poor survival strategy.

And nowhere have financial incentives for security work proven more effective than they have for bug bounties, where Immunefi itself has used exactly this tool to prevent over $25 billion USD in damages, conservatively calculated. Immunefi regularly demonstrates that ROI on bounty spend is almost always over 100x when compared against the most conservative estimates of hack impact that would have occurred had the reported vulnerabilities been exploited. There is every reason to expect that bounties will prove just as effective for Safe Harbor as they did for Immunefi bug bounties.

We now have almost all the components required for creating an effective final line of defense against hacks: We have the deputization of the security community, the pre-emptive consents that give the security legal protection for doing good deeds, and bounties that have proven effective in rallying security experts in the past. But there’s still one thing missing: guardrails for safe use.

Safe Harbor is a powerful tool, but to consent and encourage whitehacks opens a pandora’s box of hacking activity, one magnified by the system interdependency of DeFi protocols. This risk is most visible when looking at cases where financial contagion could result. Consider MakerDAO or similar protocols that depend on collateral reserves. If that collateral is whitehacked carelessly, it becomes indistinguishable from a malicious hack. Countless protocols and assets depending on MakerDAO would be thrust into chaos, and the damage caused by the subsequent market impact is likely to be worse than if nothing had been done at all.

A poorly executed whitehack risks being a cure worse than the disease.

Such cases are not hypothetical; the collapse of Terra-Luna showed how quickly a financial ecosystem can unravel when the underlying asset is destabilized, to the tune of $40 billion dollars in market impact. It wasn’t just Terra-Luna that went down, but every financial application dependent on Terra-Luna, such as Anchor.

Overzealous whitehacks are real risks, not hypothetical ones. On April 9, 2023, a failed whitehack on Sushiswap nearly lead to loss of $3.3m USD that could have been easily rescued by the Sushiswap team had only they been given the time to do so. This event could have had a tragic ending for the aspiring whitehat, had it not been for the just-in-time interception of those funds by a charitable MEV bot operator who graciously returned the money to the affected project, in conjunction with Sushiswap’s merciful decision at the request of Immunefi. 

It becomes clear that explicit guardrails for Safe Harbor use are a must to mitigate these risks. Only when Safe Harbor is applied in a highly targeted way, for real hacks in progress, can these risks be mitigated. 

These guardrails take the following forms and are baked into Safe Harbor:

• A hack must be already in progress for the consent to whitehack to apply.

• Any assets (typically as onchain addresses or contracts) not explicitly labeled as in scope are out of scope for the consent to whitehack.

• The whitehat must immediately return all funds (without exception) to a pre-specified onchain address, or be considered as having stolen them. 

• The whitehat must complete any required due diligence procedures before qualifying for a Safe Harbor bounty.

However, there could still be uncomfortable gray zones where it is not clear how to handle a unique vulnerability. To eliminate this risk, we mandate that Immunefi Safe Harbor be tied to a bug bounty program, and when in doubt, all whitehats should default to disclosing the vulnerability directly to the bug bounty program rather than taking direct action themselves. We enforce this default-to-disclosure using financial incentives.

Safe Harbor bounties are contingent on satisfying the necessary conditions of a hack-in-progress. If loss of funds was not imminent or a hack was not in progress, then the bounty is forfeit. Additionally, we cap Safe Harbor bounty rewards at 60% of the maximum critical reward of the bug bounty. This ensures that Safe Harbor bounties are very healthy, while ensuring that a properly disclosed bug report is worth considerably more. This second condition should ensure that Safe Harbor is only used when truly necessary.

By combining these components, it became possible to create the Safe Harbor standard that is now ready to protect the onchain economy.

The stop-and-go emergence of a new security standard

Making Safe Harbor has been a multi-year journey, executed by the efforts of a small group of onchain security’s leading experts. The actual story begins well before pen was set to paper, in the heady days of DeFi Summer.

I cannot speak to when others first realized the need for Safe Harbor, but I first realized the need for it in 2021 after Immunefi’s wild first year of growth. By the end of this period, I had been part of a number of whitehacks (such as the Primitive Finance case described earlier), and the need for some kind of legal consent and waiver was clear. I participated in several rescues where, for liability dangers, we were unable to execute the rescue ourselves.

Immunefi leadership pondered whether we should create that standard, but we concluded that the time was not yet appropriate for us to do so. The chief reason was that we had not yet achieved our goal of driving broad bug bounty adoption (with less than 70 live programs at the time compared to 340 we have now). We were simply not ready to take on the burden of driving yet another security standard. But we did affirm that if, over the next few years, no one was willing to take up the challenge, we would eventually make it ourselves. 

Fortunately, someone else chose to take up the challenge, and they did so much earlier than we were prepared to act. On August 12, 2022, Jump Crypto entered the fray with their own thesis on the same subject, ‘Whitehats and Dropboxes’, followed up by their just as delightful ‘SAFU: Creating a Standard for Whitehats’ on October 24, 2022. The first article laid out a thesis for what they called first a ‘dropbox’, a pre-designated contract address with payment logic designed to receive rescued funds and payout a predetermined reward to the (presumably whitehat) rescuers. The second article described how the dropbox should work as part of a larger ‘SAFU: Simple Arrangement for Funding Upload’ agreement, designating which assets would be in scope for the SAFU, the rescue and payment conditions, and a formal legal statement from the project committing pre-emptively not to bring legal action against the whitehats. 

In short, Jump Crypto came to the same conclusions we did: solving this problem necessitates creation of a new type of bug bounty program. But Jump Crypto was just as busy as we were, and while they were happy to get the idea out there, they were not willing to go it alone and build it. We were making progress, but still had no line of sight to a functioning Safe Harbor.

But thanks to the very tragic Nomad bridge hack, one leader felt compelled to take on the challenge. In this hack, over $190m was stolen over a period of hours. While a few whitehats got involved to rescue what they could, most were unwilling to help due to the risk of their being punished, charged, or sued for trying to help. 

Samczsun and a small working group of whitehat colleagues decided that the security community would solve this problem themselves once and for all, and create the security standard they would have needed to intervene in the Nomad bridge hack. The working group that would create the Safe Harbor standard included Samczsun and Hudson Jameson from SEAL, Delphi Lab’s Gabriel Shapiro and his colleague 0xcharmed, whose technical mind guided much of the legal work alongside Piper Alderman and the Debevoise white shoe law firm, Miles Jennings and Rodrigo Seira from a16z and Paradigm respectively, the then-security overseer of MakerDAO Kurt Barry representing major DeFi protocols, Lucas Baker and Nihar Shah over at Jump Crypto, and and yours truly Mitchell Amador serving as resident bug bounty program and adoption expert. 

This working group would eventually evolved into the Security Alliance (SEAL), which formally coordinated and funded the creation of the full Safe Harbor Agreement as its flagship deliverable.

Adopting Safe Harbor and Preemptive Predictions

Now that we’ve covered the history of the making of Safe Harbor, the next step is to use it to make history! We need to get Safe Harbor adopted far and wide so it becomes a default best practice of the onchain security stack.

And that won’t be easy! We will have to show every adoptee project that Safe Harbor can drive real security impact and that they themselves should adopt it. Until Safe Harbor is battle-tested in the jungle of the onchain economy, that will be a challenge.

For our part, Immunefi will commit to offering Safe Harbor as part of new bug bounty programs launching on Immunefi going forward. Projects need only to decide to opt-in. This is Immmunefi’s way of giving Safe Harbor its very best chance to change the world for the better.

Looking forward, I’d like to share some predictions for the future that should double as north stars for us to pursue.

First, if Safe Harbor succeeds in becoming a best practice in the onchain security stack, it will be because the first 1-3 whitehack rescues enabled by Safe Harbor were clear successes. These rescues will form the foundation for promoting Safe Harbor industry-wide. And with Immunefi pushing adoption, these case studies proving the efficacy of Safe Harbor will be all that is required to realize adoption.

But that’s not the only way things could go, and so comes my second prediction: If Safe Harbor should fail to proliferate over the next three years as an industry standard, the primary cause will be a failure to show that early Safe Harbor rescues were both clearly net-positive and that its application was consistently safe for projects. If the outcomes are lukewarm, or if the security community attempts to use Safe Harbor outside a very narrow scope that guarantees a positive outcome, then Safe Harbor risks being seen as insufficiently impactful as a security tool, and this will kill adoption before it has really begun. To counteract this risk, Immunefi Safe Harbor is designed to absolutely minimize the risks of a bad-outcome whitehack rescue.

A final prediction: The reality is that the whole world is coming onchain, and the burgeoning economy they bring with them will require more security resources to prevent more hacks. Every single gap in the security stack needs to be patched, and today, Safe Harbor is the only effective means of arresting such hacks in progress. There are thousands (tens of thousands, if we’re unlucky) of potential hacks in the next few decades that can be stopped here and now through Safe Harbor adoption. It’s for precisely that reason that Safe Harbor adoption will be seen as inevitable in hindsight, because how else could we protect the entirety of the onchain economy? There was simply no other way than to rally the security community to act as an always-watching hack defense force.

So I hope you’ll join me in welcoming Immunefi Safe Harbor to the world, and that you’ll do your part in driving Safe Harbor adoption for the future onchain economy.

If you like my blog, please subscribe & share it with your friends. I write in my free time, so seeing more people read these posts motivates me to write more. I don’t send anything except my research, typically monthly.

Share mitchellamador.com

I run Immunefi, the main clearinghouse for onchain exploits. Every day, thousands of hackers hunt on Immunefi, safeguarding key onchain infrastructure by turning unexpected vulnerabilities into exploits in supposedly secure code. Having seen the vulnerabilities and run the statistics, I can confirm what we’ve all felt: Blockchain security impact (as measured by protecting projects from harm and users from theft, in hard $dollars) comes from a select few hackers, the hackers so impossibly good that they are more impactful than a hundred other security researchers put together.

I call these security researchers ‘100x hackers’ because these hackers have, quite literally, 100x the positive security impact of the typical security researcher, sometimes even 100x the impact of other elite-level hackers. 

100x hackers find more vulnerabilities, and they do so faster than their peers. They find vulnerabilities no one else could have–the kind lurking in open code for years on end. The best part is that with bug bounties, we can measure the direct and tangible impact of 100x hackers and compare them to one another. There are people on Immunefi’s Whitehat Leaderboard who have discovered multiple critical vulnerabilities, saved hundreds of millions of dollars (even billions), and earned life-changing millions. 

This discussion isn’t meant to knock on the typical security researcher who makes an invaluable contribution to the onchain economy in his own right. The typical security researcher stands far above most blockchain developers in their ability to find vulnerabilities and secure code; professional security researchers regularly show outsized ability to prevent catastrophic harm in the code they protect, making them very valuable team members. They do the lion's share of code review and red-teaming (inclusive of auditing) that keeps the onchain economy safe. Without them, hacks would be far more frequent.

To give you a quantitative baseline, the typical security researcher on Immunefi makes a real contribution to ecosystem security, submitting an average of 11.69 vulnerability reports per year across the severity range, and this while working on an overwhelmingly part-time basis. Moreover, these typical security researchers make up the vast majority of crypto’s auditor workforce as the frontline keeping bugs out of production. Auditing has proven so effective that getting audits prior to new deployments is a widely respected industry standard.

Clearly, protocols can and should do whatever they can to attract and engage as many professional security researchers as they can.

And yet, 100x hackers remain in a league of their own. I’ve analyzed Immunefi’s own data, which is by far the most comprehensive in the space, to show you a picture of what these 100x hackers look like. 

The numbers speak for themselves.

If ever there was any proof needed to show the existence of 100x hackers, here it is. The top hackers disclose far more criticals than others (many multiples of the median). Note that this graph only includes elite-level security researchers; even among elites, 100x hackers stand apart. 

Their earnings reflect a similar pattern of outsized performance; note that this graph does not have few entries; it’s just that the largest earners outstrip everyone else by a vast margin.

The onchain economy survives because of these 100x hackers, who have prevented countless billions in losses that would have otherwise destroyed the legitimacy of the crypto marks. Every independent security researcher should strive to become one of them.

These graphs prove the 100x hacker’s existence through the metric that matters most: Positive security impact through funds saved and harm prevented, shown logarithmically. Note: This data comes from a narrow sample of 33 bugfix reviews, made public on our blog. It does not include the entire dataset of reports (which is thousands of vulnerabilities, most of whom have not had impact quantified due to how labor-intensive that work is). Note the dropoff into the millions in funds saved, the result of an artificial cut on our side; there were some hundreds more cases accounting for single-digit million saves, a milestone which most elite security researchers on Immunefi have achieved.

Funds saved reflects the true, differentiating marker of the 100x hacker, which is that they can find unique vulnerabilities, understand how to turn them into catastrophically dangerous exploits, and responsibly disclose them to prevent 100x (or much more) the damage of the typical security researcher. And they repeat this immensely challenging security feat over and over again.

Before we further explore the profile of the 100x hacker, and how you might learn to become one, it’s worth exploring the link between the 100x hacker and the 10x developer. 

For those unaware, the 10x developer is a hypothetical engineer who is 10x more effective than the typical software engineer. Many people claim to have worked with one of these rare talents. Others doubt their existence. They get their incredible output from their vast knowledge of computer science and the software stack, applying just the right solution at just the right time–and quickly. The end result of their superior skills is the capacity to produce 10x the output of the typical developer. They can do this because programming is not effort-dependent, but rather knowledge-dependent. You can achieve many tasks in 1,000 SLOC, or you can do it in 10,000 SLOC. It all depends on what you know.

There are similarities between these profiles since the 100x hacker is knowledge-dependent in a similar way. Their vast knowledge of existing vulnerability and exploit patterns, onchain primitives and blockchain architectures, and the various security tools at hand make them capable of massive security impact.

But where the 10x developer’s impact scales with their production, the 100x hacker’s security impact scales with their ability to surface potential harm. In crypto, the capacity for harm scales so massively as to make their impact uniquely valuable. The classic example of this is the $billion dollar vulnerability, of which there have been a number in the history of DeFi and on Immunefi.

But this takes us to the most important question: how does one become a 100x hacker? Is there a replicable method? To find out, I’ve spoken to many of these 100x hackers working on Immunefi, who were generous enough to answer my questions. To summarize my conclusions, derived from a mixture of these interviews and my own profiling conclusions, the 100x hacker is characterized by:

1. A deep knowledge of computer science and blockchain fundamentals. A strong, intuitive mastery of the fundamentals is a prerequisite for high-level hacking skills. You cannot fully exploit what you do not understand.

2. Strong mathematics and coding skills. At the highest levels of vulnerability detection, analysis, and exploit packaging, strong math skills play a crucial role. Note that 100x hackers are not necessarily the best developers, but they do understand development very well. Sophisticated hobby projects are very common with them, as the flip side of the urge to break or disassemble is the urge to create.

3. A comprehensive knowledge of vulnerability patterns, attack vectors, and exploit design principles, unique to their focus area and personal interests. Encyclopedic knowledge of these areas allows them to find innocuous hooks and turn them into full-blown exploits. Because such knowledge is typically field-dependent, it often emerges from day-to-day work or personal interests, and takes countless hours to build.

4. High creativity, with an eccentric and often divergent mindset. 100x hackers are very independently minded; they have to be in order to hunt and find what no one else has found. Living this way results in unique perspectives and eccentricities. This is one of the most defining characteristics of the 100x hacker, as they have creativity in far greater abundance than most of their peers.

5. A high tolerance for risk, the first of which is the willingness to risk one’s own time throwing their energy against ostensibly impossible-to-crack code, and the second of which is to devote one’s personal time and career to the task indefinitely. Becoming a 100x hacker requires a long period of research and work that can’t be rushed.

6. Tenacious grit and tolerance for pain. 100x hackers throw themselves against the castle wall of secured code over and over again. They give up on a target far later than others would.

7. An idealism, pro-social attitudes, and a strong sense of integrity, but in blackhat cases a deep skepticism of the prevailing systems of society and morality. Whether moral or amoral, they tend to go to extremes.

These atypical psychological factors drive their outsized security impact. Factors #1-4 give them the advantage of compounding knowledge, which lets them see what others can’t. Factors #5-7 give them the intense self-belief and tolerance for suffering necessary for trying repeatedly. 

Given the demanding requirements of the above profile, it’s no wonder 100x hackers stand out. Becoming one is a long, multi-year journey with few upfront rewards or assurances of success. 

And yet, 100x hackers can drive onchain security like nothing else can. We need more of them.

If you dedicate great effort to the fundamentals of blockchain security and cultivate your character and personal discipline, you can become like the best hackers in our industry. Over a long enough time, these factors should bring you to their level. I certainly think so. I’ve seen it a number of times now.

We built Immunefi for exactly this reason, and its operations revolve around attracting, nurturing, and incentivizing these rare 100x elite hackers. Today, we are proud to work closely with many of them. This cohort of elite security researchers is the single most potent security force in all of crypto, as the last three years of Immunefi critical vulnerability disclosures have shown. 

The journey of becoming a 100x hacker is a long road, but you don’t have to travel it alone. We have a thriving community of security researchers and Immunefi team members ready to help you get there.

I invite you to become one of them, and if you’d like to work with them, you can get in touch with Immunefi here.

If you like my blog, please subscribe & share it with your friends. I write in my free time, so seeing more people read these posts motivates me to write more. I don’t send anything except my writing.

Share

Share mitchellamador.com

Preamble

Over the last few years, I put aside writing to protect the onchain economy by creating Immunefi. This post is an honest review of that mission to date, and the results we’ve achieved–$25 billion in hack damage averted at minimum. In drafting this post, I asked myself what next contribution I should make. My conclusion: my insights and experiences at the cutting edge of onchain security have proven valuable in helping my colleagues and founder peers avoid the same mistakes.

So, I’ve decided to share my learnings with the broader community, starting with this review of Immunefi and the Scaling Bug Bounty standard. I hope it proves helpful to you.

Post TLDR:

1. Immunefi was founded to prevent an onchain financial armageddon, which hack records showed was incoming circa 2021.

2. Immunefi succeeded in this effort, preventing over 500 critical security incidents and preventing at least $25 billion USD from being stolen.

3. Driving adoption of bug bounties in crypto was very challenging, and is not yet complete to this day. See end of post for lessons on how to drive future market standards.

In 2020, I watched the initial wave of smart contract hacks during DeFi summer. 

Having spent that year analyzing the then state-of-the-art defenses to match against my threat forecasts, a menacing future appeared. If the blockchain security stack did not quickly mature, then the blockchain economy would face a financial armageddon of hacking crime that risked de-legitimatizing the entire industry. 

After reflecting on how to prevent this impending catastrophe and exploring the space, I concluded that the most effective tool would be the mass adoption of bug bounty programs. 

In 2020, bug bounty programs were rarely adopted and deeply unappreciated by the blocksec community. I, however, believed they would allow and incentivize the entire global blockchain security community to shore up the defenses of key industry infrastructure through decentralized, permissionless code review. Even better, such programs would become increasingly effective as the blocksec community expanded, while also acting as a powerful reflexive steroid for security community growth in the form of financial and career incentives. 

At the time, I estimated there were less than a thousand serious security professionals responsible for all key industry security duties diluted across projects, from propping up the industry’s most important infrastructure to auditing, to hunting for bugs in mission-critical code. 

To say blocksec was understaffed would have been a dramatic understatement.

Without dramatic growth in the security talent pool, we wouldn’t be able to do all the internal security work, audits, responsible disclosures, security tool and product creation required just to survive. 

Yes, it had become clear: only mass adoption of bug bounty programs could save crypto from a dark forest armageddon. 

That’s why I founded Immunefi. 

Solving the hack problem

There were two huge problems Immunefi had to solve to achieve this mission and make the industry safe: 

1. Drive bug bounty adoption so that incentives and power dynamics would disfavor criminal hacking activity

2. Grow the aggregate blocksec community in the face of countless alternative temptations

In the web2 space, tech companies would customarily pay out $25-50k for a big bug bounty. Even great Web2 hackers might get just six figures for a truly critical zero-day sold through a zero-day broker (often with intelligence agencies as the end purchaser), with only the most exceptional zero-days going for seven figures. The world’s largest tech companies (Apple, Google, Microsoft) have just begun to offer 7 figure bug bounties, though I have no evidence that they’ve made any such payments yet.

But in the web3 space, the unique attributes of the onchain economy make monetizing onchain vulnerabilities so much easier. A blackhat could use their own zero-day vulnerability to make many lifetimes' worth of riches in a single heist. The only whitehat alternative at the time was to contact the project, explain the problem, and usually get ridiculed, ignored, or paid a laughable pittance. No sir, this dynamic would not be viable.

These were big problems, and barring a powerful new catalyst, we were going to be very, very screwed.

To break through this depressing status quo, we needed a conceptual battering ram. We needed an utterly novel, yet easy-to-adopt solution that would make protecting the onchain world both meaningful and financially worthwhile for security professionals worldwide.

After much reflection, I created a simple thesis that: 1) bug bounties are the best way to protect onchain assets, and 2) the size of bounties should grow together with the amount of capital at risk (you can read the original thesis here), subject to practical financial limits. For example, if you have $10 million at risk from a particular bug, the bug bounty payout should be up to $1 million (a reward of 10% of the impacted funds), caveated by program-specific rules and a cap corresponding to cash and tokens earmarked for the bounty. 

A hacker could still earn more by executing the exploit, but then they would be breaking the law and have to spend the rest of their lives looking over their shoulder (see Ilya Lichtenstein and Razzlekhan as a good example). I reasoned that if a hacker could get life-changing money through either path, the benefit of not having to forever watch their back would be preferable to most hackers, even if the financial return was not as high.

I called this new thesis the scaling bug bounty standard.

Since then, scaling bug bounties (most especially on Immunefi) have become an industry standard and prevented immense harm. But did the scaling bug bounty standard really make the blockchain economy a safer place? And was the immense harm prevented worth the dramatic 10-100x increase of bug bounty sizes that the scaling bug bounty standard drove?

In this retrospective, we’ll examine the numbers and evaluate the real impact of the thesis, and whether or not it prevented the ‘financial armageddon’ I foresaw.

—

Reviewing the damage

We can assess the impact of Immunefi and the scaling bug bounty standard by looking at the frequency and impact of hacks over the years. If hack incidence or aggregate impact is going down over time, then we can be confident that overall security in the industry is improving, which Immunefi and the scaling bug bounty may be responsible for.

Reduction in hack incidence or hack impact is not sufficient for us to conclude that Immunefi itself is responsible for that outcome. However, increasing ecosystem security (which reduced hack incidence and impact both indicate) is required to prove Immunefi a possible cause.

Fortunately, Immunefi has been monitoring hack incidence and impact for the lifetime of its operation, so we have hard data (though it is probably not inclusive of all incidents). 

The data tell us there were 107 hacks in 2021, 134 hacks in 2022, and 247 hacks in 2023, for a total of 488 publicly known hacks from 2021-2023.

These hacks impacted $2,334,863,067 USD in 2021, $3,773,906,837 USD in 2022, and $1,699,632,321 USD in 2023, for a total of $7,808,402,225 in funds impacted from 2021-2023. For clarity, funds impacted means funds hacked, stolen, or otherwise lost, but doesn’t include funds returned or reclaimed by whitehats and investigators.

Conclusion: Hacks are up in volume (and increasing), but aggregate impact appears to be trending downwards in magnitude, in a very material way. In other words, more hacks are happening, but they’re becoming much less severe on a per-hack basis, and the aggregate hack impact appears to be decreasing as of 2023. So, onchain security is objectively improving according to the metric that matters most (funds stolen). 

Another fact becomes apparent: the future I was so concerned about (an onslaught of onchain hacks) did occur as forecasted, but the impact of these increasing hacks appears to have been limited. The crime wave came, but the industry had blunted its force.

Clearly, an early onchain financial armageddon had been successfully prevented!

But this doesn’t show us what prevented it. While Immunefi and the scaling bug bounty standard are logical candidates, there could be other causes. To understand that, we need to look toward funds saved and exploits patched as evidence of security success. 

Attributing impact from theft prevention

The most effective way to understand what drives security impact is to quantify and categorize interventions that successfully prevent security incidents. Here’s a quick review of security measures and their quantifiable impact:

• Security incidents averted via audits and external code reviews

  • We can look at the quantity of vulnerability findings in public audit reports. Unfortunately, it will be an incomplete dataset, since countless audit reports are private, and many audit findings are unlikely to result in security incidents (as most findings aren’t critical severity findings). Finally, nearly every firm uses a different measure of severity, when even most such ‘high’ severity vulnerabilities may not lead to loss of funds or material security events. There are some rare exceptions to this rule, like ThreeSigma, which uses Immunefi’s Vulnerability Scoring System to hold itself to a high performance bar.

  • For external code reviews, most of the code reviews aren’t happening on mainnet. Additionally, the focus is not on the most critical types of bugs. Finally, the data on any funds that would have been saved from such disclosures is unavailable. 

  • This isn’t to say audits and external code reviews aren’t worthwhile. We believe that audits are highly effective tools for preventing hacks, and that every onchain founder should use them as standard tools in their security toolbox. It’s just that their real-world impact is challenging to quantify in dollar terms. As a reflection of our conviction, Immunefi itself offers two audit contest products, Boosts and Invite-Only Programs, connecting founders with Immunefi’s top hackers to provide unparalleled code security outcomes prior to deployment.

  • Still, we can measure the degree to which they failed to prevent failures by looking at the number of hacks that occurred on audited protocols. Unfortunately, the data shows that nearly all major hacks occurred on widely and regularly audited protocols. It seems unlikely that audits are predicting hacks per se. It seems much more likely that audits are so widely adopted and predictive of future success that all major targets of value for hacking necessarily get audits, explaining the correlation. Still, the quantified impact of audits on ecosystem security remains unclear. I may do a deeper dive into the historical efficacy of onchain audits in the future to settle this question for my own understanding.

• Security incidents averted via monitoring and interception solutions

  • Onchain monitoring systems have a similar advantage to bug bounties. Their specific impact can be quantified, and a security event can be clearly classified as resolved successfully (or not). 

  • Unfortunately, I’m aware of no public and verifiable store of onchain interception events that can be trusted to come to such estimates (though if you find one, please let me know!). Adoption only really began in earnest in 2023, so it seems safe to conclude that monitoring solutions were not responsible for major security successes over the past three years, but this is hard to know for certain.

  • With luck, monitoring solutions will get more adoption and more transparency over 2024, so that we can all understand more about their efficacy.

• Security incidents averted via bug bounties and responsible disclosures

  • Bug bounties have the advantage of being quantifiable in impact, so we should be able to derive a specific, high-conviction estimate on the efficacy of bug bounties and responsible disclosures in driving threat prevention by looking at real $Value saved from exploitation.

  • This number will necessarily be very conservative, because the dataset is incomplete (bug bounty platforms do not currently share data with one another), and the difficulty of assessing quantified exploit impact (which forces us to use the minimum impact estimate to stand on the firmest ground, and that from only a small sample of reports).

Can we tell how much of this security impact is driven by Immunefi? Sort of. Since we can’t effectively measure security impact from most of the practices, we can’t establish weightings between the measures, but we can weigh the security impact of bug bounties themselves.

And by weighing this impact according to funds saved, we can then make our own evaluation as to whether the potential impact could or would have resulted in an onchain financial cataclysm, and this would be sufficient for us to understand whether Immunefi achieved its mission.

To weigh the security impact of onchain bug bounties, there are two meaningful indicators: 

1. The aggregate funds saved from theft and hacks by critical bug reports. Out of the two indicators, this is the most important. 

   1. For context, critical onchain vulnerabilitiess are defined in Immunefi’s Vulnerability Severity System as those that directly cause loss of funds (via theft or freezing), cause total network shutdown or unintended chain splitting necessitating a contentious hard fork to fix, or serious cryptographic flaws that undermine the integrity of the entire system. Such vulnerabilities truly deserve the critical levelling.

2. The number of critical bug reports. Immunefi’s severity definition of ‘critical’ almost always refers to direct funds at risk.

   1. We can consider this a useful proxy of bug bounty efficacy in aggregate due to the vast majority of onchain funds-at-risk vulnerabilities flowing through Immunefi for several years, though it does mean that this estimate is necessarily conservative.

   2. We can then compare this number directly against hack numbers to understand the impact bug bounties are having on preventing hack events.

In reviewing 1), there is no comprehensive dataset tallying funds saved by bug bounties. Such a dataset would require a massive amount of manual work in quantifying impact report by report. Fortunately, however, Immunefi keeps track of a small subset of these previously mentioned critical reports, covering roughly 33 of the total 573 critical reports (2021-2023), for the purpose of making public educational bugfix reviews for the community. We can call this our ‘bugfix review dataset’. While it’s just a small percentage of all critical reports, it does provide us with a set of publicly verifiable reports.

This bugfix review dataset alone prevented over $25 billion USD in direct harm, based on conservative criteria. By conservative, I mean: 1) an analysis of only a small fraction of Immunefi’s paid report database (again, just 33 of 573 total critical reports), 2) measurement of only stablecoins and liquid assets with material market depth, 3) no counting of dependent equity, most tokens (including all but directly affected and highly liquid governance tokens), derivatives, and market impact on token price depending on the underlying vulnerability affected, and finally 4) no counting of financial impact to products and assets built on top vulnerability-affected platforms. This $25b figure can be re-derived from all of the bugfix reviews posted on our Medium. 

If we compare this number to the aggregate hacks that did occur ($7,808,402,225 USD in hacks between 2021-2023), we can see that the Immunefi community alone saved a 3.2 multiple of that figure. By this measure, too, bug bounties have proven themselves to be a phenomenally successful security tool. If we remove some of these assumptions and include impacted value across ecosystem platform products, collateral damage to tokens and equity, or derivatives of various kinds, the probable impact would be multiples of the above number. Loosening the conservatism of $25 billion quickly brings us into the $30 billion, $50 billion, and $70 billion in funds saved range.

For 2), we can review valid critical smart contract and blockchain reports on Immunefi, year by year, and stack them up against hacks for comparison.

The data is stark: Immunefi prevented approximately 594 security events (where each security event is a potential hack), against 488 realized hacks and exploits. Clearly, bug bounties are carrying an enormous security load by preventing hundreds of would-be hacks and security events.

It’s now clear that bug bounties and responsible disclosures have played a massive role in protecting the industry over the last three years, and one vastly in excess of bounties paid (sitting comfortably at $95 million total over the last three years).

It also becomes clear that, if Immunefi and bug bounties had not been widely adopted, the damage that would have been caused ($25 billion USD in the most conservative estimates) would be multiples of the real hack damage that did occur ($7.8 billion between 2021 and 2023 according to our statistics). 

Do you think an extra $25 billion USD in hacks would have constituted crypto-financial armageddon? The negative impact of damage on that scale would probably have been so severe that DeFi itself would likely have been delegitimized and made illegal in many countries. 

Clearly, Immunefi and bug bounty adoption have indeed played a crucial role in preventing a blockchain hacking apocalypse.

Impact from talent pool growth

The scaling bug bounty standard has also driven security impact by incentivizing and nurturing the growth of the blocksec community. 

While it’s impossible to put a direct dollar sign on this factor, it’s safe to say that it will be a major driver of long-term security impact in the blockchain ecosystem, and one that compounds yearly as more professionals find ways to keep the onchain economy safe. 

But we should attempt to quantify the impact somehow. Any assessment will be incomplete, but the growth of the blockchain security community has exploded, so we can still extract some useful insights:

Immunefi alone now has >40,000 registered hackers and auditors, many times more than my previous estimate of the entire industry in 2020 (which was less than the estimated 1,000 security professionals in total). 

In 2020, there were less than 30 notable auditing firms. Today, there are multiples more auditing firms, plus hundreds of solo auditors acting as independent contractors and thousands of security researchers participating in Immunefi Boosts and audit contests.

In late 2020, when Immunefi started, there were only four major DeFi security startups of note (Immunefi, Hats Finance, Code4rena, and Forta). Today, there are dozens, and at least 50 by my count (and probably double that in reality). That is an explosion of blocksec ventures.

In 2020, security hires for blockchain startups were far and few between. In 2024, I frequently see a security hire among the first 10 hires, which demonstrates a huge increase in the number of security engineers working in blockchain. 

More anecdotally, I have had hundreds of conversations with security researchers, engineers, and at least a dozen active blocksec founders that share that they got into blockchain security thanks to Immunefi and scaling bug bounties. 

These proxy measurements indicate a massive increase in the size of blockchain’s security talent pool, and that this dramatic blocksec community growth was (and is) nurtured by Immunefi and scaling bug bounties.

That’s nice, but this is a retrospective, so what didn’t work?

It turns out that driving the adoption of Immunefi and the scaling bug bounty standard was not an instant success but rather a roller coaster of problem-solving and miscalculations. Here are a few.

I thought scaling bug bounty adoption would be straightforward; it wasn’t. 

I really thought when we were getting started that we would figure out the adoption question pretty quickly. I used to tell Immunefites that there were just fifty key problems that we needed to solve, and it’d be all unicorns from there. I was wrong, for with every big success came a whole new set of problems, multiplying with every victory.

Driving bug bounty adoption proved to be a Herculean task. It took hundreds–even thousands–of meetings and dozens of product iterations to really make adoption happen.

It’s hard to persuade people to adopt a new standard. When we started in 2020, the vast majority of onchain projects had no bug bounty program, and many of them weren’t even familiar with the concept. They had no budget for anything security-related outside audits, and showing them why they should spend even more money on something so unproven was a challenge.

The key insight ended up being framing: we needed to show people that if they put money here, they were much more likely to avoid catastrophic security events than not, and furthermore, there were no effective alternatives at the time. When we figured that out, we had a path to victory, but we still needed to hike that path.

Adoption happened through countless pushes to roll the boulder to the top of the hill. We knew we needed to hit a critical mass for the standard to take hold, but we did not understand that this critical mass was in the 100+ project range, including many giant industry names and multiple million-dollar bounties by early adopter partners.

Without any one of those ingredients, industry adoption would have failed. 

Even more worrying, adoption has been limited mainly to the most security-proficient projects, which understand the standard's effectiveness and value. The majority of DeFi projects do not run a bug bounty program to this day! Insanity! 

I am still pushing the adoption boulder up the hill to this day.

I thought bounties might scale in bounty size indefinitely; they haven’t.

The more the scaling bug bounty got adopted, the more an asymptote began to appear. First came the invention of the bounty cap, wherein scaling clauses would be bounded by a preset hard figure (ie. 10% of funds at risk up to $10m USD). This turned out to be a very good idea, as many projects simply did not have the funds to scale their bounties (for reasons we may cover in another post), and to pretend otherwise would have led to a bad place.

As more and more projects adopted the thesis, a ‘market pricing’ phenomenon began to occur, as projects anchored their bounty sizing to what other similar projects were doing. A sort of ‘market rate’ for bug bounty caps emerged. Total bounties available and average critical bounty size continue to trend upwards, but now do so gradually as projects grow larger and their bug bounty becomes more important for ongoing survival, as opposed to the dramatic upward surges that we saw in the 2021-2022 period.

It has been fascinating to observe market standards within market standard (the scaling bug bounty itself) emerge, but fascinating does not mean expected, and it wasn’t a helpful surprise at the time.

In early 2022, I predicted that by 2025, there would be $1 billion in bug bounties available. Sitting comfortably now at the beginning of 2024, I’m not so sure that prediction will come true, but I do think a gradual rise to this level by 2030 remains viable. We could hit those numbers on the onchain DeFi-market growth alone, leaving current bounties-per-project flat. But I no longer think that bounties will scale as aggressively as they once did.

I thought the incentives alone would be compelling enough for almost the entire security community to participate in bug bounty hunting; they didn’t.

I knew that bug bounty hunting required a certain type of person. You need to be highly self-motivated, to love cracking puzzles that nobody has solved, risk-tolerant of the ups and downs of bug-hunting, and you need a strong sense of personal honor and integrity (or you might succumb to blackhat temptations). While I’ve been blessed to work with many such people over the past few years, this life isn’t for everyone. 

Almost everyone in security has one or two of these traits, but a much smaller subset has all four.

But that doesn’t mean the rest of the security community didn’t help! Many of these amazing professionals did fantastic work championing the standard and driving the adoption of bug bounty programs in the organizations they touched. For that, they have my enduring respect and appreciation. We couldn’t have done it without them.

But still, I definitely missed the mark here.

I thought effective alternative standards would emerge. One hasn’t.

When I put out the scaling bug bounty standard, I thought that this would be the beginning of an evolutionary process for bug bounty standards. This didn’t happen. Immunefi and the scaling bug bounty standard itself evolved (as this retrospective shows) thanks to our friends in the wider blocksec community (and most especially Immunefi’s customers), but no credible challenger standards have emerged.

Immunefi and the scaling bug bounty standard stand alone as the best-in-class bug bounty standard to this day.

Finishing up; what’s next?

Three years ago, I founded Immunefi with the aim of preventing an onchain financial armageddon through the mass adoption of bug bounties. It seems to me that we at Immunefi, in fellowship with the wider onchain security community, have succeeded in preventing just such a disaster. It also seems that Immunefi has had a special role in safeguarding the onchain economy over the last few years. Immunefi really did become a crucial part of the onchain immune system, as we had hoped.

But in achieving this, I’ve been inspired to think in bigger terms. So, Immunefi now has a vastly bigger mission, toward making the onchain world safe for a world of open applications to thrive. Preventing the hacking apocalypse? Now that’s our every day, but there’s so much more that is needed.

So what's next? While we've raised the bar on blockchain security worldwide, the value onchain today remains a sliver of what's to come; we must prepare for the next $10 trillion dollars onchain to arrive. That means we need to raise the quality bar of onchain security by yet another order of magnitude. And there’s no other way to achieve that than to invest deeper into onchain security across the stack, from audits to bug bounties, from automated monitoring and prevention to open standards. Consider this an open call to leading projects and top investors to triple down on their onchain security investments; it will be the most effective industry growth spend ever spent.

And while the onchain economy at large needs to make big investments into security to succeed, the security industry needs to deliver technologies and solutions that are even more effective than they are today, until frequent hacks become a thing of the past.

That’s why Immunefi is building the future of onchain security to secure the next billion users and the next $10 trillion dollars. Our bug bounty platform was just the beginning. With the advent of our Boosts/Invite-Only Programs audit contests, and our leading security partnerships across the industry, Immunefi will provide everything protocols need to stay safe and secure.

We will do our part to raise the bar for onchain security. As always, I invite you to be a part of it.

As for me, consider this post the beginning of a new journey, where I share my hard-won discoveries from the security frontier for the benefit of our onchain world. 

If you like my blog, please subscribe & share it with your friends. I write in my free time, so seeing more people read these posts motivates me to write more. I don’t send anything except my writing.

Share

Share mitchellamador.com