The Immunefi bug bounty process can be broken down into three steps: confirm the target is in scope, submit a reproducible report, and get paid according to the project's payment requirements. The key judgment criteria for the entire process are not on the Immunefi platform itself, but on each project's own Bug Bounty page—scope, PoC requirements, and KYC conditions are all set by the project. Immunefi only provides escrow and arbitration.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
Scope: Look at the Project Page First, Not the Immunefi Main Site
The Bug Bounty page structure for each project on Immunefi is similar, but the specific content varies greatly. You need to find the target project's page at immunefi.com/bug-bounty//information/ and focus on three sections: Impacts in Scope, Rewards by Threat Level, and KYC requirements.
Scope is usually divided into two dimensions. The asset scope tells you which contract addresses and which websites/applications are testable. The impact scope tells you what kinds of vulnerabilities count. Taking Immunefi's own project as an example, a Critical smart contract vulnerability is defined as "direct loss of funds," while a Critical website/application vulnerability requires "direct loss of funds without any user interaction." This qualification is crucial—many beginners submit vulnerabilities that are "risky but require the user to perform a certain action first," which may only be Medium or even Low in the project's classification.
Primacy of Impact and Primacy of Rules are two different judgment logics. Primacy of Impact means that even if the affected asset is not explicitly listed in scope, the report is still valid as long as the impact falls within the in-scope types. Primacy of Rules strictly follows the terms written on the project page; both the asset and the impact must be explicitly in scope. Most projects use Primacy of Rules, so "I think this vulnerability is serious" does not constitute a valid basis for a report.
PoC is required for all severity levels. Multiple Immunefi project pages explicitly state "Proof of concept is always required for all severities." Without a runnable PoC, the report will not be accepted. The PoC needs to demonstrate actual impact, not a text description or code snippet—Livepeer's page puts it bluntly: "Explanations and statements are not accepted as PoC and code is required."
Reporting: What to Write and How to Submit
The submission entry point is on the Immunefi platform. You need to register an account first, then click submit on the target project's page. The report itself needs to include several elements: the affected asset (contract address or URL), vulnerability type, reproduction steps, PoC, and an explanation of the impact.
The severity level is determined by the project, not by you. Immunefi's severity classification system divides vulnerabilities into five levels: Critical, High, Medium, Low, and None. You can mark your estimated level when submitting, but the final classification authority lies with the project. If you feel the project downgraded a Critical to Medium, Immunefi has a "Lowering Severity" appeal path in its process, but this is not a mechanism that guarantees a reversal.
Duplicate submissions and known issues are not paid. If the vulnerability has already been disclosed in the project's audit report, or if someone else has already submitted it first, your report will not be rewarded. Immunefi's own project page explicitly lists known issues with Gnosis Safe, and any reports about these issues are not eligible.
After submission, the report enters the triage process. The project will first confirm receipt, then evaluate whether it is in scope and how severe it is. There is no fixed time commitment for this process. When answering questions from projects, Immunefi said they do not provide incident response help and do not guarantee intervention if a project is attacked. This means that after you submit a report, if the project does not respond for a long time, you have no mandatory timeline to rely on.
Payment: KYC Is Chosen by the Project, Not Uniformly Required by Immunefi
This is the easiest place to stumble. Of the 153 projects on Immunefi, only 68 are KYC-free; the rest require identity verification before payment. KYC requirements are written on each project's page but are not aggregated on Immunefi's main site. You need to click into each project page to confirm.
The KYC process is carried out by Immunefi on behalf of the project. If the project requires KYC, the white hat will receive a message in the report thread with a link to upload documents. Standard materials include: a valid passport or ID card, and proof of address (usually a utility bill). Plume Network's Attackathon page further states that researchers need to submit KYC within 14 days of the request, otherwise the reward may be forfeited.
Payment currency and network are determined by the project. Livepeer pays in USDC on Ethereum, Mt Pelerin supports ETH, BTC, USDT, USDC, and DAI on Avalanche, Arbitrum, and Base, and Pareto Credit pays in USDC for amounts below $10,000 and in IDLE for the excess. You should confirm the payment method on the project page before submitting a report, rather than waiting until the bounty is approved to find out you cannot receive it.
KYC-free projects do exist, but you need gas for the PoC. A researcher analyzed the full list of Immunefi projects and found that 68 projects with kyc: false can send USDC directly to your wallet. But these projects also require a mainnet fork PoC, meaning you need to spend gas to set up the test environment. Zero KYC does not mean zero cost.
Dispute resolution goes through arbitration. If you and the project cannot agree on severity or payment amount, Immunefi will first attempt mediation. If mediation fails, the dispute will be submitted to the London Chamber of Arbitration and Mediation under its blockchain arbitration rules. The cost and timeline of this path are not low for individual researchers, and in practice most disputes end at the mediation stage.
Disclosure: Do Not Make It Public Before the Fix
Immunefi's Responsible Publication Guide divides disclosure conditions into several categories, depending on whether the project has fixed the issue, whether the report has been closed, and the disclosure category set by the project.
The core rule is: unfixed vulnerabilities cannot be discussed in public channels. Cosmos's documentation states clearly: "Public disclosure of vulnerabilities is prohibited until Cosmos Labs has remediated the issue and explicitly authorized disclosure." This is not only Immunefi's platform rule but also part of most projects' security policies.
What you can disclose after the fix depends on the project's Category. Category 1 and Category 2 have different rules, and Category 3 requires explicit project permission to disclose the payout amount and project name. If you disclose details before the fix, Immunefi can suspend or permanently ban your account and cancel your right to receive payment.
Completion Criteria
The point at which an Immunefi bug bounty is considered "complete" is when the project confirms the vulnerability is valid, completes the fix, and the payment arrives. Report submission, passing triage, and severity confirmation are only intermediate states. If the project decides not to fix the vulnerability you reported, Immunefi's rule is that the project has no payment obligation unless the vulnerability is in scope and the project actually made a fix based on the report. The fix is a prerequisite for payment, and this causal relationship needs to be taken into account when choosing your target project.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
References
- Immunefi·Immunefi Official Bug Bounty Program Information Page, page publication or update date: not indicated on the page; verification date: 2024-10-28.
- Immunefi·Leather Project Bug Bounty Information Page, page publication or update date: not indicated on the page; verification date: 2024-10-28.
- Immunefi·Livepeer Project Bug Bounty Information Page, page publication or update date: not indicated on the page; verification date: 2024-10-28.
- Immunefi·Pareto Project Bug Bounty Rewards Rules Page, page publication or update date: not indicated on the page; verification date: 2024-10-28.
- Immunefi·Mt Pelerin Project Bug Bounty Information Page, page publication or update date: not indicated on the page; verification date: 2024-10-28.
- Immunefi·Vulnerability Severity Classification Update Explanation Page, page publication or update date: not indicated on the page; verification date: 2024-10-28.
- Immunefi Support Center·White Hat Researcher Collaboration FAQ Page, page publication or update date: not indicated on the page; verification date: 2024-10-28.
- The Colony·Immunefi Project KYC Analysis Post, page publication or update date: not indicated on the page; verification date: 2024-10-28.
- Immunefi·Plume Network Attackathon Event Resources Page, page publication or update date: not indicated on the page; verification date: 2024-10-28.
- Immunefi·Safe Harbor Rules Explanation Page, page publication or update date: not indicated on the page; verification date: 2024-10-28.
- Immunefi·Responsible Disclosure Guide Page, page publication or update date: not indicated on the page; verification date: 2024-10-28.
- Cosmos Official Documentation·Bug Bounty Rules Page, page publication or update date: not indicated on the page; verification date: 2024-10-28.
