Security Budgets and The Bounty Flywheel

No one outside of North Korea is happy with the current state of security within crypto broadly or DeFi specifically.

Rather than discuss the broad range of security shortcomings and potential ways of addressing them, I’m going to make the case for how we as an industry should significantly increase our collective security spend and why increasing the size of bug bounty programs is the right place to start. ‍

Security Budgets in Crypto

The way we think about security budgets in crypto has evolved over time.

In the beginning, there was only Bitcoin. Bitcoin’s security budget came entirely from issuance of new coins, at a schedule of 50 new BTC issued on average every 10 minutes, as payment for securing the network.

As the price of BTC increased, the security budget also increased linearly. At $1 per BTC, the network was spending $52,560 per year to secure itself, while at $10 per BTC, the annual security spend became $525,600. Of course, as we all know, bitcoin issuance gets slashed in half every four years; the current annual security budget from issuance for the $1.25 trillion network is $10.5 billion at current price levels, or 0.84% of its market cap. (Yes, Ordinals and Runes are giving this a boost.)

Unlike Bitcoin, Ethereum’s issuance schedule has not been fixed, but rather has evolved to a social consensus of “minimum viable issuance.” That is to say, the Ethereum community has been aligned around setting the security budget for the network at whatever level is deemed to provide the necessary incentives to have good faith actors validating transactions on the network, and keep the cost of attacking it economically infeasible for those who might wish to disrupt it. Currently, Ethereum is a $375 billion network, spending $2.9 billion, or 0.77% of its market cap annually on security.

In fact, all layer 1 blockchains have a similar concept of using issuance of new tokens as payment for securing their network. Why do blockchains issue tokens for their security budget? First and foremost, all of these protocols care about ensuring that transactions are faithfully recorded and that users can trust that the content and ordering of those transactions cannot be changed in the future. If a blockchain can’t give these assurances, there’s not much reason to use it.

But what about DeFi protocols? What does security mean in the DeFi context?

DeFi protocols operate on blockchains, with their users paying transaction fees that contribute to the security budget of the underlying chain. That’s fine for contributing to the security of record keeping and settlement, but it’s not really what most people think about when they think about the “security” of a DeFi protocol.

For DeFi protocols, security means your assets not getting lost or stolen. Whether it be avoiding technical hacks (e.g., reentrancy), bugs (e.g., devops199), or economic exploits (e.g., Avi Eisenberg), first and foremost, DeFi protocols need to keep their users’ funds secure.

Security Budgets in DeFi

Let’s be honest: we’re not doing great on the security front.

In the end, we’re going to have to bite the bullet: we need to spend more on security.

Like, an order of magnitude more.

And as more value flows through DeFi protocols, the security spend will need to increase commensurately.

Wait, that sounds familiar…

Oh yeah, that’s what L1 blockchains do!

It has long been widely accepted that holders of tokens for L1 blockchains should expect single-digit annual issuance as a cost to secure the protocol that gives those tokens value. Of DeFi protocols today, how many have spent even 1% of their current market caps on security over their lifetime? I’d be willing to wager “not very many.”

How do we fix this?

Well, as a starting point, I’d love to see the following commitment from teams:

Contribute 1% of token supply per year toward a security fund.

This could be carved out from the 20-40% “community” allocation in most token pie charts, over the period of team and investor lockups–after all, the security community is one of the most critical to have aligned with a project’s success. Let’s optimistically call that period four years, so 4% of the total token supply.

Ideally these tokens would be sold and the proceeds held in a segregated account, either in some dollar-denominated asset or the native asset of the chain where the token contract is deployed (look, I’m trying really hard not to just say ETH or ignore the inevitable appchain migration).

How would teams spend their security budgets?

There are some obvious things, like conducting more and better audits, hiring in-house security experts, and setting up robust monitoring solutions. But there’s one big one that can drive all the others:

Bigger bug bounties, that scale with value-at-risk.

Here are the current ten largest bounties available across the ecosystem:

Not bad!

But notice how this compares to the projects’ current TVL.

That is not nearly big enough.

Now look, much like TVL itself, Bounty:TVL Ratio is a blunt metric and there are plenty of edge cases where it doesn’t make sense. For example, Lido at $30B TVL has a Bounty:TVL ratio of <0.01%, but still has a $2M max bounty on offer which is much better than JustLend at $6B TVL with a measly $50K max bounty. That said, it does point in the right direction of encouraging teams who claim to take security seriously to put their money where their mouth is.

I’m confident most teams and users would be happy to pay 5-10% to whitehats for enabling a live vulnerability to be fixed, rather than see a hacker steal 100%. In fact, that’s where a lot of post-hack negotiations end up–would you rather start with a formal bounty program of that size or publicly negotiate there retroactively with an attacker in possession of the bulk of your TVL? But realistically, for most non-Lazarus Group hackers, even a solid 7-figure bounty on a $500M+ TVL protocol is probably enough to get paid out legally rather than spend the rest of their lives looking over their shoulders.

There have been some interesting proposals and even implementations of ways to do this in a fully permissionless way onchain, which I think is a fantastic idea even in more narrow forms like the Security Alliance’s Whitehat Safe Harbor framework. That said, private reporting through platforms such as ImmuneFi, Cantina, or HackerOne is far less risky and disruptive to users, and thus should always have greater incentives attached. The main challenge here is the difference between who pays in each of these scenarios. Typically, labs teams or foundations sponsor bounty programs, but their cash on hand frequently can’t keep pace with TVL growth for a successful protocol, whereas the permissionless whitehat processes put the burden of payment on the users. My proposal to have DAOs/teams allocate 1% of token supply annually to fund security is one way to help address this, but like everything in security, it doesn’t perfectly cover all scenarios.

While max bounty on critical vulnerabilities gets the most attention, teams should make sure they don’t lowball medium and low severity bounties either. Top security researchers view hitting bug bounties like a bit of a lottery: they’re really nice if you get them, but generally they’ll prioritize looking at protocols where they’re more likely to get a decent payday for reviewing code for a few days or weeks. Large max bounties are good for headlines, showing you care, and swaying greyhat researchers to the light side; meaningful low and medium bounties are good to get more experienced professional eyes on your code.

What happens if we meaningfully increase bounty payouts and scale them with funds at risk?

My colleagues on the Nascent Security team and I theorize that larger bounties will lead to more resources and investment in all other layers of the security stack.

The Bounty Flywheel(s)

The case for bug bounties, particularly bounties tied to value-at-risk, driving increased security is relatively straightforward.

1. Large bounties attract more talented security researchers to look at a protocol’s code
2. More talented and highly motivated eyes lead to more high-impact vulnerability disclosures
3. These disclosures make the protocols safer
4. Safer protocols attract more users and TVL
5. Larger TVL drives and enables bigger bug bounties
6. Repeat

Not too hard to follow, but this alone doesn’t explain how bounties can drive investment into all layers of the security stack. For that, we need to go bigger:

While the name is admittedly tongue-in-cheek, the concept is serious. The more a team has on the line in the form of a bounty, the more painful it will be to have to pay it out. This gives increased leverage to other forms of security spend.

Of course, everyone already wants to make sure their protocol is secure; if a protocol gets rekt, the expected loss in value to the team that developed it is almost certainly far greater than what they’d have to pay out in a bounty… so why would larger bounties add any incremental motivation?

In this case, it’s not actually about avoiding having to payout on critical max bounties. Remember the earlier warning not to skimp on payouts for medium and low findings? Those are the ones that can be annoying to deal with, and if a novel codebase has not been incredibly thoroughly reviewed via multiple private audits and public competitions, it’s quite likely there are still multiple issues at this severity lurking in there.

Do we really care about finding those low and medium issues? Probably not directly. But investigating those issues can often be how security researchers find ways to escalate seemingly small surface issues, following edge cases until they catch on to much more serious high and critical vulnerabilities.

This path of investigation and discovery–paired with the unpredictable timing and frequency of reporting–provides strong motivation to teams to make sure they invest in more upfront, predictable forms of security spend.

Now, readers will probably point out that most teams already know they should be spending more on security, they just choose not to do it because no one likes having to pay for defensive measures; spending on incentives and growth has much clearer and more immediate benefits.

That’s where we all come in as users: it’s our money on the line and we don’t want to lose it, so we need to use both our voices and our assets to direct positive attention to the protocols with strong security stances. At the same time, we need to let those who have allowed security to take a back seat know that we see them and we expect better of them if they want to earn our deposits.

Giving the Bounty Flywheel a push

Given how important we believe bug bounties are, Nascent Security has built a site to collect all the bug bounties across web3 and make it easier to see how we’re doing as an industry in improving on this critical piece of the security stack:

Introducing bounty.vision

We’ll continue to add data and features to bring more nuance to the conversation around bounties and security. We hope bounty.vision will become a valuable resource for all ecosystem participants:

• Users, to understand which projects demonstrate a strong commitment to security and which are lacking
• Teams, to benchmark and publicize their bounty programs
• Security researchers, to easily identify the right reporting channels for vulnerabilities, and to keep on top of the latest updates to both bounty opportunities and the contracts they cover (👀soon™️)

Please check it out, send us feedback for improvements, and use it to both celebrate the security leaders and hold accountable the laggards.

Towards better security for all

Overall, there are a lot of nuances on what works and what the pain points are around bug bounty programs in DeFi, including how bugs are categorized, who pays, and whether payment even happens at all. But as we find ways bounty programs can be improved, it’s important to appreciate how much better we already handle bug bounties in web3 than in web2, given that it’s possible for security researchers to directly and provably demonstrate the ability to steal funds.

In fact, despite the common perception of web3 lagging in security, the nature of our industry forces us to take it more seriously than almost any other. While the web2 world has estimates like $43 billion lost to identity theft and $4.45 million in cost per data breach in 2023, these numbers obscure the fact that when bugs are exploited in web2 systems, the damage is typically much harder to directly attribute to the original source. When your identity data is stolen for the umpteenth time, was it that data breach or the third one prior that resulted in the fraud you experienced years later?

There is no doubt that security has been the Achilles heel of DeFi to date. With sufficient focus, resources, and accountability, we can make our industries’ security practices worthy of not just respect, but emulation by the rest of the world.

If you’re a builder working on a protocol with over $1M in TVL but are among the 78% currently without a bug bounty program, go set one up with Immunefi, Cantina, HackenProof, Hats Finance, HackerOne, or Code4rena today. If you already have one, consider raising the size of your bounties at all severities and tying the max bounties to value at risk.

If you’re a user, check bounty.vision and make sure your favorite protocols are putting meaningful resources behind keeping your funds safe.

And if you’re a security researcher, thank you for your service. Now go check out bounty.vision and let us know what we can add to help you continue to improve the security of our ecosystem.