The Immunefi Standard Badge sets the bar for all projects on the Immunefi platform. When you see the badge icon next to a project’s name on the Explore page or the project’s bug bounty page, you’ll know that the project is reliable, active, and up-to-date with the latest rules and best practices at Immunefi.

While the Immunefi Standard Badge is not a new feature, we’re issuing a significant update to the criteria that projects have to meet in order to receive and maintain the badge.

We rebuilt this Standard to incorporate security researcher feedback about some of the biggest problems and challenges they’ve faced while hunting on Immunefi. We are constantly logging feedback and developing solutions to give security researchers a seamless experience, so they can continue to make web3 safe for everyone.

The Account Management team at Immunefi regularly checks requested changes from projects to see if those changes fulfil the Immunefi Standard criteria — or not. If the criteria are not met, the badge is removed. Conversely, if requested changes from projects meet the Immunefi Standard, then they receive the badge publicly on Immunefi and are congratulated.

These actions help ensure that the badge you’re seeing on a project is fresh.

Note: Some projects received their badges prior to the release of the updated criteria below. These projects will be asked to meet the updated requirements in the near future, but they will keep their legacy badges for now.

In brief format, the new Immunefi Standard criteria are as follows:

Critical Theft of Funds Primacy of Impact Adherence

Projects must have the Primacy of Impact applied for at least the “Direct loss of funds” for Blockchain/DLT bug reports and/or (must be “and” if they have both) “Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield” and “Protocol Insolvency” for Smart Contract bug reports. This further ensures that their bug bounty program truly protects their project from loss of funds.

Impact-Focused Severity Classification System

Projects must have an impact-focused severity classification system in place, as seen in the Impacts in Scope section. Having an impact-focused severity classification system allows for a clear and objective assessment of their program by security researchers as well as simplifies any report validity evaluation that may be necessary. Such a section greatly reduces any ambiguity that security researchers may perceive, as the impacts projects are willing to accept and the impacts they’re not are abundantly clear.

Signed Statement of Work

Projects must have signed the Statement of Work contract. This ensures that the projects have agreed to our operational standards such as SLAs involving responses, thus addressing potential responsiveness concerns. Signing the SOW also indicates an agreement to make the bug bounty program a contract itself, thus further reducing uncertainty with security researchers.

10% Funds at Risk Scaling Reward System for Critical-Level Rewards

If a project has a scaling system for critical-level rewards, then it has to reward at least 10% to satisfy this requirement. We have found through our research that 10% of funds at risk is generally an acceptable additional limitation to a published reward amount. Thus, we have been recommending this as a standard for critical bugs that have a scaling reward system in place.

If a project does not have a scaling reward system based on the funds at risk but rather provides a flat reward no matter how much is stolen, then this criterion is considered inapplicable.

Minimum Critical Reward Amount of USD 50 000 or 25% of Maximum Critical Reward, Whichever is Lower

If a project has a scaling system for critical-level rewards, then it has to reward at least a minimum of USD 50,000 or 25% of the Maximum Reward, whichever is lower. This minimal critical reward guidance is to incentivize security researchers with a reasonable reward to report findings as soon as possible, rather than sitting on them.

If a project does not have a scaling reward system based on the funds at risk but rather provides a flat reward no matter how much is stolen, then this criterion is considered inapplicable, given that the max reward amount is applicable in a valid critical report.

Known Issue Assurance

The project expresses a commitment to disclose known issues publicly and/or privately via a self-reported bug submission if such a bug would be considered in-scope for their bug bounty program.

Inability or failure to do so would result in the bug report being considered valid and due 100% of the reward as per the bug bounty program.

This process simplifies all known-issue-related bug report rejections, as a self-reported bug report would be cited with its respective bug report number. In case a security researcher has doubts, when they call for assistance, Immunefi would be able to verify that it is, indeed, a known issue, and the case would be resolved smoothly.

Having known-issue-related rejections processed in this manner is thus a best practice, especially given that it is already discouraging on its own to find a valid report, only to be turned away from a reward since it was known previously.

Responsible Publication Category 1, 2, or 3

The project has agreed to a Responsible Publication category. By selecting a category, it becomes clear to all parties when and what information whitehats, projects, and Immunefi are allowed to publish about bug reports.

Agrees to the Disclosure of Bug Bounty Program Operations Metrics

The project has agreed to publicly disclose data on its operational metrics. These data points are the total amount paid out (in USD) and the average resolution time. By being transparent about response and resolution times, projects communicate more clearly to security researchers what they can expect when they submit a bug report to their program.

What security researchers can expect

Security researchers can expect projects with the Immunefi Standard badge to adhere to the above criteria for their bug bounty programs. However, as noted above, some projects have been grandfathered into the new Immunefi Standard Badge while still adhering to the legacy criteria. We are rolling out the new requirements to these projects soon, at which point they will have the opportunity to agree to the terms and keep the badge or lose it.

Project violations of the above criteria are a serious matter. If you as a security researcher notice that a project is in breach of the Immunefi Standard, please bring this to our attention in your bug report submission thread or by reaching out to Support.

How to finds projects that follow the Immunefi Standard

The Immunefi Standard badge will appear on the Explore page, as well as a project’s bug bounty page. It will only be given to projects that have met the criteria outlined above.

Explore page example:

Bug bounty page example:

The Immunefi Standard is a powerful tool for projects to show that they take security seriously. The more projects that adopt the Immunefi Standard, the more other projects are motivated to adhere to best practices in a virtuous cycle.

Everyone wins.

See you on the leaderboard.