Launching an Effective Onchain Bug Bounty Programs - with @hrkrshnn, CEO of @spearbit & @cantina-xyz

Hey everyone, my name is Dan Johnson and I'm on the protocol security team here at Coinbase. I'm joined here today with Hari, the CEO and co-founder of Spearbit and Cantina, web three security companies that are dedicated to protecting the onchain ecosystem since 2021. Uh today we're serving up our 12th episode of our ongoing Coinbase security series where every two weeks our team gets together and gets to connect with all the great builders in the web 3 community and discuss a variety of topics on blockchain security and how to build safely in the space. As a heads up, this will be our final session for 2025. So consider this to be our season finale for season 1.

Uh and we'll pick things back up in the new year. As is the case with each of these sessions, please note the disclaimer that's at the bottom of the screen. Um, and with that, we've got a great session for you today. So, I'll let Hari take it away.

Awesome. Thanks, Dan, for the introduction. My name is Hari, as uh Dan mentioned, and I'm one of the founders and the CEO of Canina. And we started the company after after seeing a lot of security incidents in the crypto industry. And I used to work back in the day at uh the Ethereum Foundation building the serity language and the compiler.

And we saw the problem firsthand as we were talking to many of the builders building our chain and none of them were happy with how the state of security was. they were like afraid of launching their code um to production because you know there were this like hackers trying to steal money and uh we built a company to try to fix our problem and one of the offerings that we do is a bug bounty platform and I want to maybe like cover a few topics that we have learned over time on how to run a successful bounty and you know that's the goal of my presentation here but maybe to start with like you know I to set the stage here like why does security even matter uh for onchain products. It sounds a very it sounds like a very simple question but it's not because a lot of the people listening are early stage product builders, early stage startups and if you are a product builder in the web 2 world especially as you are young security is often an afterthought and security is an afterthought because of a you know a reason. Um if you are a small company with very few users, there are very few malicious actors trying to work havoc in your uh product or or company. But that is not the case with uh onchain products.

And why is that? Uh the the reason is pretty simple. For many onchain products, you're oftening often dealing with money. And when there is money involved live in production, you are effectively setting up an incentive for these malicious actors to come in and take it. And unfortunately, that's what happened in the last, you know, like several years of crypto where smart contracts get hacked, infrastructure that has to deal with money gets hacked.

Um and it ultimately comes down to the simple fact where you know there is a lot of money at risk and anyone can come and interact with these uh protocols or smart contracts and for better or for worse people can like take that money and liquidate it pretty easily. That is not the case for many web 2 startups. Um the worst case for many web 2 hacks as a small company is like you lose data, you lose data, you might get dosed and it's often not it's it's not easy to assign a monetary value to that uh at least at the beginning. Obviously as you get bigger, you know, data loss is uh not an easy it's not an easy like thing. Often times you get fined, you go to court, your customers might file a lawsuit against you if you do that.

So as you get more mature, companies invest a lot of resources into security. Crypto and onchip products are something where you have to as a builder invest in security very early. You know, if you are touching money, you need to like make sure that that is secure. So that's like at a high level. Why do you need to even do security for onchain product products especially as an early stage builder?

Uh crypto is different different crypto security is different. One of the u famous sayings in the web two world is like move fast and break things. That doesn't work in crypto because you're touching money and people will try to steal it if you try to be careless. So the next thing I I want to set up is okay you need security. Where does bug bound come into play here?

The like our common recommendation to customers building onchain products is try to do a secure review before you are launching to production. And if you have the time, budget, and resources, try to do a security competition, which is you you put out this codebase out there. You work with a platform like us, and you offer a reward for anyone that can come in and find a valid security bug in your software. And but bounties are a very similar mechanism that's been around for a very long time where after you've gone into production, you set up a bounty which is an incentive for anyone to come and look at your codebase and to find bugs and get rewarded for finding bugs. So this has been around for a very long time.

But in crypto, this has been unusually effective at finding very severe bugs that otherwise double up to like, you know, hundreds of millions of dollars, maybe like billions of dollars in losses. Okay, so to summarize, security is very important if you're building an onchain product. um doing code reviews before launching is important, but after you launch your protocol, having this incentive out there which is hey here's all my here's all my like piece of code try to find a bug in there and you will get rewarded if you report that bug as opposed to like leaving it by itself or leaving it for a black hat to come and exploit it. So that's uh why onchain boundaries matter and every big company in crypto has a book bounty program. You know we're talking we're talking about the the base team here.

The base is hosting their book bounty program with cantina uh which has been very successful in finding um making sure that there's no bugs out there that there are no bugs out there that could potentially put their assets at at risk. So moving on. Okay. Now that you understand why you need to do a book bounty program, how do you make sure that your book bounty program is designed in a very um successful way? So the number one important thing to consider here is the scope of the bounty.

Okay, imagine you are a builder who just built a bunch of smart contracts, maybe a front end, and you want to decide like what asset should I put into into the scope of the bounty? And the easiest way to think about it is how do you how do you try to how do you try to like um assign severity um when it comes to let's say money getting lost. So if you are a builder that you know build a D5 app let's just say you're trying to build a an AMM on base and you have a front end for that most of the time the severe part of your software is the smart contracts that are managing the AM up. So number one this has to go into the Pokemon disc because that's where most of the money is getting managed. If you want to take it a step further, I we would also recommend you to put your front end and any other infrastructure that is part of the part of the um software.

But what we have seen is that you know the smart contracts are the bare minimum where you know that's actually managing money whereas with front end not every bug can lead to severe consequences but there's still like bugs that could you know do people into doing things or could take down your infrastructure and that's not a good user experience. So you might as well like throw it in there but with like much lower payouts. Uh so you always want to maximize like the impact of uh your program. So you want to put the bounty amounts for the smart contracts to be much higher than your you know backend code or infrastructure or your front end. And one way to think about the bounty amounts is try to tie that in some way to the amount at risk.

Um I don't mean like in a literal way where you tell people that hey you're going to pay out like x% of whatever amount is at risk but rather let's say you are a large protocol that is managing know billions in TVL the number that you are that the number for the highest bounty has to be also like pretty big for example we host one of the largest bounties in the world for unis swap and unisop is a protocol that is managing you know, like5 10 billion in TVL. And for them, the max bounty of $15.5 million is uh pretty significant to attract uh top security searches to find the bug. Um especially bugs that could potentially put billions of dollars at risk. Um, so when the amount of risk is in the billions, like there are many bug bounty programs that often offer like millions of dollars in rewards and that's often like a very interesting amount for the top bounty hunters to come and try to find the bug and disclose it.

But you if you are a protocol starting out, I think this number can be like, you know, much lower. Uh we have seen like very early stage products you know do numbers like as low as like $10,000 to like $100,000 especially for very very severe bugs and the ROI is pretty worth it especially if you are sculping that number for critical findings. It's much better for you to pay out that you know number which could be a big amount for an LS startup than be at risk of a black hat trying to find that critical bug and stealing your customer funds. We have seen you know people lose uh customer funds to hacks and it's not a not a great place to be like it's a terrible you know you you know you it's like things like turn upside down one day and we highly recommend you to incentivize like the security researchers to find the bug instead of like having a black hat find it before. So the reward, you know, try to have it somewhat proportional to the size of the amount at risk and try your best to like pay the rewards out in liquid assets, for example, like USDC or a stable coin.

I think that's a really good way to reward your white tax, but in certain cases, you know, you may not be able to like offer a lot of liquid assets. Um and we have seen some companies offer you know tokens or equity or you know some form of like value in kind that uh you can assign a dollar value to. So try your best to award them in liquid assets that are know proportional to risk somehow. Um and the third thing we highly recommend is ahead of time try to document some of the known assumptions in your codebase. So if you know that the protocol is designed in a certain way, the threat model is designed in a certain way, try to make that explicit uh in your bug bounty scope.

A common example is there are some trusted roles and protocols and trusted roles tend to have higher privileges. So you can tell that ahead of time so that people are number one not submitting these issues. Number two like are aware like what are the areas of concern in the codebase. So they can spend most of the time hunting for bugs in that. To give an example, for many protocols, they have an admin function, often times a multisig that can do upgrade actions and sometimes there are ways to do malicious upgrades and if that is a trusted role, you know, you don't want people to report that hey there can be a malicious malicious action taken by these uh multisig of trusted individuals.

that is not very interesting for um most customers and you don't want secure searches to to spend time on it. But this is like a very simple example. Uh there are many protocol specific rules out there and it's much better to get that ahead of time. So you're not you know you're not wasting security time and you're going to have a much better experience like going through the process uh where you're going to have a much better higher chance of getting uh um valid findings. Another thing to mention is this idea called safe harbor.

This is something that Seal as an organization has been pushing for which is the idea that um let's say there is a live protocol exploit. So one of the worst examples here is uh the Nomad hack. So Nomad was a bridge that got hacked for almost $200 million unfortunately. And this was a protocol exploit that was happening somewhat in real time over like an entire day. And many wide hack secure searches were able to save funds because they realized that this protocol was getting hacked and it was possible to save some funds.

So safe harbor is a legal contract that gives them some protections to do that. So there are some companies out there, some security searches that try to make sure that if they find an exploit on chain, they can protect that exploit and be do that in a legally compliant way. So it's as simple as saying that, hey, here are the rules. You can um you can um you can u um okay you can like uh protect the funds and here is an address often times a multisig where you can safely send the funds and there's often like rewards for doing that and the rewards are often like comparable to the bounty amount as well. So if you find an exploit in the wild that's getting hacked and if you save it, you know, you could potentially qualify for up to like the max uh equivalent bounty.

So that's one way to like legally protect some of the people that want to defend your protocol as well. And it's something that is up and coming. So moving on, these are some of the tips for uh secured your searches watching. But if you're a you know protocol team that's watching um this will help you understand some of the challenges and how to make the life of security searches easier. So it's like something that's useful for both the security searches and the teams.

And these were some of the tips that were shared by Alexis from um the Coinbase team. So we had a conversation a couple of weeks ago um on how to run a well what are Coinbase's takeaway from running a successful bug bounty program. And these are some of the um suggestions by Alexis from Coinbase security team on um how secure researchers can maximize uh the impact of their submissions and how they can make life easier for the people reading the finding and you know this can go a long way in getting yourself like higher rewards and getting your findings taken like much more seriously. So one you know top tip that I can share here is for every severe submission that you're making um try to have a reproducible proof of concept. So what is a proof of concept?

So let's say you find a bug. Let's say you find a bug in which you can you can show that hey there's a million dollars at risk on chain today uh with this exploit. And historically tooling in Ethereum was not great but this has changed today. There are great tool tools out there that allow you to easily reproduce bugs in a safe way. And one such tool is a foundry and it's a it's a set of tools that allow you to write code, test code and simulate actions on chain.

So let's say on Ethereum you found a bug in a certain D5 protocol. You can write a proof of concept which is often a solidity contract that tries to do the exploit and you can write it in such a way that someone can locally simulate that this is going to be the action if the exploit happens. So you can do it in a very safe way where like nobody will really know well with with some caveats but it's not a public like you know testing and it's not like you're going to um mainet and testing it or on a test net. So only you you know with some caveats can see uh what's happening and this is the best way in which you can convince a a company that your bug is actually severe right a proof of concept and ideally something that you can fork uh the mainet state on and then ensure that hey here's like the exploit here's what happens after all these actions and here's like demonstrable evidence that this bug is real and one really good tip that Alexis uh talked about is know when you're doing the fork test try to make sure that the environment you set up is realistic. Sometimes there are certain like you know state variables or certain trusted actors are not properly set up and that leads to people thinking that they have a bug when they don't actually have a bug.

So most of the time if you try to do a fork test you will be able to like see all this like small edge cases that makes your bug invalid because you know that's not realistic. So If you are a company listening to this, the best thing you can do is well number one try to have a a codebase that is easy to run and test on and maybe you can like leave a tip like hey look at this test case from our codebase if you want to write a proof of concept yourself. So that can often like speed up the process for secure researchers when you know they want to submit a finding and validate the finding and um this also like allows people to focus on the actual exploit path and you know I like the word in the slide which is the gymnastics. So sometimes like there are there's wrong assumptions made in tests that are not realistic uh in a real world scenario. So having the proof of concept that has to do with the fork environment allows you to like find these you know edge cases that make a bug not valuable.

So a couple of like very common mistakes on EC is uh people tend to rely on mocks. So you want to be able to like simulate a certain actor and often times it's not very easy to simulate that actor. So you you write mocks. So it's a very classic like testing strategy. But what people make a mistake is they often make the mock more uh do more take more actions that actually happens in in in real life.

So the mocks are wrong and which leads to like a wrong P and which leads to like people thinking something is severe when it's not severe. The other thing that I highly recommend for everyone listening is uh you know if you are a protocol you know try to be very fast when it comes to like triaging the submissions. So we try our best to like support teams that don't have a lot of capacity by offering triaging services. So you know when you sign up for a bounty with us you can additionally sign up for triaging from our side. So where a team of people from our team would be looking at the bounty and you know telling customers that this is severe this is not severe and we have seen that the quality of the buck bounty is often correlated with how fast the teams are when it comes to responding to submissions.

So if you're able to like come back to secure searches like pretty quickly saying hey this is valid we're going to you know deploy buck fix immediately and here's a reward you will attract them to come back even more to hunt for like bigger and bigger like chunks of your code. So that is the ideal case where you know you come in you respond to things quickly you make decisions quickly you you know help payments move fast and these secure resources will come back and try to like look at even more bugs in your code base and that's like a win-win for everyone and that also like helps you build trust as a brand which is like another reason that people like to have a book quantity program because it inspires trust that you know when as a user of your protocol you know, if you're putting like, you know, tens of millions of dollars in the protocol, your users can sleep well at night knowing that you're doing your best when it comes to securing the protocol. So, at the end of the day, like the money involved is pretty high and you need to also like inspire trust in your piece of code, in your software for your users to like put their money in your protocol. So, having this like very fast, respectful process is a good way to do that. and it helps like you know researchers uh come back for more.

So here's like some of the things that you know we learned working with Coinbase doing their successful Bundy program and this touches on some of the topics we discussed earlier. So I'll make it like super fast. So make it easy to participate just allow anyone to come in and submit findings but make sure that the standard for submission is pretty high. require a proof of concept for everything and if you're a researcher make sure that you are writing the PC's investing the time and you're gonna have a much better experience another thing is like investing in the ownership of triage so if you're a try to assign a single person in your company who's responsible for handling all the submissions that are triage by our team and try to be very decisive when it comes to like fixing bugs making payments um you know things on that side and lastly like you Ultimately the people submitting bugs are mostly humans. Um this is something that's changing over time but you know these are humans and they invest a lot of upfront time in finding bugs.

So communicating very well both sides it goes a long way in building trust and making sure that these security sources are coming back to find bugs and disclosing them early. So that's like a very short summary on like how you can run a successful bounty program. If you have any questions, I'm happy to answer right now or you can always reach out to me on Twitter or Telegram or email.

Yeah, awesome. Awesome stuff, Hari. Uh yeah, looking through our our stream here. Um, and as I give people a chance to add some questions of their own as well, I may as well just ask something I'm naturally curious about because I know that you've seen uh you've seen the space evolve uh drastically since the time that you guys have rolled out a lot of changes since 2021 and especially in the past year. There's been a huge increase of some pretty sweet AI related tools that are introduced to the space.

So, like what uh percentage of bugs reported in 2025 do you suspect were found specifically using AI tools versus, you know, security researchers doing a manual line by line code review? Um, and then my follow-up question will be how do you think that percentage is going to change in 2026? I think this is a great question on multiple fronts. The first thing is uh I think everyone knows that like AI is like supercharging people in every single way. like people are able to like write things faster, people are able to test things faster, they're able to write more code faster.

So we are seeing that number one like in the last two years people are using LLM, JPT cloud both in good and bad ways in submitting findings. So in the last two years we saw a very interesting trend which is when these LLMs started getting popular, we started getting a lot of spam submissions. So there is a lot of LLM generated spam at the beginning which is like people asking JPD hey here's a codebase find me a critical bug and people will like literally copy paste that and put it in the bounty uh so please don't do that you know try to like do your best to validate it

but today like I think we are seeing some more interesting things where what we're seeing is security researchers understand that these tools are powerful and they started using the tools to help um hunt for B findings. So we're seeing more and more findings that are like often like human and AI working together to like discover ideas, write proof of concepts, try to write things better, try to like add more data. So we're seeing a lot more of that on valid findings by humans combined with AI,

right? Right.

But we're also seeing this completely new trend which is uh like agents and AI finding bugs, validating and all this like things by itself.

And that is like the shocking part where

I think in the next like 12 to 24 months we're going to see this like become more mainstream. Um as an example like we have a tool internally that is a completely autonomous buck hunter. Like last week we found a bug on a protocol that's live and they had to fix it urgently and this was found by an agent and like obviously like we are very respectful of people's time so everything that we submit like a human will look at it but this entire bug was found by an AI so I think we are slowly going to see more of that like know starting with llm swap to human plus AI to this AI just finding bugs. So, this is the future.

Yes, sir. Yeah, I saw you raving about it on uh over on Twitter or X. I I every once in a while I'll pop in and see uh Yeah, I see you show up on my feed. Um that was Yeah, I'm it's piqued my attention, got my interest, I'll just say. Um but yeah, you you did mention uh all of this resulting in unfortunately a lot of spam or lower quality reports coming in.

um whereas they yeah they may or may not be legitimate and you have to take every reported bug in these bounty programs seriously. So like what um you know what initiatives or changes do you think you can add to the the platform to kind of still be open to new talent while avoiding these uh this spam that's coming in?

Yeah, I think this is also a great question and number one like some different people have different takes on how to do it. We have always felt like to fight AI you need to use AI. So we've been building AI tools to detect AI. We've been using AI tools to like do some triging and that's been interesting especially in like certain types of protocols like solidity contracts like we can fairly get a really good AI triage that's consistent with what a human would do but for others like we're trying to like expand our capacity there. We can also like figure out with reasonably high confidence these days like whether something was written by AI.

It doesn't always mean it's an invalid finding but um that's a signal.

Um another thing is like reputation score. So if you are a researcher that has a history of of submitting great findings then you you know we can assign a score to the person. We've been doing that for a long time and that is a signal for like hey this is probably correct because this person has a reputation for finding a lot of bugs uh based on their historical performance. Another thing that some smaller um protocol teams have started doing is uh charging for submissions for certain smaller companies you know they are asking like hey you want to submit a finding you need to stake like know $50. So this is and there's like different like opinions across the board.

So for larger companies like Coinbase, they see every submissions as valuable. So they want to get everything even if it's like like not very interesting cuz for them like people paying attention to software is very valuable. So for Coinbase like anyone can come in and anyone can submit findings like they have all the resources to like look at findings and learn from it. But if you are like a very small team of you know five people building maybe this is like too much and charging for submissions is a smart way to like you know optimize for your use case. So we have seen like all of this like playing out.

Yeah I I totally see it you know both sides of it. I I think there's a lot of lean teams in the space. I would say a majority of teams are extremely lean and uh it's yeah that that's they don't have the time to look at all of the the spammed reports that might come in or duplicate or otherwise not you know human reports. Um but at the same time, you know, from from our perspective, yeah, it is that every you would hate for any of these gates that be put in place that prevent some, you know, your eyes being placed on a bug that's reported. Um you would hate for that gate to prevent you from seeing it.

Um and it unfortunately lead to something that, you know, could be a very expensive loss. So yeah, I definitely see both sides of it. Um, I guess you know I'm I'm curious. I should check back in with our chat, but I am curious uh that the of your opinion on like what TVL amount would you say warrants a mandatory bug bounty program be in place for teams and then out of those in that threshold? Uh what percentage would you say uh should like actually have one set up today?

I mean this is a this is a great question and I can share some just anecdotals you know this is not backed by hard data but from our experience you know taking from the very top you know if you have a billion dollars in TVL there's a guaranteed like black hat's trying to find ways to like try to steal that and we feel like the amount where it gets it gets like black hat attention is like on EVM on easy protocols like you know about like $10 to $50 million. That's around the time where you can guarantee that like Malaysia's actors are trying to like steal the money.

Uh in none EVM protocols like I think the number is a bit higher because people pay less attention to it.

Um but but yeah, like if you're if you have a protocol with already $10 million in TVL and it's growing, assume that malicious actors are trying to come in and try to steal it. like you need to be like you need to like take security seriously. Like even if you did not take it before like that is the time that you need to pay attention to it and do it prospective like hey what do we do like we have a lot of money on chain there's definitely people trying to hunt uh for uh uh money and what do I have to do to make sure that's secure. So, EVM, I would recommend like anything over a million dollars, like try to have at least a small bounty. At a $10 million, like it's irresponsible not to.

Uh, at like 50 and above, like people are going to try to steal that money every single day. So, you need to be proactive about like that.

Yeah, absolutely. I I think you know it's uh there might be that sense of comfort even even when you hit that million-dollar threshold of well you know it if something bad were going to happen it would have happened by now so surely we're already you know battle tested in and into this you know secure protocol but no I I think you're absolutely right um the the use of the word irresponsible to a certain extent I think is uh I mean that definitely rings that that just stood out to me and I I do agree. I think you know to an extent you need to these measures exist and these tools and resources exist to keep your users your community safe. Um so yeah at a certain point you know you do need to be a responsible owner of your of your project and and have it set up. So, I guess yeah, the only thing you didn't catch in that question was what percentage uh that are at that, you know, maybe let's say the the $10 million TVL mark.

Uh what percentage would you say have a program set up versus do not? This is a this is a hard question to answer. I think have a hard number, but I would say it's more than 50%. like like crypto companies unusually um like do better at security than like some of the like classic traditional companies. They know that the risk is real

and the number is going to be much like rel compared to like a web two company that has similar levels level of success. Um more crypto companies tend to like have bounties and things like that. So we we think the numbers like pretty high like 10 million about about TVL like a significant portion either have a bug bounty program with a partner or often have like you know security email where they often like reward bounties. So um if you don't fall under that category like you are losing user trust like users don't trust um teams that don't do any security like that that's the reality like if you you might get some TVL but if you want to get the next jump in TVL like people look at these details like especially with some of more like institutional investors that we're seeing

they really pay attention to like security details because they are often like liable for that money. So they have to be responsible for you know putting that money in some protocol for yield or you know trading. So if you want to attract like bigger you know attacks from getting into your protocol you need to like be responsible for security and do at least like have an internal bug bounty program. You know the the best thing is an external facing one but like at least have something.

Yeah. Yeah. Yeah, at the end of the day it's a it's a reinvestment in yourself as a team. Um it's and it should definitely be seen as such and your community is going to see it that way. Um yeah, and I guess uh to wrap things up, you know, do you think uh there are any other gaps in these bounty platforms that that exist today?

and what uh exciting changes that you can tell us about uh that you're aware of that are coming to cantina um in 2026. I think the biggest thing uh for us is uh like we have spent a lot of time on AI in the last like you know six to 12 months and we have a pretty good understanding of where things are going and I don't think like teams are really prepared for what is you know going to happen to give an example like in the last one month there were like two big articles one by anthropic another by um OpenAI just yesterday about how these models are able to find security bugs sometimes like out of the box. Um so what does it mean for the future of open source code where anyone can now you know try to become a bug hunter and some of them might be malicious some of them might be like white hack uh hunters but I think their risk is going to increase because there's more code getting produced there's more people that are able to analyze code and there's going to be these autonomous um agents that will make the life of a black hat you know hacker easier as well. So I think we're really thinking hard on what does it mean uh for the future security what does it mean for the future of you know like open source software as well and I think many things that people historically knew about security it's going to get redefined in the next few years. So that that's like the biggest thing for us and we want to make sure that our customers are safe and understand what's coming and they proactively uh take measures uh as opposed to like you know getting hit by these like new threat actors.

Absolutely. Yeah. I mean definitely a lot of the the whole the whole spectrum of from scary to exciting to just Yeah. really great things coming in 2026. Uh it sounds like uh for everyone involved an exciting year ahead.

Um but yeah, this is this has been awesome. Hari, thank you so much and thank you to the Spearbit and Cantina teams for uh supporting us as well and for taking the time out of your day to educate our awesome community here. Yeah, on behalf of Coinbase here, I wish you all a very happy 2026 and we'll resume these sessions in the new year.

All right. Awesome. Yeah, thanks watching.

Take care.