Processing Bug Reports and Reward Payouts Overview – Immunefi

Welcome to the Immunefi Bug Bounty platform! This article provides a brief overview of how to process bug reports and reward payouts. There are also links to further reading in each section if you have additional questions that are not answered here.

Using the Dashboard

Before you try your hand at processing a bug report, we recommend that you watch the Immunefi Dashboard Basics video.

Escalations and Self Triaging	All bug reports will be escalated to you for review and self triaging (except spam). Immunefi will automatically recognize spam and not escalate it to you, unless you choose to turn off the automated filtering feature. You can see all the submissions marked as spam and decide if it is worth re-evaluating them.
Communications With the Whitehat & Asking Immunefi for Help	Projects & Whitehats discuss bug reports directly using the Immunefi dashboard. Immunefi can help when mediation is requested by the Project or the Whitehat. It is expected from all parties to maintain communication on the dashboard at all times.
Advancing Dashboard Statuses	Projects use Quick Action tools to advance bug statuses forward to resolution.
Changing Dashboard Severity Levels	Projects can lower or raise severity levels independently by providing a valid reason to the whitehat, who has to agree or disagree with the project assessment. Note that a whitehat can request Immunefi to review in case they feel a submission is being improperly assessed by the project.
Issuing Payments to Whitehat and Immunefi	To confirm payouts and provide transparency as well as trust, projects must provide transaction IDs directly in the dashboard upon payment.
Re-opening Bug Reports	Projects can request Immunefi to re-open bug reports if they have been closed incorrectly.

Self Triaging

Immunefi will run all bug reports through our automated filtering process to prevent obvious spam from reaching your inbox. Reports that make it through this process will be escalated to you for self triaging. This means that your team will need to review the report to determine whether or not it is valid or invalid.

If you would like to turn off automated filtering and personally review all new submissions, you are free to do so. You can read more about activating/deactivating automated filtering here.

For more information on self triaging bug reports, you can read the Self Triaging section of our Help Center.

What do I do if...	Action
The bug report is valid.	Use Quick Actions to advance the status of the report.
The bug report is invalid.	Reply to the whitehat with a rationale that explains why the report is invalid. Mark the report as “Closed.”
There is not enough information for me to determine whether or not the report is valid or invalid.	Reply to the whitehat with your questions. Once the whitehat responds, you can use the information to determine whether or not the report is valid.

Advancing Report Statuses

We’ve created a Quick Action feature to make advancing the status of bug reports easier and more efficient. When you select a Quick action, template text will be auto-populated for you in the 'Custom Reply' field and the status of the report will be updated (if applicable). This will allow you to quickly and effectively communicate with whitehats and advance reports through review stages until they are brought to resolution - either in a Closed or Paid status.

You can read more about Quick Actions here.

Changing Report Severity Levels

At Immunefi, we use a vulnerability classification system based primarily on a vulnerability’s impact and likelihood of exploitation. You can find a more detailed explanation of our severity classification system here.

If you disagree with the severity of a bug report, you have the power to lower or raise the severity level by providing a valid reasoning to the whitehat. If the whitehat agrees, then the severity level can be changed. If not, the whitehat may request mediation from Immunefi to resolve the issue.

It may be acceptable to change the severity level in the following instances:

Uncommon or incorrect action must be taken by the victim
Uncommon or incorrect action must be taken by an user with escalated privileges
Attacker needs escalated/admin privileges
Attacker needs key compromise
No funds at risk
Attack requires repeated interaction over a long period of time (project may notice)
Attack requires adjacent network access or MITM network access
Attack requires physical access to the victim's computer
Attack requires brute-force complexity of over 40 bits

You can read more about changing severity levels here.

Requesting Mediation from Immunefi

While we hope that projects and whitehats can work together to resolve reports, we understand that sometimes a neutral third party is necessary to settle disagreements. In the event that you cannot resolve an issue together, align on impact, severity and/or reward level, or in the event a whitehat becomes threatening or is breaking a rule of the Immunefi platform, you may add an Immunefi mediator for help.

If Immunefi *is not* subscribed to the bug report…	Click the “Request Help” button at the bottom right of your submission page and select one of the reasons provided on the list.
If Immunefi is subscribed to the bug report…	Reach out to us using the “Comments” section by replying to “[Your Project Name] and Immunefi” and explaining why you are requesting mediation.

For more information on how to request help from Immunefi, you can read the “How & When to Request Help” article here.

Resolving Reports

Bug reports are considered resolved when they are either rejected as invalid (marked with the Closed status), or paid out by the project (marked with the Paid status). Note that the report cannot be considered Paid until both the whitehat bounty and the Immunefi fee are paid.

Reports can also be resolved when the Service Level Agreement (SLA) is not tied to fixing the bug, so the project either closes or pays within the SLA timeframe.

Issuing Payments to Whitehats

Payments are sent directly from projects to whitehats. The wallet address of the whitehat, shared at the time of submission of the bug report, will be displayed on the right side panel of the bug report itself.

Always confirm with the whitehat their wallet address before sending any payment. When advancing from Confirmed to Paid status, a template will auto populate for you and prompt you to reconfirm the whitehat's wallet address.

Some projects choose to make KYC (know-your-customer) info a requirement for whitehats who hunt on their bug bounty programs. If you choose to do this, know that we do not conduct any KYC verification on our platform. All KYC verification is strictly between you and the whitehat.

If a whitehat submits a valid report but is banned before payment, the whitehat becomes ineligible for a reward. Nevertheless, the standard 10% Immunefi fee will still need to be paid.

You can read more about issuing payments to whitehats here.

Issuing Payments to Immunefi

The final stage of a Paid report is to issue the Immunefi 10% fee.

The 10% fee is calculated based on the amount sent to the Whitehat in the currency/coin used to pay them; the actual amount sent and not the outstanding rate at the time the transaction to Immunefi is sent.

Once you submit payment to the whitehat and mark the submission as status 'Paid', you will be sent instructions to pay the Immunefi fee.

In instances where a report is confirmed, but the whitehat is banned before payment, you will not be required to pay the reward, but you will still need to pay the Immunefi fee.

You can read more about issuing payments to Immunefi here.

Re-opening Closed Reports

If you believe that a report has been incorrectly closed, it is possible to re-open the report. To do so, you simply need to click the ‘Re-open report’ button at the bottom of the report page on a closed report.

You can read more about re-opening closed reports here.