Bug Bounty Programs
What is an impact and how does it work?
An impact is the damage that a vulnerability could cause a project (e.g. X amount of funds could be stolen through Y vulnerability). To be eligible for a reward, the vulnerability must be something that could cause damage now rather than at some point in the future.
If the report can’t identify an impact from the bug bounty program, then it is not eligible for a reward.
When a program lists a website in scope, are other directories in scope? And subdomains?
All the directories will be included (site.com/something) but not the subdomains (something.site.com) by default, unless the program specifies otherwise.
Are rewards required to be delivered as outlined in the project Bug Bounty program?
All bug reports should be assessed and rewarded based on the scope of the BBP at the time of the report's submission.
The project's bug bounty program says they have a primacy of rules policy. What does that mean?
We encourage projects to abide by a primacy of impact policy. Projects that have this policy will still reward you if you submit a report that identifies an in scope impact with an out of scope asset.
However, if the project specifically lists a primacy of rules policy, that means that your report will be judged strictly against the word of the BBP and you will not be rewarded in the scenario outlined above,
What is the best way for me to navigate a bug bounty program page? How do I find the information that I am looking for?
The easiest way to find specific information on a bug bounty program page is to use the tabs located below the header. There are three tabs to choose from: Information, Scope, and Resources.
- Information-
- When you select this tab, you will be presented with a general overview of the program and its rules. This includes information regarding vaults, rewards, audits, known issues, KYC, eligibility criteria, PoC, responsible publication policy, prohibited activities, and feasibility limitations.
- Scope-
- This section shows which assets/impacts are in scope and out of scope for Blockchain/DLT, Smart Contract, or Web & App depending on the category selected. To change the category, simply click the appropriate tab on the top of the page.
- You can see whether the program follows a primacy of impact or a primacy of rules policy next to the title of the ‘impacts in scope’ section. If the program uses a mixed primacy policy, you can see the policy for specific impacts by placing your mouse over the ‘Pol’ label next to the reward for that impact.
- Resources-
- Clicking this tab will present information regarding the codebase and documentation.
Report Submissions
The project is being slow responding to my bug report. What are their required response times / SLAs?
When projects join Immunefi, they sign an Operational Agreement with Service Level Agreements (SLAs) which governs receipt, decision, and payout times. If a project breaches any of the time frames below, please see the following article on how to request help from Immunefi.
| Action | Severity Level | Response Time |
|---|---|---|
| Acknowledgement of report | Critical | 48 hours |
| All severity levels except critical | 3-4 days, depending on holidays/weekends | |
| Decision on report | High + Critical | Up to 14 days |
| Low + Medium | Up to 7 days | |
| Payout for valid reports | High + Critical | Within 14 days |
| Low + Medium | Within 7 days |
When I try to submit a bug report, the dashboard tells me to try again in 48 hours. Why?
Immunefi ratelimits all bug reports to encourage whitehats to focus on submitting the highest quality reports.
Whitehats are currently allowed to submit a maximum of 5 reports per 48-hour period. Once you’ve submitted 5 reports, you will have to wait 48 hours to submit more.
What if I find a vulnerability across multiple assets of the same project? Of different projects?
Although a vulnerability can exist across multiple assets, keep in mind only the first instance of each cited is eligible for a bounty reward. You can follow the guideline of: one bug, one patch, one payout.
If the same vulnerability is found in different project's assets, please file a new report for each.
I think I’ve found a vulnerability, but I’m not sure. Can I share it with someone?
Do not share it on a public channel. You can share it privately to another whitehat you trust, but you will held responsible if the vulnerability is leaked and exploited.
If you consult with another whitehat, it’s your responsibility to figure out how to split any bounty. Immunefi and the project will not mediate in any dispute.
Can I reserve a place as first reporter by submitting a report that is not yet fully complete?
No. Keeping a bug report open does not secure a "spot" as the first reporter, as only the first complete report escalated is what is considered to be the first one. You are welcome to resubmit when you are ready to have a fully completed report escalated to the project.
Can I contact the project directly about a bug that I find?
No. In fact, doing so is against the rules and could result in a warning or a ban. Contacting a project directly is a rules violation because projects host their bug bounties on Immunefi specifically so that all communication is handled through our secure platform.
Additionally, contacting a project before submitting to Immunefi is also considered a violation and will result in no payout.
Can I edit a bug report after I have submitted it?
Am I allowed to report an identical vulnerability to multiple projects when they are all susceptible to the same bug?
Yes, you are allowed to report the same vulnerability to different projects when they are each independently affected by the bug. On Immunefi, each vulnerability is assessed individually, which means that even if you report the same bug to multiple projects, each report is treated as a unique discovery for the respective project.
You are welcome to submit these reports to as many projects as it is relevant to. None of our policies will prevent you from doing so, and projects can't reject your report on the grounds that the vulnerability has been reported elsewhere. Each valid report, provided it is applicable to the specific project, will be assessed independently and could potentially earn a bounty.
Report Mediations and Resolutions
Can I change the bug’s severity level after I report it?
If the report status is in Reported or Needs more information, the whitehat can ask Immunefi to change the severity level. After escalation, it needs to be discussed with and agreed upon by the project.
- the bug is a duplicate
- the bug is a known issue to the project, and the project can supply appropriate proof
- the bug is a non-security issue (e.g. low-level UI bug), so even if fixed does not require payout
- the project decides not to fix the bug
When can I go public with my find? I'm interested in publishing information regarding my report.
That depends on which Responsible Publication category the bug bounty program subscribes to. You can find that information in the Program Overview section of the program you submitted your bug report to. If there is no information there, it means that project has not yet subscribed to the Responsible Publication policy and is under the Legacy Publication policy.
You can read more information about what you can publish about your bug reports on the Responsible Publication page.
If you are ever unsure about your publication rights, please feel free to ask Immunefi in your bug report.
Can I re-open my report after it's been closed?
Only Immunefi and the Project can re-open your report. If you believe your report has been closed in error, please Request Help from Immunefi.
The project closed or downgraded the severity of my report and are claiming they requested an update to their bug bounty program prior to my submission. The change they are claiming was not published on their program page at the time of my submission. What happens now?
If a project logs a bug bounty program change request with Immunefi and a new bug report is submitted after, it will be reviewed against the updated version of the program, although it might not yet be publicly published. If there are any doubts, please reach out to Immunefi to verify the timeline of events.
How do I troubleshoot if I get an error message saying "This resource is secured against CSRF" when trying to send a message in a bug report submission?
This is an intended security mechanism and can be cleared by reloading/refreshing the page. If this does not work, try to log out of your Immunefi account and log back in.
What is a duplicate report?
A report is a duplicate when it showcases the same vulnerability as another report that has already been submitted to the project on the Immunefi platform. Only the first report to identify a vulnerability is paid a reward.
For example; if Report 11894 and Report 12001 both detail the same re-entrancy vulnerability but Report 11894 was submitted first, then Report 12001 is a duplicate and is not eligible for reward.
See our Duplicate Reports article for more information.
What counts as a known issue?
A known issue is a vulnerability that a project can prove was already known to them before it was identified in a bug report. Projects can prove that a vulnerability is known by providing a github issue, formal documentation, or by self-reporting it on Immunefi (which then makes any subsequent reports documenting the same vulnerability into duplicate reports).
See our Report Closed for Known Issues article for more information.
Bug bounty programs usually exclude findings from previous audits. What if I can bypass the “fix” for one of those issues. Is my report valid?
Report Payments
I'm working with another hacker on a bug. When we submit our bug, how do we handle splitting bounties?
Currently, splitting is a manual process. The bounty payment is sent to one address, and the whitehats can decide how to split it from there.
What happens if I do not confirm my wallet address after my report is confirmed and the project wants to pay?
The project will keep your report open for 30 days after requesting for you to confirm your wallet address. If you do not respond within this timeframe, the report will be closed due to lack of communication. However, if there are extenuating circumstances that led to your lack of response, please share them in the report thread along with your wallet address. The report may still be eligible for payment (we will review these on a case by case basis).
What happens if projects decide not to pay?
Bug bounties are very new in the Web3 space, so projects are still learning how to run successful and ethical bug bounty programs. Rarely, a project will decide not to pay. We will do everything we can to encourage projects to act ethically and responsibly, but if a project is generally non-responsive, we will remove them from our platform.
How do payouts work, and are they done only in crypto?
Projects only make payouts in crypto. Each project’s bug bounty program page on Immunefi specifies exactly what the payout terms are. Sometimes, the payouts are done in stablecoins like USDC (1 USDC is equivalent to one U.S. dollar). Other times, payouts are made in that project’s native token. Occasionally, it’s a mix of both, or BTC/ETH.
Once a project confirms the vulnerability you have reported and updated status to `Confirmed`, they will then reconfirm with you the severity level and reward payout amount as well as the wallet address to which they should send the bounty payout. The transaction is directly between you and the project, so do confirm all details are correct before they issue it. At any time you can reach out to request mediation assistance.
Why are some bounty rewards offered as vested tokens instead of non-vested tokens?
Not many projects offer bounty rewards as vested tokens, which are released to the whitehat on a set schedule.
However, some projects do pay rewards in vested tokens. Immunefi initially did not allow vested tokens, and the initial policy still holds for Immunefi’s fee, but projects and whitehats requested that vested tokens be allowed, so that some projects could offer much larger bounty rewards. The point of this policy change was to allow whitehats to hunt on whichever bug bounty programs suits their requirements the most.
How do I create a wallet to receive payments for my bug finds?
We require that hackers use a wallet that is an externally owned account (EOA) to receive payment. We don't require that hackers use any particular wallet software, so long as the hacker is able to submit transactions and make signatures from that address.
Important: smart contract wallets are not supported. Centralized exchange (CEX) wallets are not supported. If you submit a smart contract or CEX wallet on the submission form, you're at your own risk. If your bounty payment goes into a black hole, we cannot retrieve it for you.
For non-EVM projects, it’s ok to enter all zeroes as the wallet address and then put the actual wallet address in the bug report.
How do I change my wallet address in a submitted bug report?
If the project decides that the bug is valid and they advance the report to the 'Confirmed' status, you will be asked to confirm your wallet address. You can use this opportunity to change it to the correct address.
Do I get to decide what type of token I am paid with?
No, projects get to determine the payout terms. With that said, we do have a liquidity requirement for payouts in project tokens.
In order to determine whether or not a project's native token meets our liquidity requirement, check the 30 day average of 24hr trading volumes on CoinGecko. If the maximum bounty on the project's bug bounty program is less than 5 times the 30 day average of 24hr trading volumes, then the token has sufficient liquidity and can be used to pay the reward.
If the project's token does not meet the requirement, then you can require the project to pay in stablecoin or another more liquid asset. You are responsible for ensuring that the project token meets the liquidity requirement BEFORE accepting payment.
If you see that a project's bug bounty program lists reward payments in a project token that does not meet our liquidity requirement, please report it using this form.
Can I publish a bugfix review after receiving a goodwill payment?
That will depend on the publication category that the project has selected.
For more information on our publication policy, please see our Responsible Publication article.
Comments
0 comments
Article is closed for comments.