Most projects in cryptocurrency space don't have a bug bounty program, or their bug bounty program is deficient. We think such an approach is dangerous for most projects out there. Bitcoin is probably the only project that can afford not having a bug bounty program. This comes from its decentralised nature and the way people contribute to it. If you think your project is also decentralised and thus it does not need a bug bounty, you are probably wrong in both.

Today we are going to describe how a good bug bounty program looks like from bug hunter's point of view. The following is very specific to cryptocurrency space. Don't try to apply the following to projects outside of cryptocurrency space. It may or may not work.

What we are looking for in a bug bounty? How to create proper incentive structure to motivate people to check your code for you? Let's find out.

Submission Simplicity

Don't overthink it. Don't create annoying requirements for bug hunters when they want to submit a report to you. Put all the complexity to the valuation of the submissions (see Bonuses below), don't make something a requirement unless it is really necessary.

Does a bug hunter want to make an anonymous submission? Let her stay anonymous. Also let her get her award anonymously.

Does a bug hunter want to make an encrypted submission? Offer your PGP public key. Provide secure submission web form.

Does she not want to encrypt her submission? Accept unencrypted submissions at least for lower severity bugs.

Don't require working exploit to be sent to you.

Don't require the bug to be exploited on the testnet before you accept the submission.

Don't require solutions to be discussed.

Don't require fix to be implemented for you.

Don't require the severity of the vulnerability to be estimated or discussed.

Don't have too long terms and conditions that the bug hunter must accept. It is reasonable to require not disclosing the vulnerability to other parties until it is fixed in your code and deployed to your network, but be reasonable, no one wants to read 10 pages of text, or even 5, or 3.

All you should care about initially is whether a valid bug was submitted to you or not. If you create such a requirement that would discourage someone from reporting a valid bug, you are doing it wrong.

Contact

Provide at least email or online form. Make sure your spam filter is off. If you can, offer additional options how to contact you and make sure you response promptly to every submission. The more options the better, but only if you respond equally promptly to all options you offer. It makes no sense to offer some special way of contacting you if you check incoming messages through that channel once a month. Make sure you deliver a response within business 3 days. If it usually takes you longer, make that clear before the communication channel is selected. The only things that matter in the initial response are acknowledging that you received the submission and describing the timeframe in which you reply further.

Clarity of Awards

Bug hunters are not your free working force. They are doing their job for money, not because they like your project. Of course it can happen that you receive free help from people who support your vision, but don't rely on that. Create a clear reward structure for submitted vulnerabilities. This is ultimately what will motivate people to start checking your code – fair well-defined rewards that they want to get; or what will discourage them – too low reward even for severe vulnerabilities.

Use concrete numbers, not generic phrases such as "we will evaluate each submission fairly". Do not price the awards in your token. Use Bitcoin, use US dollar, but don't expect people to care about your token. It's about simplicity again. You don't want to bother the bug hunter with the need of exchanging your token for something of actual value to her.

Valuation

In its core, only two properties matter for the confirmed vulnerability valuation – the severity of the issue and the cost to exploit it. If the bug is not exploitable, you can define the cost of exploitation to be infinite. Feel free to invent your own list of different severities, but always make sure that it makes sense.

What is the worst bug that can appear in your cryptocurrency? If you think of double spending of 51% attack, for most projects this is not the case. There are bugs even worse then that, such as inflation bugs or remote code execution (RCE) bugs. So the worst that can happen to you, that should be severity level 10. Then try to think about as many different types of bugs that you can and create a severity table out of it. Here are some suggestions what to include in your table:

• bug that can cause memory leak and subsequent denial of service (DoS);
• ability to instantly crush the node the attacker can connect to;
• bug allowing anyone to spend any coin regardless of private key ownership;
• ability to steal funds from a user without the user making a mistake;
• convincing a specific node in the network that transaction was made even if it wasn't;
• bug that causes the wallet to loose track of some coins and needs to be resynced/reinstalled to see them again;
• ability to show attacker's message to a wallet user that looks legitimate;
• denial of service attack that propagates to the whole network;
• ability to access files on wallet user's hard drive;
• 51% attack or equivalent:
  
  • requiring a large amount of hash/stake power, i.e. more than 20%;
  • requiring a medium amount of hash/stake power, i.e. between 5% and 20%;
  • requiring a small amount of hash/stake power, i.e. between 1% and 5%;
  • requiring a tiny amount of hash/stake power, or none at all, i.e. between 0% and 1%;
• ability to double spend, other than through 51% attack;
• inflation bug;
• causing networks split;
• disabling certain features of nodes or network and other types of DoS;
• different kinds of information leaks (e.g. retrieve user's history, location, contents of the whole wallet, identity, etc);
• ability to circumvent any specific protection you implement;
• et cetera, et cetera, et cetera – you can find different kinds of reported vulnerabilities in the history of all kinds of cryptocurrencies.

Once you have the severity table, define valuation range on each severity level. Then you can say you will award in the lower part of the range in case the cost of the attack is high, and in the higher part of the range in case the cost of the attack is low.

Bonuses

If you want, you can specify all kinds of bonuses in order to encourage the bug hunters to make your life easier. Here are some examples again, all of them are optional:

• You will pay extra 10% if a solution is being discussed in the report, or if the bug hunter is actively helping you during the process of fixing the bug – replying to your questions, explaining complex parts etc.
• You will pay extra 30% if the bug hunter does not make public disclosure after the bug is fixed.
• You will make an official press release giving credit to the bug hunter, in case the bug hunter agrees to get 20% smaller reward.
• You will pay extra 30% if a working exploit code was delivered.
• You will pay extra 20% in case there are multiple attack vectors and all of them are covered by the report.
• You will pay extra 50% if a full fix is delivered with the report.
• Et cetera – think about anything that is valuable for you so that you're happy to pay for it.

Fairness

Finally, make it worth to submit a bug to you. And make it fair. Most of the cryptocurrency project have more or less transparent history of funds. So don't play stupid and try to convince bug hunters that your project does not have any money because it's a community effort. Especially don't do that, when your wallets are full of tokens worth millions of dollars from ICO/IEO/..., pre-mining, initial distribution, or just bootstrapping period.

Neha Nerula recommends bounties to be multiples of vulnerability prices on the market to align incentives well. This is not always practical or possible – think about a bug destroying your whole project. That can be worth millions to your competitors, but it is probably not reasonable to make such an offer.

So what pricing do we consider fair? You should understand what you're paying for. It is not just the final act of finding the bug that was reported to you, which can take anything from 1 day to 2 weeks. You need to price all the other work that the bug hunter must do in order to achieve that point. Quite often it means years of experience in the field with expert understanding of all the details. Then it means time to learn specifics about your code base. Even if your project is a fork of another project with which the bug hunter is familiar with, there will be differences. There will be differences in the code, in the way the code is compiled et cetera. Also you should understand that most of the bugs are initially just ideas. And it takes multiple ideas that will turn out to be wrong ideas before the bug hunter comes with the idea that actually works. Often the bug hunter is working for free for long time trying all different ways to bypass certain protection, to find the hole, only to discard that completely without being paid. All these you need to price in. It is the work that you don't see.

What does it mean specifically for our group? We are focusing on medium to high severity bugs and for medium, 5/10, severity bug (think about crashing a target node the attacker can connect to with small cost of just some bandwidth and CPU power) we are happy to receive around $5000 worth of Bitcoin. The price increases dramatically with every severity level, so we'd be looking for $50000 equivalent for most severe bugs.

If you think it is too much, ask yourself why no one from your expert development team was able to find the bug.

But Our Project Has No Money, It Is Community Effort...

So the situation is basically that:

• you have a cryptocurrency which contains a financial network;
• you are probably promoting this project to people to onboard them;
• you probably already have hundreds or maybe thousands of people invested;

but you don't have the required knowledge to keep the network secure and you haven't even allocated enough money to pay to people who have such a knowledge and can help you to keep your network secure. If this is the case, you are acting irresponsibly, gambling with other people's money, and you should not ask for any sympathy. It's actually better for everyone if your project is exposed sooner rather than later before more victims fall for it.