The Bug Bounty Program Is Law

Bug bounty program pages are something we take incredibly seriously at Immunefi.

We painstakingly designed the bounty program page's basic format to revolutionize web3 security and the bug bounty industry. This format has directly led to the biggest bug bounty payouts ever seen, such as the $10m payout from Wormhole, and the $6m payout from Aurora as just two examples.

One of the reasons we’ve been able to facilitate such large payouts is because we’ve held to the idea that the bug bounty program is law.

This means that the terms of the bug bounty program are the central factor in determining what is in-scope, what is out of scope, how impact is defined, and what the payout amount should be, given the severity level.

All of this information is explicitly defined in advance on the bounty program page to prevent arbitrariness, uncertainty, and unfairness. As such, projects are strictly prohibited from trying to negotiate to change the commitments established in their bug bounty program page and have it affect a bug report retroactively.

For example, if a bug report has a severity level of critical and the program states that the minimum payout for critical bugs is $50,000, then projects are strictly prohibited from trying to negotiate with security researchers to lower the payout. If they try, security researchers are fully within their rights to respectfully push back by citing text from the program page.

The same goes for a bug report with a severity level of medium. If the severity level is indeed assessed at medium, then projects must pay the exact amount listed for medium, as stated on their bug bounty program. They are prohibited from paying a lower amount.

If the project is unwilling to follow the terms of their program page, security researchers can also click the ‘Request Help’ button in their report. Immunefi mediators will then provide an objective, impartial analysis of the report and provide a conclusion by assessing the bug report against the program text.

When projects onboard on Immunefi, they participate in the construction of the bounty page and are fully aware of every commitment they’re making to security researchers who submit bug reports.

If projects refuse to abide by their commitments, they will be removed from the Immunefi platform, unless there are very rare and exceptional circumstances at play.

Conversely, this means that security researchers are also bound by the terms of the bug bounty program. A security researcher cannot create their own impact calculation and substitute it for the calculation that is stated in the bounty program.

So, if potential PR damage from an exploit is listed as part of the impact calculation but the text also states that taking into account PR damage is fully at the project’s discretion, a security researcher cannot simply and arbitrarily calculate that the PR damage for his bug report, if exploited in the wild, would be $100m and demand that the project pay a max critical bounty. It doesn’t work that way. That kind of calculation isn’t present in the program text.

First, in this hypothetical case, whether PR damage is involved in the impact calculation is at the discretion of the project. It’s crucial to remember that the project has the final say over how much more they reward over the amount determined by the direct financial damage the bug poses.

Second, the calculation used to assess PR damage is up to the project.

Let’s discuss another example that might be a bit more unintuitive. A security researcher finds a critical bug in a smart contract for project X. While the impact is in-scope for project X’s program, the particular smart contract is not listed in the Assets in Scope table.

If the program is rules-based, then this would be an out of scope bug report. However, if the Program Overview section states that Primacy of Impact applies, then the bug report would be in-scope.

In all cases, it’s important for both the security researcher and the project to operate in good faith and to be respectful, even if they believe the other side to be unreasonable. We require that as part of our rules.

By understanding and following the guidelines set out by the program, security researchers can increase their chances of receiving a reward for their efforts while also boosting their reputation within the web3 security community.