Bug Bounty Platforms Overview
You have learned the skills. Now it is time to apply them where it matters most — and get paid for it. Web3 bug bounties are the highest-paying in all of security. Immunefi alone has paid out over $95 million to researchers. A single critical finding at a top protocol can pay more than most people earn in a year. This lesson covers every major platform in detail so you can choose where to focus your efforts.
Platform Landscape Overview
| Platform | Format | Max Payout | Competition Level | Best For |
|---|---|---|---|---|
| Immunefi | Ongoing bounties | $10M+ (rare) | Low (asynchronous) | Critical/High bugs in live protocols |
| Code4rena | Time-limited contests (3-7 days) | $100K+ pool | High (competitive) | Comprehensive protocol audits |
| Sherlock | Contests + staking | $100K+ pool | High (competitive) | Auditors who want protocol-level exposure |
| CodeHawks (Cyfrin) | Contests + First Flights | $50K+ pool | Medium (growing) | Beginners via First Flights |
| Cantina | Competitions + invite-only | $100K+ | Medium-High | Quality-focused submissions |
Immunefi — Where the Big Money Lives
Immunefi is the largest smart contract bug bounty platform in the world. Over $95 million paid out. It operates like a traditional bug bounty program: you find a bug in a live deployed protocol, report it privately, and get paid if validated.
How Immunefi Works
Step 1: Protocol lists a program
→ Defines scope (which contracts are in scope?)
→ Defines rewards (what pays what?)
→ Examples: LayerZero ($15M critical max), Optimism ($2M)
Step 2: Researcher finds a vulnerability
→ Read the in-scope contract code
→ Identify a security bug
→ Build a working proof of concept (PoC) exploit
Step 3: Submit a report via Immunefi
→ Report template: title, description, impact, steps to reproduce, PoC
→ Submitted PRIVATELY to the protocol team only
→ NOT public until resolved
Step 4: Triage process
→ Timeline: typically 3-14 days for initial response
→ Immunefi triages to verify the bug exists
→ Protocol team confirms impact and agrees on fix
Step 5: Payout
→ Protocol team fixes the vulnerability
→ Researcher receives payment in ETH, stablecoins, or protocol token
→ Disclosure can be published after fix is liveImmunefi Severity Levels
| Severity | Typical Range | Criteria | Real Example |
|---|---|---|---|
| Critical | $50K - $10M+ | Direct loss of user funds, protocol insolvency | Wormhole: $10M for signature bypass ($320M at risk) |
| High | $5K - $100K | Significant fund loss (indirect), protocol compromise | Uniswap: $40K for governance manipulation |
| Medium | $1K - $25K | Limited fund loss, temporary service disruption | Aave: $5K for reentrancy in non-critical path |
| Low | $100 - $5K | Informational issues, non-critical bugs | Various: $1K for gas optimization that could be exploited |
PoC Requirements — What Immunefi Expects
Minimum requirements for a Critical/High submission:
1. Clear description of the vulnerability
→ What contract, what function, what line
→ Why is this a security issue?
2. Impact assessment
→ Who is affected? How much can be stolen?
→ What is the worst case scenario?
3. Working Proof of Concept
→ Foundry test that demonstrates the exploit
→ Should run with: forge test --match-test test_exploit -vvvv
→ Should show: before state (vulnerable), attack execution, after state (funds stolen)
4. Root cause analysis
→ Why does this vulnerability exist?
→ What is the incorrect assumption in the code?
5. Recommended fix
→ How should the code be changed?
→ (Optional but demonstrates quality)
Example PoC test structure:
function test_exploit() public {
// Setup: fork mainnet, identify victim contract
vm.createSelectFork(vm.envString("MAINNET_RPC_URL"));
uint256 victimBalanceBefore = token.balanceOf(victim);
uint256 attackerBalanceBefore = token.balanceOf(attacker);
// Execute exploit
vm.prank(attacker);
exploitContract.attack();
// Prove impact
assertGt(token.balanceOf(attacker), attackerBalanceBefore);
assertLt(token.balanceOf(victim), victimBalanceBefore);
console.log("Stolen:", token.balanceOf(attacker) - attackerBalanceBefore);
}Real Immunefi Payout Examples
Wormhole — $10,000,000 (2022)
Bug: Signature verification bypass in bridge contract
At risk: $320M in bridge assets
Researcher: white-hat who reported instead of exploiting
Polygon — $2,000,000 (2022)
Bug: Double-spending vulnerability in PoS bridge
At risk: $850M+ in MATIC
Note: One of the largest payouts in history at the time
Optimism — $2,000,042 (2022)
Bug: Infinite token minting exploit
Researcher received $2M + $42 bonus
Aurora — $6,000,000 (2022)
Bug: ETH theft vulnerability
At risk: ~$200M in user funds
LayerZero — $15,000,000 max (ongoing)
Current maximum available bug bounty
For critical vulnerabilities in the cross-chain messaging system
Take-away: Bug bounties pay MORE than traditional security
because the alternative (exploitation) is catastrophic and public.Code4rena — The Competitive Audit Platform
Code4rena (C4) runs time-limited audit competitions where many independent researchers ("wardens") review the same codebase simultaneously. Wardens compete for a fixed reward pool based on the quality and uniqueness of their findings.
How Code4rena Works
Phase 1: Contest Opens (3-7 days)
→ Protocol submits code + documentation
→ Reward pool set (e.g., $100,000 USDC)
→ All registered wardens can view the codebase
→ Wardens submit findings through C4's platform
→ Communication: GitHub issues + Discord
Phase 2: Judge Review (1-4 weeks post-contest)
→ Selected judge (senior auditor) reviews all submissions
→ Findings categorized: High, Medium, QA (Low), Gas
→ Duplicate findings are grouped (only one pays full)
→ Contested findings can be challenged
Phase 3: Reward Distribution
→ Reward split based on:
a) Severity: High gets more than Medium
b) Uniqueness: if 1 warden finds it, they get 100%
if 5 find it, they share proportionally
c) Quality: well-written = higher share of pool
Scoring formula (simplified):
Score = (severity_multiplier) * (1 / number_of_duplicate_finders)
Example with $100K pool:
Warden finds unique High severity finding
→ Gets ~50% of the High pot = $25K-$40K
Warden finds Medium severity (same as 4 others)
→ Gets 1/5 of Medium pot = $2K-$5KGetting Started on Code4rena
For your FIRST Code4rena contest:
1. Choose a smaller scope contest
→ Fewer contracts = faster full coverage
→ Look for "First Flight" or small scoped ($20K-$50K pool)
2. Read EVERYTHING before finding bugs
→ Documentation (white paper, README)
→ All in-scope contracts (top to bottom)
→ Previously deployed versions of the same protocol
3. Use a systematic checklist
→ Check every function for access control
→ Check every external call for reentrancy
→ Check every calculation for overflow/precision
→ Check every oracle usage for manipulation
→ (Solodit has a 380-item audit checklist)
4. Submit well-documented findings
→ Even if you're not sure it's valid, submit Medium with caveats
→ Judges can downgrade; they cannot find bugs you missed
5. After the contest, READ ALL FINDINGS
→ Don't just look at what you found
→ Read every finding from every other warden
→ For each bug you missed: why did you miss it?
6. Repeat 20+ times before expecting consistent payoutsSherlock — Staking Model
Sherlock differentiates itself with a staking model: auditors ("Watsons") stake USDC and are rewarded based on contest performance. Poor performance means losing part of your stake.
How Sherlock Works:
1. Auditors stake USDC (minimum ~$100)
→ Staked USDC earns yield from protocol premiums
2. Participation in contests
→ Submit findings during contest window
→ Higher stake = higher weight in reward calculation
3. Judging based on quality
→ Lead Judge is a senior auditor designated per contest
→ Lead Watson submits contest finding list
→ Community judges + Sherlock judge validate
4. Reward/penalty distribution
→ Correct findings: rewarded proportionally
→ False positives (invalid submissions): penalized
→ The staking mechanism filters out low-quality submitters
Watson Score: Public ranking based on historical performance
→ Top Watsons get early access and bonus rewards
→ Visible portfolio of past performance
Advantage vs C4: More structured judging, less gaming the system
Disadvantage vs C4: Lower total contest pool sizes (historically)
Getting Started:
→ Register at sherlock.xyz
→ Read the docs on how findings are evaluated
→ Start with lower-stakes contests to understand the processCodeHawks — Cyfrin's Platform
CodeHawks is the bug bounty and contest platform built by Cyfrin (who also made Cyfrin Updraft). It has a unique beginner track called "First Flights" that is designed specifically for new auditors.
First Flights:
- Smaller codebases (200-500 lines vs 5,000+ in real contests)
- 4-12 hour expected review time (vs 40+ hours in full contests)
- Smaller reward pools ($500-$5,000) but much less competition
- Designed as a learning experience
- Post-contest report is educational (explains all findings)
Who should start here:
→ Anyone who has completed Ethernaut + DVDF
→ People who haven't participated in competitive auditing before
→ Those who want lower-stakes practice
Full CodeHawks Contests:
→ Same format as Code4rena: time-limited, competitive
→ Reward pools: $20K-$200K+
→ Growing quickly in size and quality
→ Backed by Cyfrin's reputation and community
URL: codehawks.comYour First Bug Bounty — Realistic Expectations
Most serious auditors participate in 10-20 contests before earning a significant payout. This is normal. The skill compounds — each contest teaches patterns that make the next one more efficient. The top earners on Code4rena and Sherlock earn $500K+ per year, but they have years of compounded pattern recognition. Start with the learning goal, and the earnings will follow.
Month 1-3 (First Flights + small C4 contests):
→ Expectation: $0-$500 total
→ Reality check: You may find QA issues but miss Highs
→ Learning: How judging works, what makes a valid finding
Month 3-6 (Regular C4/Sherlock contests):
→ Expectation: $500-$3,000 per contest (occasionally)
→ Reality check: You'll miss most Highs still
→ Learning: Starting to spot patterns you've seen in CTFs
Month 6-12 (Developing pattern recognition):
→ Expectation: $1,000-$10,000 per contest (less frequently)
→ Reality check: You start finding High severity bugs occasionally
→ Learning: Protocol-specific knowledge becomes valuable
Year 2+:
→ Expectation: $5,000-$50,000+ per contest (top wardens)
→ Some wardens earning $200K-$1M+ annually at this stage
→ Reality: Requires dedication and continuous learning
Immunefi (whenever you're ready):
→ Start looking for bugs in Immunefi programs alongside contests
→ The extra reward for critical bugs is extraordinary
→ One good finding can exceed months of contest workHow to Write a Great Vulnerability Report
## [H-01] Reentrancy in withdraw() allows draining all ETH
### Summary
The `withdraw()` function in `VaultContract` performs an external ETH transfer
before updating the user's balance, allowing a malicious contract to reenter
and drain all protocol funds.
### Vulnerability Details
**Location:** `src/Vault.sol`, line 45, function `withdraw()`
**Root Cause:**
The function violates Checks-Effects-Interactions by calling `msg.sender.call`
before updating `balances[msg.sender]`.
Vulnerable code:
function withdraw(uint256 amount) external {
require(balances[msg.sender] >= amount);
(bool ok,) = msg.sender.call{value: amount}(""); // ← ETH sent here
require(ok);
balances[msg.sender] -= amount; // ← balance updated AFTER external call
}
### Impact
**Severity: High**
An attacker with any deposit can drain all ETH held by the contract.
At the time of writing, the vault holds 150 ETH ($450,000 at current prices).
### Proof of Concept
See full Foundry test at: [link to PoC code]
forge test --match-test test_ReentrancyDrain -vvvv
// Output: Attacker stole 150 ETH starting with 1 ETH
### Recommended Fix
Apply the Checks-Effects-Interactions pattern:
function withdraw(uint256 amount) external {
require(balances[msg.sender] >= amount);
balances[msg.sender] -= amount; // Update state first
(bool ok,) = msg.sender.call{value: amount}("");
require(ok);
}Common Mistakes Section
On Immunefi especially, a bug report without a working proof of concept is often dismissed or given much lower priority. Always build and test your exploit in Foundry before submitting. A 10-minute investment to write a PoC test increases your payout probability dramatically.
Calling a Medium-severity issue "Critical" harms your reputation and causes delays. Be conservative and precise with severity ratings. If you're unsure, describe the impact clearly and let the triage team assign severity. Chronic overseverity gets you flagged as a researcher who doesn't understand impact assessment.
Every bug bounty program defines what is in scope. Reporting a bug in an out-of-scope contract wastes everyone's time and marks you as someone who doesn't follow instructions. Read the scope document before touching any code. Common out-of-scope items: centralization risks, theoretical attacks with no economic incentive, issues in external dependencies.
Bug bounty participation requires you to disclose vulnerabilities responsibly — to the protocol team privately first, not publicly. Do NOT exploit vulnerabilities you find for personal gain. Do NOT front-run patch announcements. Follow each platform's responsible disclosure policy. Violating these norms is not only unethical — it is criminal in most jurisdictions and will result in permanent platform bans and potential legal action.
Summary / Key Takeaways
| Platform | Best Use | Where to Start |
|---|---|---|
| Immunefi | Critical/High bugs in live protocols | After solid CTF + contest background |
| Code4rena | Competitive auditing, comprehensive reviews | Start with smaller scope contests |
| Sherlock | Competitive + staked reputation building | After understanding C4 format |
| CodeHawks First Flights | First steps in competitive auditing | After Ethernaut + DVDF |
| Cantina | Quality-focused, growing platform | After establishing credibility |