It’s an eternally frustrating experience for whitehats to find a bug in a project on Immunefi with a real, in-scope impact, only for them to find that it’s out-of-scope because the asset isn’t listed in the bug bounty program.

The project then fixes the bug, which may save user or protocol funds, and then says they don’t have to pay the whitehat anything because the asset is technically out-of-scope, according to their bug bounty program rules.

This isn’t an especially common experience, but it has happened before.

It seems unfair, and whitehats aren’t sure how to even approach the situation. Should they withhold vulnerabilities in the future? Should they ask Immunefi to ask the project to list the asset in the Assets in Scope table before they submit a bug report, perhaps in case the project just forgot to add it? Should whitehats submit the bug report anyway and hope that the project will treat them fairly and reasonably, rather than taking advantage of their good faith disclosure efforts?

To solve this problem, we’re introducing a new best practice standard for projects called Primacy of Impact, which they can choose to implement in their bug bounty programs.

What is Primacy of Impact and where is it?

If a project displays on their bug bounty program in the Program Overview section that they subscribe to Primacy of Impact, they are publicly stating that if they receive a bug report with a real, in-scope impact, they will treat the report as in-scope, despite the fact that the asset might technically be out-of-scope.

They will then process the bug report like any other in-scope report and issue a bounty reward based on the appropriate severity level and extent of impact.

Primacy of Impact is beginning to be rolled out to new projects, so keep an eye out for it. As mentioned, if a project subscribes to Primacy of Impact, it will appear in their bug bounty program’s Program Overview section. Some projects have this in their Rewards by Threat Level section, but those are gradually being moved to the Program Overview section.

How does Primacy of Impact work?

It’s important to note what Primacy of Impact means and what it doesn’t mean.

• If an in-scope impact affects an out-of-scope asset, then Primacy of Impact applies. The whitehat will be rewarded based on the severity and level of real impact.
• However, Primacy of Impact does not apply for out-of-scope impacts. If you look at a project’s bug bounty program and discover that your impact is not listed in the impacts in-scope table, then Primacy of Impact does not apply. In that case, if you still submitted that bug, it would be entirely up to the project whether they want to give you a goodwill payment or not.
• Primacy of Impact also does not mean that theoretical impacts that do not currently pose a risk are in-scope.
• Primacy of Impact may only apply to a certain severity level and/or a certain category. For example, some projects may only apply Primacy of Impact to smart contracts, rather than Web/App. Always make sure to carefully read the project’s bug bounty program page!

Why projects have Primacy of Impact

Projects choose to have Primacy of Impact because creating and maintaining bug bounty programs can be a complicated process, especially when it comes to the Assets in Scope table. Sometimes, projects forget to add new assets to the table as they roll them out in production. Other times, projects forget to add certain assets from the start! But they still want to ensure that whitehats are incentivized to protect them from real threats, even if the asset doesn’t happen to be listed on their bug bounty program page.

Projects ultimately don’t want the rules of their own bug bounty program to contradict the primary objective of protecting at-risk funds and product integrity. What Primacy of Impact states is that real impact is more important than the list of in-scope assets.

Primacy of Impact is an impact-first approach, as opposed to a rules-first approach, which unlocks the creativity of whitehats to find especially novel bugs with in-scope impacts.

Why Primacy of Impact projects still have an Assets in Scope table

Some whitehats might ask: if a project subscribes to Primacy of Impact, then why would they need an Assets in Scope table at all?

An Assets in Scope table is still a must-have for all bug bounty programs on Immunefi.

First, it makes things much easier for whitehats who are trying to hunt. Nobody wants to waste time digging around for project assets. It’s better for everyone for projects to list their assets in one convenient spot on their bug bounty program, even if they happen to forget to add one of their assets to the table.

Primacy of Impact is not a substitute for projects having to list assets on their bug bounty program.

Second, sometimes Primacy of Impact doesn’t affect all impacts and categories. For example, some projects will only have Primacy of Impact applied to critical severity reports. Sometimes, they’ll be more specific and apply Primacy of Impact only to critical smart contract reports.

We’re constantly improving our features and policies to give whitehats the best experience possible on Immunefi.

Primacy of Impact is the latest example, but we have many more to come. Stay tuned, and see you on the leaderboard.