When looking for crypto bounties, no program towers higher than Immunefi bug bounty. It comes with not only the highest paying opportunities, but also stands as the least forgiving of them all. Over its 7 years of existence, Immunefi claims to have facilitated over $180 million in total bounty payments by over 300 protocols. Yet, its strict enforcement of rules means that even a single miniature misstep could cost a beginner their account and every open report attached to it.
Key Takeaways
- Immunefi lists more than $162 million in available bounties and has paid out record sums, including $10 million for a single Wormhole finding.
- Immunefi does not pay you: the project pays you directly, and Immunefi charges the project a separate 10% fee on top.
- If you are banned before payment, the project owes you nothing for a valid report but still owes Immunefi its fee.
- Testing against mainnet or public testnet is grounds for immediate permanent ban; all proof of concept work must run on a local fork.
- Token-denominated payouts are often converted at the submission date rate, so a long triage delay transfers all the price risk onto you.
This guide covers how the platform pays, how to submit a report that survives triage, the rules that get accounts banned, how to screen a program before committing time, and the payout terms that quietly decide what you actually take home.
What an Immunefi Bug Bounty Actually Pays
As of 2026, Immunefi stands as the biggest bug bounty marketplace in the Web3 space based on every available metric. In the web page, Immunefi advertises over $162 million in available bounties across active programs, and the historical payouts are genuinely extraordinary.
For instance, $10 million was paid to a researcher known as satya0x for a critical Wormhole bridge finding, and $6 million to owning.eth for a bug in Aurora. These are self-reported platform figures, but the largest payouts are independently documented.
The ever increasing threats on digital finance networks is enough justification of why projects will spend tens of millions in assessing bugs. In fact, the latest numbers in 2025 indicate that crypto thefts exceeded $3.4 billion in 2025. The ceiling is high because the assets are enormous.
Notice: Immunefi is not the payer in these programs. Rather, the project sponsoring the programs pays the participants directly. Then, Immunefi separately charges the project a 10% fee based on the bugs found via the community. This is totally different from other platforms like Hackenproof that charge their fee from the researcher’s side. It also means the platform can facilitate a dispute but cannot make anyone pay you.
How to Submit a Report That Survives Triage
One of the biggest hurdles for researchers is the Proof of Concept (PoC). It’s exactly here where most first submissions fail. For smart contract vulnerabilities, Immunefi generally requires runnable code that demonstrates the impact without exploiting anything live, built by forking mainnet state with Hardhat or Foundry. The objective is to prove the vulnerability and its impact without interacting with live deployments.
However, screenshots and screen recordings are not sufficient evidence for smart contract reports, although they remain valid for web and application-layer bugs. Researchers transitioning from Web2 bug bounty programs often overlook this distinction because demonstration videos are frequently accepted elsewhere.
Severity is evaluated using Immunefi’s Vulnerability Severity Classification System, while each program specifies whether it follows Primacy of Impact or Primacy of Rules. It’s this decision that materially impacts the real money a researcher will ultimately receive.
Under Primacy of Impact, achieving a confirmed in-scope impact through an asset that was not explicitly listed still pays at full severity. Under Primacy of Rules, the written scope governs and the same finding can be closed as out of scope. Check which one applies before you start, not after.
Reports must be written in English, must be substantially your own work, and must include reproducible steps. Vague placeholder submissions filed to reserve a claim are treated as a rules violation rather than an incomplete report.
You may also like: Crypto Tasks and Blockchain Activities: Every Way to Earn in 2026
The Rules That Get Accounts Banned Without Warning
Immunefi enforces its rules more aggressively than any comparable platform, and the published list of prohibited behaviour carries consequences that most newcomers do not read closely enough. One of the most significant restrictions concerns testing against deployed environments. Any testing against mainnet or public testnet deployed code is grounds for an immediate and permanent ban. All work belongs on a local fork.
The other behaviours that trigger suspension or a permanent ban:
- Spray-and-pray submissions: filing low-quality reports across many programs hoping one lands.
- Misrepresenting severity: labelling everything critical regardless of actual impact.
- Multiple accounts: used to evade submission rate limits, which bans every associated account.
- Duplicate self-submissions: re-filing your own report to the same project to claim an additional reward.
- Publication policy breaches: posting screenshots from your reports, or discussing findings beyond what the project’s Responsible Publication category permits.
- Requesting mediation on a spam report: treated as a permanent ban without appeal.
The Ban Risk That Decides Whether Your Work Gets Paid
Some researchers have publicly described a recurring pattern in which accounts were suspended after falling below the platform’s required quality threshold, with active reports becoming inaccessible at the same time. Because the platform requires KYC for payouts on most programs, a ban is effectively permanent preventing a researcher from creating even a new account. at the person level rather than the account level. Other bounty hunters claimed to have lost confirmed medium and high severity findings this way, along with drafts they could no longer access after losing login.
What makes this more than a fairness complaint is a line in Immunefi’s own project-facing documentation. It states that if a researcher is banned before payment of a valid report, no reward is required, though the project still owes Immunefi its fee. With that interpretation, a ban therefore means no future participation, but also no payment for reports that had already been accepted.
The opposing perspective is equally important. Public complaints represent a self-selecting sample, while researchers whose reports are processed successfully rarely publish their experiences. Human triage remains the primary bottleneck across the industry, and AI-assisted tools have dramatically increased the volume of convincing-looking vulnerability reports. As a result, some publicly reported bans almost certainly involve genuine spam, abusive submissions, or other rule violations.
In one widely known case a researcher mentions that a proof of concept brought down a testnet node, which is itself an instant-ban offence under the published rules, whether or not the researcher realised it at the time. Not every ban is arbitrary, and a rule you did not know about is still a rule you broke.
Where criticism is most frequently directed is the absence of a graduated enforcement process. Researchers are in favour of models that cost you reputation, or signal for manual reviews before a final permanent ban. This is not to ask for lenient enforcements, but rather an interim review stage before any irreversible suspension actions are taken.
Duplicate reports, for example, document genuine vulnerabilities that were simply reported later than someone else’s submission, leading some experienced researchers to question whether they should count as evidence of bad-faith behaviour.
Check the Vault Before You Spend Three Weeks on a Program
Among experienced Immunefi researchers, the most common piece of practical advice is to verify that the reward money exists on-chain before you start. Immunefi operates a Vaults System that lets projects deposit assets and prove they can cover payouts, visible to researchers in the interface. Using the vault is optional. A program can advertise a six-figure maximum while holding a small balance. Researchers describe an impressive headline figure attached to a vault with almost nothing in it.
The second screening habit worth adopting concerns findings that require a privileged or administrative action to trigger. Even when that action is guaranteed to occur as part of normal operations, programs frequently close such reports as invalid on the grounds that they depend on trusted-party behaviour. Confirm how the program treats admin-dependent impact before you invest the analysis time.
A practical pre-work checklist:
- Vault balance against advertised maximum: a funded vault is the single strongest signal that a program intends to pay.
- Primacy of Impact or Primacy of Rules: determines whether adjacent assets count.
- KYC requirement: listed per program, and it decides whether you can be paid at all from your jurisdiction.
- Payment currency and conversion terms: covered in detail in the next section, and routinely the difference between the headline figure and your actual take.
- Project financial health: a token in sustained decline signals a treasury with no appetite for a large payout, and failing projects break their commitments in predictable ways.
How Token Payouts Can Halve Your Bounty Before You Receive It
One of the most overlooked sections of bug bounty campaigns is the model used in reward payments, and token valuation. Instead of paying in stablecoins, some projects opt to calculate a token quantity using the market price on the date a report is submitted rather than when payment is eventually made. The Threshold Network program spells the mechanic out with a worked example: a $5,000 award at a submission-date price of $1.75 becomes 2,857 tokens, regardless of what those tokens are worth when they arrive.
This approach term is neutral in a stable market and brutal in a falling one, because triage delays are common and entirely outside your control. Some researchers have publicly described waiting seven months for confirmation on a valid critical finding, then receiving a token quantity fixed at the old rate while the token had fallen by roughly half in the interim. In those cases, the project honoured the written terms of the program, but the economic value received was considerably lower because the conversion date had been fixed months earlier
The defence is to read the conversion clause before submitting and to prefer programs with better terms. Some are notably fairer: the Polygon program calculates token payouts using a five-day time-weighted average price from the payment date, which keeps the volatility risk with the party controlling the timeline. Stablecoin-denominated programs remove the problem entirely.
If you are already in this position, asking politely for a goodwill adjustment is reasonable and occasionally works, but the program follows its written terms and has no obligation. Treat the conversion clause as a term you accept at submission, because that is precisely what it is.
| Payout term | Who carries the price risk | What to do |
|---|---|---|
| Stablecoin denominated | Nobody; value is fixed | Preferred, no action needed |
| Native token, rate at payment date | The project | Acceptable; delays do not cost you |
| Native token, rate at submission date | The researcher | Factor in delay risk before submitting |
When a Project Disputes or Quietly Fixes Your Finding
Immunefi provides a formal mediation process when disputes arise between researchers and projects. The endgame is ensuring projects compensate researchers fairly, respond promptly, and act in good faith. There is also an on-chain Arbitration Protocol intended to produce binding decisions on disputed reports.Yet, some researchers argue that the mediation avenues close down once a final decision has been recorded. Hence, opportunities to challenge a disputed decision may depend on whether the program supports arbitration or other review mechanisms.
One of the most frequently discussed frustrations within the security community concerns what researchers refer to as a “silent fix.” In these situations, a report closed as invalid or as intended design, followed shortly afterward by on-chain activity that looks unmistakably like emergency remediation of the exact issue.
Researchers have documented cases where a project drained a substantial share of a pool’s liquidity within minutes of dismissing a report. On-chain data makes the contradiction visible in a way it never is in web2 security, which is a genuine structural advantage, but visibility is not enforcement.
Researchers must also be realistic about the leverage available when raising disputes. Responsible publication rules limit what you can say while a dispute is live, and breaching them risks the reward and the account. The realistic options are mediation, arbitration where the program supports it, and public criticism once disclosure terms permit it. Understanding how bad-faith operators behave across the wider crypto space helps you avoid the programs most likely to put you here.
One escalation that appears in these discussions needs stating plainly rather than politely: when disputes go badly, someone always suggests keeping the funds instead of reporting. That is theft, not leverage. It converts a payment dispute into a serious criminal offence, and the researcher raising it has usually already submitted under KYC and a real-name account, so the anonymity the suggestion assumes does not exist. Frustration with a platform is legitimate. The correct response is to stop working on that program and say so publicly when you are permitted to.
Building the Skills Before You Submit Anything
An Immunefi bug bounty rewards findings that survive expert triage, so the entry requirement is real competence in Solidity, Rust, or Move depending on the target chain, plus enough cryptography and protocol knowledge to reason about economic attacks rather than just code defects. Experienced hunters consistently point newcomers to the same practice ground: deliberately vulnerable training environments such as Damn Vulnerable DeFi, and the public repositories cataloguing real historical exploits, worked through until the attack patterns are familiar.
Learn the tooling in parallel, because the platform demands it. Foundry and Hardhat are the frameworks used to fork mainnet and write the proof of concept that Immunefi requires, and being unable to produce one means your finding is unreportable no matter how real it is. Reading published post-mortems of past hacks is the highest-value study material available, and it is free.
A note on artificial intelligence, since it divides this community sharply: the useful distinction is not whether you use it but whether you verify what it produces. Using a model to scaffold a test environment or tighten a report reads very differently to triagers than submitting unverified generated output, and the platform bans for the second. A finding you cannot personally explain and reproduce is not a finding you should be filing.
If this sounds like more than you want to take on, that is a reasonable conclusion rather than a failure. The wider range of crypto tasks and activities contains genuine on-ramps that bug bounties are not: crypto faucets need no technical skill, testnet participation rewards care and consistency, airdrop farming sits in between, and structured microtask programs offer far more predictable hours-to-payment ratios. Anyone presenting bug bounty hunting as accessible beginner income is describing something that does not exist, which is the same overstatement pattern seen on platforms that inflate what casual users can earn.
One last framing point. A funded bounty program tells you a project takes security seriously enough to pay for it, but it is not proof of safety, and a clean audit score is not the same as a secure protocol. That scepticism protects you as a researcher choosing programs just as much as it protects users choosing where to put money.
People also read: Crypto Faucets: Are They Worth It and How to Earn Safely
Frequently Asked Questions
Immunefi is a legitimate platform that has facilitated the largest verified payouts in Web3 security, including a documented $10 million reward. It also attracts persistent criticism over automated bans and dispute handling. Both are true at once: the platform is real and the payouts are real, while the experience for researchers whose reports get closed can be genuinely poor.
Duplicates alone are not listed as a bannable offence in the published rules, but researchers report accounts closed after a run of invalid and duplicate submissions under an accuracy threshold. The practical advice is to submit less and verify more, since submission volume with a low hit rate is the pattern that draws attention.
No. Immunefi charges the sponsoring project a 10% fee, which sits on top of your reward rather than being deducted from it. The project pays you directly, which also means Immunefi cannot compel payment if a project refuses.
Most programs require a working proof of concept for all severities, and for smart contract findings it must be runnable code on a forked environment rather than a video or screenshots. Reports lacking one are closed, and repeated incomplete submissions count against your account.
Immunefi rules require projects to respond in a timely manner and you can request mediation. The larger risk of a long delay is financial rather than procedural: if the program converts your reward at the submission-date token price, a delayed payout in a falling market costs you real value with no recourse.
