Onboarding FAQs

Is there any up front fee to be a part of Immunefi? How much do we have to pay to launch on your platform? 

There is no onboarding fee, and there are no ongoing maintenance fees. You pay us only when you validate an escalated vulnerability and pay out the whitehat their bounty reward. The fee payment is an additional 10% on top of the reward paid out to the whitehat. Please see our related Help Center article on Immunefi Fee Payout and Issuing Payouts.

I am a new client. When should I begin receiving bug reports?

There may have been some bug reports sent already, but that were caught by our automated filtering and so have not been escalated to you as they were considered as spam. You will only see relevant, escalated bugs in the bug disclosure dashboard. See our Self Triaging Overview for more information.

Am I able to change my username after creating my account?

Yes. To change your username, simply log into the Immunefi bugs platform, navigate to the user settings page, and click the ‘change username’ button.

After I launch, when should I expect to receive bug reports?

It’s normal for bug bounty programs to not receive bug reports immediately, though the first few weeks do tend to be the period with decent bug report activity, so please continue to be ready and ensure your technical team is on standby. However, as bug bounty programs are also designed to protect against long tail cybersecurity risk, it’s normal for bug reports to come in months after launch, as has been the case with some of our clients.

I didn't receive the verification email when trying to create my account. How do I have it re-sent?

Verification reminder banner and re-send verification email link visible in the below video.

How should we determine the bug bounty reward amount?

We usually recommend having the maximum critical reward set at 5-10% of the total funds-at-risk for your project. Based on our experience, this is the amount needed to incentivise a blackhat hacker to report a vulnerability instead of exploiting it.

 

We do understand that this is hard to meet for many projects, so the idea would be to get as close to that as would be practical for your project. For larger bounties, we can scale the critical bounty rewards based on the funds-at-risk of the reported exploit, so the team won’t necessarily have to pay out the max critical reward for just any critical bug report.

What's the total budget that should be set aside for the program?

We recommend setting aside a total budget that is 2-3 times your max critical payout. This should be enough in case your project receives a large number of valid bug reports within a short span of time.

What happens if I have an ongoing/upcoming audit?

We would advise against having an ongoing audit alongside a live bug bounty program in order to reduce the number of duplicate reports that the team would have to pay out for. It would be best to wait for the audit to be completed and the audit report to be published publicly before starting with a bug bounty program.

 

Audit reports are usually included in our bug bounty programs to let security researchers know that any issues previously highlighted in those audit reports are considered out of scope of the program and to help them understand where and how the codebase has already been hardened.

My contracts are already similar-match verified and the source code is viewable. Why do I need to have it exact-match verified?

Exact matched verification takes into account things like constructor arguments, which could be relevant to bug bounty hunters looking for vulnerabilities. However, there are some cases, especially for testnets, where exact-match verification is not possible for certain contracts. If that is the case, let us know and we’ll check with our team for you.

Does all code need to be open-sourced/publicly viewable?

Yes for all smart contract/blockchain assets.

 

At the very least, this is done via exact-match verification of deployed addresses on the various block explorers. For cases where verification is not available on the block explorer (e.g. Solana), we do require the source code to be public on Github/Bitbucket etc.

 

For projects that want to enforce a PoC requirement for bug reports, we also require the Github repo to be opened. This would allow security researchers to more easily set up their test environments for PoC testing.

 

Web/App assets do not need to be open-sourced/publicly viewable.

Should I have a PoC requirement for my program?

The risk of not having PoC is that you get reports that are wrong for some subtle reason that the hacker wasn’t able to fully comprehend. Requiring PoC removes almost all doubt about the technical correctness of a report. Of course, coinciding with this increase in false positive rate is a decrease in the false negative rate.

 

By not requiring a PoC, you are reducing the barrier to entry for hackers and consequently may receive a larger volume of reports with reduced latency.

Who decides on the severity of the bug reports?

During the drafting process, you will be able to decide what impacts fall under the scope of your program, and what severity they would be classified as. However, once the program is launched, we would expect both projects and security researchers to follow that classification for the bug bounty program.

 

We have a default severity classification here that we have compiled based on our experience with handling bug reports in the space. You are free to modify this if needed, but we highly recommend at least using our default as a reference and then making the required edits from there.

How does the bug report filtering work?

Our team helps to filter out bug reports by verifying the whitehat’s claims against the bug bounty program rules. We do not, however, check to see if a whitehat's claims are factually correct. This is the responsibility of the project.

We also filter reports that do not contain sufficient information. All bug reports get filtered and are either closed, or escalated to your team.

Your team will have access to both closed and escalated reports. Your team will be immediately notified about escalated reports by email. You can also set up PagerDuty integration by following the steps listed here.

In contrast, your team will not be immediately notified about closed reports. Instead, you will receive a weekly digest with a list of all the closed reports, and you will be able to access the closed reports at any time.

Do note that escalated reports mean that they have passed through our filtering process, but it does not mean that the bug report is valid. Your team is in charge of validating the bug reports yourselves. 

It is also important to note that the automated filtering service provided by our team does not check if the whitehat’s claims are factually correct, assess the submission severity, or analyze the PoC to understand the validity.