Giving Whitehat Hackers Their Fair Share

Smart Bug Bounty Payouts

This article describes one of the features on the strategic roadmap of Hats version 2. We will release a series of articles to discuss the economics and processes around version 2 to engage in a productive discussion and incorporate feedback from the community. A detailed roadmap will be part of one of the following articles.

Hacker Incentive Alignment

Bug bounties are a well-known and utilized tool in the software industry to incentivize white hat hackers for their exceptional know-how in a way that is benefiting the ecosystem. White hats often help secure millions of dollars of user funds, making them an integral part of the space. It is our belief that we must give them their fair share of the cake in order to keep white hats engaged, and turn black hats into white hats through incentive alignment.

This mission can be targeted from many angles. For example, giving hackers a more secure and predictable reporting process, and enabling hackers to stay anonymous while receiving deserved recognition and bragging rights. We will cover all of these topics through our product offering but today we want to talk about the most basic incentive: Bug bounties.

Setting the right size for a bounty program is not a mundane task. A severity classification is used to set the size of the payout which is usually a percentage share of the overall bounty program. But what should be the highest amount that can be paid out? A rule of thumb that generally resonates with the white hat community is that 10% of the saved funds would be a fair share. If you don’t set up your bounty well, you run the risk of even white hats going down the route to hold your assets hostage since they perceive your bounty as being unfairly low.

At Hats Finance everyone can increase the size of the bug bounty for a specific protocol in so-called vaults, and different groups of participants have a clear incentive to do so. Investors and users want to secure their investment and assets locked in the protocol. The DAO and the Dev Team want to make their product safer and protect their reputation. Because everyone can join the security effort by adding liquidity and even benefit from the incentivization¹, the size of a vault can grow way beyond what a traditional bug bounty would offer. So how should this liquidity be used? Hackers want to be rewarded fairly while the community doesn’t want to overpay.

Introducing Smart Bug Bounties

One feature that is currently in the pipeline and we want to discuss with you starting today is smart bug bounties. The committee that is setting up the bounty will get the ability to control the bounty and therefore the incentive for the hackers more precisely.

The first control is on the percentage share the vault should pay out in case a critical vulnerability is reported. If the team starts with bootstrap liquidity of $200K they might choose 80%. Their protocol is now safeguarded with $160K against critical vulnerabilities.

After initiating the vault, the community, investors, and users are incentivized to increase the liquidity of the vault. The main asset the team and other liquidity providers will deposit is the native token of the protocol. It will be a regular case that the price of the token appreciates over time and therefore the value of the bug bounty is increasing with it. Let’s assume that the vault in our example grows over time to hold assets worth $5M. A bounty of $4M might sound excessive to the team.

This is where the second control function of the smart bounty proves to be useful: A setting for the maximum payout in USD terms which acts as a cut-off. When the committee set up the vault they decided that the maximum payout should be $1M. But instead of increasing the payout linearly until the cut-off is reached every payout that is between $160K and $1M in size will be calculated by a curve to have a finer balance between protocol security, hacker incentivization, and liquidity provider risk.

Why a Logarithmic Curve Instead of a Linear Increase With a Cut-off?

The purpose of managing liquidity in a vault is to democratize and decentralize the responsibility of securing a protocol. The first priority is to reach a decent level of security, and the second is to reduce the risk for each participant that provided liquidity in the vault. The curve enables the committee to have a section where hacker incentives grow sharply (Section A), encouraging vulnerability search and disclosure. Once a sufficient bounty size is reached the payout will increase more gradually (Section B) ultimately reducing risk for all participants, therefore, incentivizing additional liquidity.

This curve can be helpful for all types of protocols, as we call a vault in section A in the “growth phase” while a vault in section B in the “maturity phase”.

Section C highlights the reason why we selected a curve over a linear increase. Every additional liquidity added should benefit the hacker, as well as the liquidity providers. With a linear increase, the benefits for liquidity providers only materialize once the cut-off has been reached, leading to some unfavorable risk/return scenarios where liquidity is only rushed into the vault near or beyond the cut-off. Section C shows the risk that is shifted away from liquidity providers compared to the linear payout model and finally, every risk above the cut-off is completely mitigated.

In our previous example, the vault contains total liquidity of $5M. In case of a reported critical vulnerability, the cut-off would now come into effect and every participant is only contributing with 20% of their staked amount. In the to-be-replaced linear model without cut-off, every liquidity provider would need to contribute 80% of their staked amount. The new model, consequently, decreased the risk of every liquidity provider significantly.

Additionally, the curve mechanism is symbiotic with the liquidity mining program since it will keep the risk/reward of vault participation in balance. Although additional liquidity in the vault decreases the earned yield per dollar, it also decreases the overall risk through the payout curve, thus making the curve a great balancing tool. This new mechanism will support reaching the desired levels of liquidity for each bug bounty while rewarding participants taking on the most risk.

Handling Different Severities

To create a fair system, reported vulnerabilities will receive bounties depending on their classified severity. A critical severity that endangers user funds should be treated differently from a small bug that could disturb the service moderately. At Hats, there are four levels of severity for which the payout size has to be defined individually. The previously set maximum percentage payout defines how much in funds will be released for a critical severity. However, the committee must decide how much of the vault should be released for high, medium, and low severities. We recommend the following settings as default.

Based on the selected values for each severity, the original curve will be broken down into four adapted curves, and then used to calculate every reported vulnerability.

Every vault has the option to modify these presets to match the project’s situation, like contract complexity, and TVL.

Once a vulnerability is reported, the severity will be judged on an even more granular scale from one to twenty, making the process more accurate. The numbers are mapped into the four severities that have been previously defined, and the payout is then calculated automatically within those brackets. Each severity (critical, high, medium, low) is broken down into five values each.

The Calculation of The Curve

Different equations were considered to define the payout, and an exponential distribution equation provided the best characteristics to reflect what we wanted to achieve from a game-theoretical perspective. Having a curve that starts with near-linear steepness and then gradually approaches the cut-off value is making it a great fit. The formula was selected to have the highest possible steepness, which mustn’t exceed a slope of one since the vault can’t pay out more assets than it holds at any point in time.

If we ignore the different severities to calculate the curve in a first step and just use the cut-off for a 100% payout we will receive the following curve.

Since the defined cut-off is expected to set the maximum payout for a reported critical vulnerability, the equation has to be modified to consider the percentage reduction in order to calculate the payout for each severity (B).

The variable (A) is defined by the percentage number selected for a vulnerability of critical severity and (B) is defined depending on the severity of the reported vulnerability. If the curve is utilized to calculate the payout of a critical severity then (A) equals (B) but (B) could represent the previously defined values for a low, medium, and high severity likewise.

Final Remarks

By presenting this feature we hope to create a discussion around what a fair bug bounty should look like and gain further certainty that this is the right way to go. We have done heavy internal discussions with the Hats team and other crypto pioneers using the presented formulas, but we look forward to the opinion of the community and their contributions.

Thank you for your attention on behalf of the Hats DAO,

Angler