Bonus — Bug Bounty (Immunefi-focused): How to Hunt Live-Mainnet Vulnerabilities for Money

“Audit competitions teach you to find bugs. Bug bounties teach you to find bugs that cost money. The difference isn’t subtle. A frozen snapshot of a codebase is an academic exercise; a live mainnet contract with $400M of user deposits is a loaded weapon. Bounty hunting is the only place in Web3 where you can earn six figures from a single Saturday — and the only place where ‘almost a critical’ pays you zero dollars and a polite email.”

Tags: web3-security bug-bounty immunefi disclosure severity methodology vscs Learner: Past Tuan-15-Audit-Methodology-Tooling and Tuan-Bonus-Audit-Competition-Playbook → has the bug-finding chops, needs the business of bug bounty Time: ~5–8 days reading + lab (parallel to other work — bounties are a side stream while you build a name) Related: Tuan-Bonus-Audit-Competition-Playbook · Tuan-15-Audit-Methodology-Tooling · Tuan-16-Report-Writing-Capstone · severity-rubric-immunefi-c4 · audit-report-template

1. Context & Why

1.1 The shape of the income stream

Three streams of “professional bug finding” exist in Web3, and each is a different business, not just a different platform:

Stream	Cadence	Risk profile	Income shape
Salaried audit firm (ToB, Spearbit, OZ, Consensys)	Continuous	Lowest variance; salary	Mid-six figures + benefits
Audit contest (Code4rena, Sherlock, Cantina)	1–4 week sprints, frozen code	High variance per contest; predictable monthly if you do many	$0-$ 50k per contest, mostly $1–10k
Bug bounty (Immunefi, Hats, HackerOne, Cantina bounties)	Open-ended, live mainnet	Extreme variance; can be zero for months	$0-$ 10M per finding

Bug bounty is the highest-ceiling, highest-variance stream. The numbers floating around the industry — satya0x’s $10 M f or W or mh o l e, pw nin g . e t h^{'} s$ 6M for Aurora, Wagner’s $2 M f or P o l y g o n — a rere a l, b u tt h ey a re t h e t ai l . T h e m e d ian * p ai d * re p or t o n I mm u n e f i s i t s a t$ 20,000; the mean is ~$114,000 (pulled up by the criticals). [verify: Immunefi 2024 stats]

Why this matters: bug bounty is not “do contests but on real code”. It is a structurally different game. Confuse them and you’ll waste months hunting in the wrong way.

1.2 The unifying meta-model

Audit contests reward you for finding bugs the protocol’s auditors missed in a known window. Bug bounties reward you for finding bugs that would actually steal money, today, on the live system.

Three downstream consequences flow from this:

Severity = economic damage potential, not finding novelty. A “design choice” that no auditor caught but doesn’t drain money is informational, not critical. Conversely, a long-known issue that no one has yet weaponized into a working PoC is still your critical if you write the PoC.
Time-to-market matters infinitely more. In a contest, the code is frozen; you compete with maybe 200 other auditors against a fixed end date. In a bounty, the code is live; the moment a black hat finds the same bug, your finding is worth zero and the protocol loses $40M. You are racing the universe.
PoCs must be transferable, runnable, and surgical. A contest finding can describe the bug in prose. A bounty finding must give the protocol team a Foundry repo they git clone && forge test to see the drain, with USD-denominated impact in the README.

If you internalize only one thing from this lesson, internalize this: bug bounty hunting is a service business where the deliverable is “irrefutable proof of a $X loss avoided, packaged so the engineering team can act in two hours”.

1.3 What you’ll be able to do by the end

Read an Immunefi program page and decide, in under five minutes, whether it’s worth your time.
Map a finding to Immunefi VSCS v2.3 severity confidently — including the gotchas (admin-required, external-protocol-dependent, requires-unlikely-user-behavior).
Write a PoC that the protocol team can run in 60 seconds, and a report they don’t need to email you to clarify.
Survive a triage standoff (severity downgrade, “already known”, “design choice”) without burning the relationship.
Spot the white-hat-vs-black-hat decision tree in a live exploit window (the MEV-bot-front-runs-attacker play).
Handle the legal/tax side: KYC, jurisdiction, lawyer-up triggers.

1.4 Primary references

Source	URL	Status
Immunefi VSCS v2.3	https://immunefi.com/immunefi-vulnerability-severity-classification-system-v2-3/	Current as of 2026-05
Immunefi Learn (hub)	https://immunefi.com/learn/	Updated regularly
Immunefi Bugfix Writeups (Medium)	https://medium.com/immunefi	Ongoing; ~weekly publishes
Immunefi PoC Templates	https://github.com/immunefi-team/forge-poc-templates	Current
Immunefi PoC Guidelines	https://immunefisupport.zendesk.com/hc/en-us/articles/9946217628561	Current
Immunefi Bug Report Template	https://immunefisupport.zendesk.com/hc/en-us/articles/12435277406481	Current
Hats Finance docs	https://docs.hats.finance/	Current
HackerOne Web3 programs	https://hackerone.com/directory (filter: blockchain/crypto)	Current
Bugcrowd Web3 programs	https://bugcrowd.com/programs	Current
Code4rena Blue (bounties)	https://code4rena.com/bounties	Current
Cantina bounties	https://cantina.xyz/bounties	Current

2. Bounty vs Contest — the structural difference

2.1 The five hard dividers

Dimension	Contest	Bounty
Target state	Frozen commit hash	Live mainnet (state and code can change under you)
Time window	1–4 weeks, fixed	Unbounded — open until the program closes
Severity basis	Severity per the protocol’s contest rubric, as judged by judges	Severity = realized/realizable economic damage if exploited today
Payment per finding	Shared with other finders (split prize pool)	Solo finder takes the entire bounty for that bug (first-come-first-paid)
Triage	Judges with a deadline	Protocol engineers on their own schedule (often slow)

The “live mainnet” point is the deepest. In a contest, you treat the codebase as a closed system: you can change anything in your local fork; nothing you do affects the protocol. In a bounty, your reading of the contract today may not be the contract tomorrow — protocols upgrade proxies, change governance parameters, pause functions. A bug you find Monday may be patched Wednesday by an unrelated change.

This forces a habit: when you find a candidate finding, freeze the exact state in your PoC. Record the block number. Pin the proxy implementation. Note the parameters at exploit time. If you write up a report from “memory” three days later and the protocol has shifted, your PoC may not reproduce and your finding will be closed as “could not reproduce”.

2.2 Severity tied to economic damage potential

Immunefi’s VSCS is impact-only. It does not multiply by likelihood the way CVSS does. The framework asks: “if this bug were exploited, what would the realized damage be?” Not “how likely is exploitation?”

Practical consequence: a finding that requires the admin key to do something stupid is not a critical in VSCS. The admin acting stupidly is “elevated privileges” and routinely downgrades. By contrast, a finding that’s a one-tx drain by any external actor with $50 of gas is the textbook Critical.

This is the single most common reason new bounty hunters get downgraded — they map “severe vulnerability” to “novel/clever bug” rather than “would actually drain money under realistic conditions”. The protocol triager has heard the “but it’s so clever” speech before. They want the bank-statement view: how much money, how realistic, how many users.

2.3 Triage by protocol (not by judges)

In a contest, professional judges read all findings and rank them within a known set. Bounce-back is fast and structured.

In a bounty, the protocol engineering team triages you, with no SLA in many programs. Their incentives:

Pay as little as possible (it’s their treasury or insurance fund).
Patch quickly to avoid embarrassment / actual loss.
Avoid setting precedent (“if we pay this, we have to pay every report like it”).
Defend their architecture publicly (“not a bug, that’s by design”).

The mental shift: in a contest you write for a judge who knows the codebase. In a bounty you write for an engineering manager who is busy, defensive, and skeptical. Same skill of finding the bug; very different communication.

2.4 Higher payouts per finding

The economic asymmetry of bounties:

Severity	Typical contest finding payout	Typical Immunefi bounty payout range [verify per program]
Critical	$5 k -$ 30k (shared pool)	$50 k -$ 10M (often capped at 10% of funds-at-risk, max cap)
High	$1 k -$ 8k	$5 k -$ 100k
Medium	$300-$ 2k	$1 k -$ 15k
Low	$100-$ 500	$0-$ 2k (many programs don’t pay Low)
Informational	Symbolic	Symbolic or unpaid

The “10% of funds at risk, capped at $X " r u l e i s t h e t y p i c a l I mm u n e f i f or m u l a . S o W or mh o l e^{'} s$ 10M reflects: a critical found, funds at risk in the billions, but cap of $10 M . * * T h ec a p ma tt erse n or m o u s l y * * — a cr i t i c a l o na$ 50M TVL protocol with a $1 M c a pp a ys$ 1M not $5M. Always read the cap before deciding where to spend hours.

2.5 The lifecycle of a bounty finding

   ┌─────────────────────────────────────────────────────────────────┐
   │                       BOUNTY FINDING LIFECYCLE                  │
   ├─────────────────────────────────────────────────────────────────┤
   │  T+0    You read the program page                               │
   │  T+1h   You decide to spend time on it (program rating)         │
   │  T+1d   You set up a mainnet fork, start hunting                │
   │  T+3d   You find a candidate vulnerability                      │
   │  T+4d   You build a clean PoC: forge test that drains funds     │
   │  T+5d   You write the report, encrypted/submitted to Immunefi   │
   │  T+5d   Immunefi triages (1–7 days), forwards to protocol       │
   │  T+10d  Protocol confirms (or pushes back on severity)          │
   │  T+15d  Severity finalized (mediation if needed)                │
   │  T+30d  Patch deployed                                          │
   │  T+45d  Bounty paid (KYC if required, on-chain transfer)        │
   │  T+90d  Coordinated disclosure / public writeup (Immunefi blog) │
   └─────────────────────────────────────────────────────────────────┘

90 days is the typical end-to-end. The 30 days between “patch deployed” and “bounty paid” is when most disputes happen.

3. Immunefi VSCS v2.3 — the playbook

The Vulnerability Severity Classification System v2.3 has two tracks: Smart Contracts and Websites & Apps. Most readers of this lesson care about the Smart Contracts track.

3.1 Smart contracts: the five levels

Critical (Level 4)

The “drain it now” tier. Criteria (any one of these):

Direct theft of any user funds, at rest or in motion, other than unclaimed yield. (Unclaimed yield drops to High — see below.)
Governance vote manipulation that alters outcomes.
Permanent freezing of funds or NFTs (can never be recovered).
Unauthorized minting of NFTs that have non-zero value.
Protocol insolvency (e.g., a path that makes total liabilities > total assets even without an exploit being run).

Examples that fit Critical, drawn from real disclosed bugs:

A vault function that lets you withdraw 100x what you deposited (Aurora EVM nETH double-deposit).
An uninitialized UUPS proxy implementation whose initialize can be hijacked by anyone (Wormhole 2022).
A double-spend bug in a bridge where a withdrawal can be replayed 223 times (Polygon Plasma 2021).

Typical Critical payout range: $50, 000 t o$ 10,000,000, gated by:

The program’s stated max bounty cap (often $1 M -$ 10M).
The 10%-of-funds-at-risk formula (whichever is lower).
KYC compliance.

High (Level 3)

Theft of unclaimed yield/royalties (i.e., funds that aren’t user principal but the protocol owes).
Permanent freezing of unclaimed yield.
Temporary freezing of funds (user funds locked but eventually recoverable — e.g., a function paused indefinitely until a redeploy).
Temporary freezing of NFTs.

Typical High payout: $5, 000-$ 100,000.

The contrast with Critical hinges on principal vs yield and permanent vs temporary. A bug that temporarily freezes $10M for two weeks until a multisig redeploys is High, not Critical, even though the user-facing damage feels severe.

Medium (Level 2)

Smart contract unable to operate due to insufficient funds (the protocol can’t pay out promised rewards because of a token accounting bug, but no theft).
Block stuffing / griefing that’s reproducible and burns user funds via gas.
Unbounded gas consumption (loop that scales with attacker-controlled input until the function reverts).
Theft of gas (forcing a victim to pay gas they shouldn’t).

Typical Medium payout: $1, 000-$ 15,000.

Low (Level 1)

Contract fails to deliver promised returns but doesn’t lose value (e.g., yield calculation is off by a small constant in a way that hurts the user but doesn’t enable theft).
Minor invariant violations without economic impact.

Typical Low payout: $0-$ 2,000. Many programs do not pay Low.

None / Informational

Best-practice nits, optimization suggestions, naming, gas tweaks, missing events.
Theoretical vulnerabilities with no realistic exploitation path.

Typical payout: goodwill, swag, or nothing.

3.2 Websites & apps: the parallel track

Many Immunefi programs include the dApp frontend and infrastructure too. Quick map:

Severity	Examples
Critical	RCE on infrastructure, theft of database credentials or signing keys, taking down the production website/dApp, unauthorized state-modifying actions on behalf of other users (e.g., signing a tx for them), injecting a wallet drainer into the dApp frontend
High	Persistent stored XSS, modifying static content without JavaScript, confidential disclosure, changing sensitive details with minimal interaction
Medium	Reflected HTML injection, modifying non-sensitive user details, open redirects
Low	Significant-interaction-required changes, temporary outage tricks (cookie bombing)

Frontend/infra is underhunted relative to contracts — most bounty hunters live in Solidity. If you have web-app pentest skills as well, the dApp side of Immunefi programs is genuinely less competitive.

3.3 Impact-only philosophy (vs CVSS)

CVSS scoring multiplies impact by attack vector, attack complexity, required privileges, user interaction, etc. VSCS does not.

What this means for you: you do not get extra credit for an attack being simple, cheap, or one-tx. Those things may help you in tiebreakers and reputation, but they do not move the severity tier. The tier is set by what could go wrong if this were exploited under realistic-but-not-adversarial conditions.

What does downgrade (per the VSCS itself):

Required elevated privileges (“requires admin key”).
Required uncommon user interaction (“requires the user to sign a specific malicious payload they would never sign”).
Cross-protocol dependency (the attack only works if another, separate protocol behaves in a way that’s not guaranteed) → automatic downgrade by one severity level, per Immunefi policy.

3.4 The severity-disagreement playbook

When a protocol pushes back (“we think this is High, not Critical”), do not argue at the level of “your rubric vs mine”. Argue at the level of:

The exact funds-at-risk number. Walk them through the PoC line by line.
Whether the attack is admin-required or external-actor-doable. Cite the contract code.
Cross-protocol or stand-alone. If standalone, cite the rubric line.
Permanent vs temporary freezing. If permanent, cite the rubric line.

If the protocol still disagrees, request mediation through Immunefi. Immunefi sides with the rubric, not the protocol. But mediation costs time (often 2–6 weeks), so only invoke when the dollar gap is meaningful (usually >$10k).

4. Targeting bounty programs — where to spend your hours

4.1 Reading the program rules carefully

Every Immunefi program page has roughly:

Max bounty (per Critical, High, Medium, Low).
Bounty formula (often “10% of funds at risk, capped at $X”).
In-scope assets: a specific list of contract addresses, repositories, commit hashes, branches.
Out-of-scope: typically test contracts, deprecated versions, off-chain infrastructure (unless explicitly in scope), and a list of “already known” issues.
KYC requirements: many programs require KYC for any payout above $X (o f t e n$ 1k–$10k threshold).
PoC required: virtually all programs now require a working PoC; some make it explicit (Immunefi will enforce).
Prohibited testing: no testing on mainnet, no DoS without permission, no contact with team members outside the platform.
Audit reports already done: linked at the top. Read them. Anything they explicitly flagged that the protocol fixed is out-of-scope as “already known”.

Read scope obsessively. The single most painful failure mode in bug bounty is finding a critical, writing a PoC, submitting it, and being told “the contract you targeted is V1; we deployed V2 last month; V1 is deprecated and out-of-scope”. You burned a week.

4.2 Identifying “hot” programs

You want programs where:

TVL is high (more funds-at-risk → higher payouts).
Max bounty is generous (look for > $500 k c a p, i d e a ll y >$ 1M).
Scope is broad (more code surface → more bugs).
Program is new (less prior scrutiny — the longer a program has been live, the more researchers have already combed it).
Recent upgrade or new feature (new code is buggier than old code; check the Git history for recent commits to in-scope files).
Complex composability: vaults that integrate with lending markets, bridges between L1/L2, restaking that depends on AVSs — each integration point is a potential bug.

You want to avoid programs where:

The protocol is well-known to be slow/hostile triagers (research on Twitter/Discord; ask other hunters).
Max bounty is tiny ($25k Critical cap is not worth your week).
Scope is narrow (one tiny contract that’s been audited five times).
Heavy KYC and you’re in a jurisdiction that makes it hard.

There’s an Immunefi-tracked stat that’s quietly motivating: 94% of long-running bug bounty programs on Immunefi have surfaced at least one Critical. The bugs are there. The question is whether you find them before someone else.

4.3 Time allocation: the explore/exploit trade

A reasonable cadence for someone going full-time on bounties:

Week	Activity
Week 1	Survey 20 programs; rank by (cap × scope × recency). Pick 1–2 to commit to.
Weeks 2–4	Deep dive on chosen program. Read all audits, fork mainnet, write internal notes. Look for bugs.
End of week 4	If you’ve found something: write up. If not: assess whether to stay or pivot. Sunk-cost is real but if there’s no signal at all in 100 hours, the program may be picked clean.

The “explore vs exploit” tension: do you spend a fifth week on the same program (you know the code better than anyone else who’d come in fresh — there’s an edge there), or pivot to a new one (a fresh program with fresh eyes catches what tired eyes miss).

A useful heuristic: if you’ve found 0 mediums and 0 informationals in week 4, the program is probably clean for someone of your skill. Pivot. If you’ve found 2 informationals, there’s likely a high or critical hiding — stay.

4.4 Multi-program parallelism

Veteran bounty hunters run 2–3 programs simultaneously and rotate based on which is generating signal. The risk of single-program focus: if you spend two months on Program A and find nothing, you have nothing to show. The risk of too-much-parallelism: you don’t go deep enough on any one program to catch the subtle bugs.

A solid middle: one “primary” you’ve committed to for 4–8 weeks, one “secondary” you check once a week for new commits/deployments, and a rolling habit of reading new program announcements weekly to keep your queue stocked.

5. The hunt — finding bugs in live code

5.1 The starting kit

Tools and habits that distinguish bounty hunters from contest hunters:

Etherscan + GitHub side by side: verified contracts on Etherscan are your truth; GitHub is your readable version. Cross-check that they match (don’t trust GitHub alone — the deployed bytecode could have been compiled differently).
Mainnet fork via Foundry: forge test --fork-url $RPC --fork-block-number $BLOCK. Always pin the block.
Etherscan storage reads: cast storage <contract> <slot> — read EIP-1967 implementation slots, admin slots, oracle addresses, multisig signers.
Tenderly: for tx debugging on mainnet; visualizing the trace of an attack.
Slither/Aderyn as low-pass sweep: not for bugs (any program of significance has been Slither’d to death), but for layout overview, inheritance graphs, function ranking.
Internal notes file: per program, a markdown file tracking what you’ve read, what you’ve discarded, candidate findings.

5.2 The reading order

When you commit to a program, read in this order:

Whitepaper / docs — what is the protocol supposed to do? You can’t catch invariant violations without knowing the invariants.
Existing audit reports — what’s already known broken? Read all of them. Anything they flagged as Acknowledged but Not Fixed is interesting (the protocol team disagreed; you might agree with the auditor).
Recent commit history (last 90 days) — what’s new? New code is buggier.
Top-level entry points — every external/public function. Map them.
Trust boundaries — every place the contract interacts with another contract or external input.
Storage layout — what state matters, who can modify it.
Upgrade authority — proxies? Who can upgrade? Cite the slot.
Specific bug class lookups — armed with the map, walk through each Week 5 / Week 6 vulnerability class checklist.

5.3 Forking mainnet to PoC

The canonical Foundry test setup:

// test/BountyPoC.t.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
 
import "forge-std/Test.sol";
 
interface IVulnerableProtocol {
    function deposit(uint256 amount) external;
    function withdraw(uint256 amount) external;
    // ... whatever you need
}
 
contract BountyPoC is Test {
    IVulnerableProtocol target = IVulnerableProtocol(0x...); // mainnet address
 
    function setUp() public {
        // Pin to a known block. The README documents the block.
        vm.createSelectFork(vm.envString("MAINNET_RPC"), 18_900_000);
    }
 
    function test_drainProtocol() public {
        // 1. Snapshot pre-conditions
        uint256 preBalance = IERC20(USDC).balanceOf(address(target));
        emit log_named_uint("Pre-attack protocol USDC balance", preBalance);
 
        // 2. Execute the exploit
        address attacker = address(0xBEEF);
        vm.deal(attacker, 1 ether);
        vm.startPrank(attacker);
        // ... exploit steps ...
        vm.stopPrank();
 
        // 3. Assert the drain
        uint256 postBalance = IERC20(USDC).balanceOf(address(target));
        uint256 attackerProfit = IERC20(USDC).balanceOf(attacker);
        emit log_named_uint("Post-attack protocol balance", postBalance);
        emit log_named_uint("Attacker profit (USDC, 6 decimals)", attackerProfit);
        assertGt(attackerProfit, 0, "exploit did not extract value");
    }
}

Run:

forge test --match-test test_drainProtocol -vvvv

The -vvvv is intentional: you want full trace output in the PoC so the protocol team can see every CALL and storage slot in their reproduction.

Crucial discipline: pin the fork block. The protocol team will reproduce your test on that exact block. If you don’t pin it, they’ll fork “now” — and “now” may have a different state (oracle prices, balances, parameters) where your exploit doesn’t trigger.

5.4 Cross-protocol attack flow

Some of the most lucrative bugs require chaining two protocols. Examples:

Flash-loan from Aave → drain pool A using flash-loaned capital → repay loan; net profit comes from manipulated state in pool A.
Borrow from lending market A using collateral that’s a liquid-staking token from protocol B → manipulate B’s exchange rate via a tiny donation → liquidate yourself favorably in A.

Bounty consideration: if your attack requires protocol B to behave in a specific way that’s not guaranteed, Immunefi VSCS automatically downgrades by one severity level. (Quote: “Bug reports that require an attack that involve one or more other protocols either to make an attack more severe than it would be in isolation, or to achieve an attack that would otherwise be impossible or infeasible, would be downgraded by one severity level.“)

The carve-out: if the integration is explicitly part of A’s design (A’s contracts directly call B, and B is a documented dependency of A), then the attack is “isolated” to A as the protocol-of-record. The line between “cross-protocol downgrade” and “in-scope integration” is fuzzy; expect to argue this if it comes up.

5.5 What makes a finding “your” finding (race condition with black hats)

You found it on Tuesday. A black hat may find it Wednesday. The race is real, and the bigger the program, the more eyes on it.

Risk-management tactics during the hunting → submission gap:

Submit on the same day you confirm, even if the writeup isn’t perfect. You can edit/expand after; what matters is the timestamp on the platform.
Do not test on mainnet. The instant your test tx hits a public mempool, an MEV searcher’s bots will sandwich, copy, and weaponize within blocks. The famous example: bots reading mempool failures, decoding the attempt, and front-running. Always test on a fork, never on live.
Do not tell anyone. Not your Discord friends, not “I’m onto something” tweets, not Discord-DMs to the protocol team outside Immunefi. The leak surface is enormous.
Encrypt high-stakes reports. Immunefi supports PGP-encrypted submissions for the most sensitive findings. Use it when the finding is a critical and a leaked report would itself enable the attack.

6. The PoC — the make-or-break artifact

6.1 What “PoC required” actually means

Most Immunefi programs require a working PoC, not just a written explanation. The exact rules:

No unit-test-only PoCs. They want fork-based reproduction against mainnet state.
No screenshots of code as PoC. The protocol team will literally run your code; screenshots can’t be run.
No testing on mainnet or public testnet. Run it on a local fork.
No DoS attacks without permission. Even DoS PoCs that “prove” a denial-of-service must be requested in advance.

The PoC repo you submit should be downloadable, runnable in 60 seconds (clone + forge test), and self-contained. Treat it like a tiny open-source project: README, foundry.toml, .env.example, src/, test/.

6.2 PoC anatomy: every step the team needs

Your PoC must include:

The exact mainnet block number the fork pins to.
The exact contracts targeted (addresses, not names — names can collide).
The exact attack steps in code, with comments at each step explaining what’s happening.
The exact funds-at-risk calculation in the test output: pre-balance, post-balance, attacker profit, in USD.
The expected attacker setup: how much capital they need to start (0 ETH? flash-loan? specific token allowances?).
The state preconditions: does the attack require the contract to have certain balances, certain oracle prices, certain governance state? Document all of them.

The Immunefi PoC templates repo (immunefi-team/forge-poc-templates) has pre-built scaffolds for: reentrancy, flash-loan, oracle manipulation, token integration, and more. Start from one of those.

6.3 The README — what the engineering manager reads first

A bounty PoC’s README is more important than its code. Recommended structure:

# [Protocol Name] Critical Vulnerability PoC
 
## Summary
One sentence: what the bug is, what the impact is.
 
## Severity (per VSCS v2.3)
Critical — Direct theft of user funds.
 
## Funds at Risk
USD value at time of submission: $X
Affected contracts: [list of addresses with Etherscan links]
 
## Attack Cost
Capital required: X ETH (or flash-loanable, cite source)
Gas: ~Y gwei
 
## Reproduction
 
```bash
git clone <this repo>
cd <repo>
cp .env.example .env  # fill in MAINNET_RPC
forge install
forge test --match-test test_drainProtocol -vvvv

Expected output:

Pre-attack protocol USDC balance: 50_000_000_000_000  (50M USDC)
Post-attack protocol balance:     0
Attacker profit (USDC):           50_000_000_000_000  (50M USDC)

Technical Details

[Step-by-step explanation, contract code citations]

Suggested Mitigation

[Specific code change or design fix]

Disclosure Timeline

T+0: Submitted via Immunefi
T+?: Awaiting protocol response


The engineering manager reading this in 60 seconds should know: what the bug is, what it costs them, how to reproduce, what to fix. If they need to email you back asking "what block?" or "what's the impact?", you've already lost reputation.

### 6.4 Showing numerical impact — the USD calculation

The single most-cited reason for a Critical being downgraded to High: "impact not quantified or quantification disputed". Defend against this by:

- **Quote prices at fork block.** Use Chainlink's price feed *at the forked block*: `chainlinkFeed.latestRoundData()` on the fork → that's the price-of-record.
- **Show the full damage path.** If the attack drains X tokens, multiply by Y USD price at the block, sum across tokens. Document.
- **State the cap.** If the attack drains the entire pool but the pool is small ($500k), say so. Critical doesn't always mean huge dollars — but the dollars matter for the payout (10%-of-funds-at-risk).
- **Distinguish realized vs realizable.** Realized = "the attacker walks away with this much net of costs". Realizable = "the protocol loses this much; some may be unrecoverable lockup, not theft". Both matter, but distinguish them.

### 6.5 The "don't actually exploit" rule

You **do not exploit live**. You submit before exploiting. Reasons:

- **Legal**: many jurisdictions treat smart-contract exploitation as theft regardless of intent. The protocol's "we won't sue" promise is conditional on responsible disclosure.
- **Ethical**: even if you intend to return funds, the panic, gas spike, and user harm during the window of confusion is real.
- **Strategic**: if you exploit, you become a defendant; if you disclose, you become a partner. The bounty system relies on this norm.

There is one famous edge case: **the MEV bot front-running play**. When a black hat exploit goes live and a transaction sits in the mempool, an MEV searcher (often a known whitehat operator like `c0ffeebabe.eth` in the 2023 Curve incident) can front-run the malicious tx, extract the same value, and return it to the protocol. This is a real white-hat play, with real ethical weight, and is distinct from cold exploitation. We discuss it in §10.

---

## 7. The disclosure — Immunefi platform mechanics

### 7.1 Platform submission flow

Every Immunefi submission goes through:

1. **You file via the Immunefi dashboard** — pick the program, pick the asset, fill the structured form (severity, summary, impact, attack vector, PoC link).
2. **Immunefi triager reviews** — sanity check that the submission is in-scope, has a PoC, and meets quality bar. They route to the protocol.
3. **Protocol team reviews** — confirm/dispute, set severity, decide payout.
4. **Mediation if needed** — if you and protocol disagree, Immunefi mediates per the VSCS rubric.
5. **Payout** — typically a stablecoin transfer to your wallet, often after KYC for amounts above threshold.

The triager step is your gate. They can close a submission for "out of scope", "duplicate", "no PoC", "informational only", etc., before the protocol ever sees it. To minimize triager rejection: stay strictly in scope, attach the PoC link in the submission body (not just a "I'll send later"), and state severity with rubric citations.

### 7.2 Encrypted communication

For critical findings, the report itself can be a weapon — anyone reading the description can replicate the attack. Immunefi supports encrypted submission with the protocol's PGP key (when programs publish one). Use it when:

- The vulnerability is Critical.
- The PoC is small enough to obviously work.
- The protocol's incident response is mature enough that they can patch within hours of confirmation.

When *not* to use encryption: when the protocol team doesn't publish a PGP key (most don't), or when the bug is High/Medium (the marginal risk is lower than the friction).

### 7.3 Bug-bounty etiquette

Norms that distinguish hunters who get repeat business from those who don't:

- **Don't leak before fix.** No tweets, no Discord posts, no "I found a bug at [protocol]" hints. Until the protocol publicly discloses (after patch), the finding is theirs.
- **Cooperate on the patch.** If they propose a fix, review it. A bad fix is your problem too — same bug class often returns after a flawed patch.
- **Don't lawyer them on day one.** If the severity dispute looks bad, give it time and use Immunefi mediation first. Lawyering up is the last resort, not the first.
- **Wait for coordinated disclosure.** Most protocols want a 30–90-day window after patch before you publish. Most also offer to co-write the public Immunefi Medium writeup; do it, it's free reputation.
- **Don't double-dip.** Don't submit the same finding to multiple programs or platforms simultaneously. If you found a bug in protocol A using a primitive from protocol B's contracts, choose one.

### 7.4 Standoff with poor-triage protocols

Some protocols have a reputation for slow, unfair, or actively hostile triage. The warning signs:

- They don't respond for >2 weeks after Immunefi forwards.
- They claim "known issue" without providing evidence (per Immunefi policy, **they must provide evidence** — a prior bug report, GitHub issue, PR, or documented mention).
- They invoke "design choice" defensively without engaging with the impact analysis.
- They dispute severity to the lowest tier they can justify.
- They go silent after promising a fix.

Tactics for these situations:

1. **Document everything.** Every message timestamped on the Immunefi platform. Don't move conversations off-platform.
2. **Invoke mediation early.** Immunefi mediation costs you nothing and applies the VSCS rubric impartially. Use it.
3. **Demand evidence for "known issues".** Per Immunefi: projects MUST provide a previous bug report, GitHub/GitLab issue, PR, or other clearly documented evidence. If they can't, the "already known" defense fails.
4. **Re-state the rubric line.** Quote the VSCS verbatim. ("Critical: direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield.")
5. **Last resort: legal counsel.** If a finding is unambiguously Critical and the protocol refuses to pay or threatens you, contact a crypto-savvy lawyer (not before — see §9).

The Injective vs whitehat dispute (May 2024) is the cautionary tale: a researcher accused Injective of "ghosting" after a disclosed $500M-at-risk bug, then went public. Whether you side with the researcher or the protocol, the story shows the underclass risk: a researcher with no leverage may simply not get paid. **Pick programs with reputational accountability.**

---

## 8. Common reasons for downgrade — defending your call

Five canonical downgrade arguments and how to handle each.

### 8.1 "Already known"

**Their argument**: "We knew about this; it was flagged in audit X / discussed in our internal docs / mentioned in a public Discord post."

**Your defense**:
1. Per Immunefi policy, **they must provide documentation** (prior report, issue, PR, public mention with timestamp).
2. If they produce something genuinely prior to your report, accept it; if it's clearly post-dated or vague ("we were going to fix this eventually"), invoke mediation.
3. If the prior mention is high-level ("there's a risk around X") but doesn't describe the specific exploit path *with PoC equivalent specificity*, argue that **specificity matters**: your concrete PoC is the new contribution.

### 8.2 "Requires admin / requires unlikely user behavior"

**Their argument**: "This only works if the owner does something they wouldn't do" or "this requires the user to sign a malicious payload they'd never sign."

**Your defense**:
- If admin-required, **check the admin design**. Is the admin a single EOA? Multisig? Timelock? A bug that requires a 7-of-11 multisig to misbehave is genuinely lower severity than one requiring a single EOA. Distinguish.
- If user-behavior-required, **show that the malicious payload is non-obvious**. Many "user signs a bad payload" attacks are real because the UX of approve-and-permit lets users sign things they don't understand. Cite the [[Tuan-12-Wallet-AA-Key-Management]] signature phishing material; show how a real user could realistically be tricked.
- Per VSCS, "uncommon user interaction" does justify downgrades, but the line between "uncommon" and "common" is fuzzy. Be honest with yourself: if a real user really wouldn't sign it (e.g., a payload that says "drain my entire wallet"), accept the downgrade.

### 8.3 "Design choice"

**Their argument**: "That's intended behavior. We documented it. You're not understanding the protocol."

**Your defense**:
- **Show the contradiction with their documentation.** If their whitepaper or README says X, and the contract does not-X in a way that lets funds drain, that's a bug regardless of "design choice".
- **Show the user-harm vector.** "Design choice" is fine as defense for protocol-level mechanics (e.g., "yes, our oracle is updated every 1h, that's by design"). It's not fine when the design choice enables theft.
- If their documentation genuinely warned about the exact thing you're flagging ("users should not deposit unwrapped ETH directly"), they have a point. Concede with grace.

### 8.4 "Severity disagreement" (defending Critical → not High)

**Their argument**: "It's High, not Critical. Funds aren't directly stolen; they're temporarily frozen / it's yield, not principal / etc."

**Your defense**: walk back through the Critical criteria in §3.1 one by one.
- Direct theft? Show the asset moves from user-controlled to attacker-controlled. The chain of transfers in your PoC trace.
- Permanent freezing? Show that the funds cannot be recovered without contract redeployment or admin intervention. If admin can recover, it's High (temporary). If admin can't, it's Critical (permanent).
- Yield vs principal? **Trace the source of the drained funds in storage.** If they came from `balances[user]` or `userDeposits[user]`, that's principal. If they came from `accruedYield` or `rewardPool`, that's yield (High).

### 8.5 "Cross-protocol downgrade"

**Their argument**: "Your attack only works because protocol B does X. The Y in our protocol is fine on its own."

**Your defense**:
- If protocol B is **explicitly an integration dependency** of protocol A (A's contracts call B's, B's address is hardcoded in A, B is named in A's docs), argue that's not "cross-protocol" — it's "in-scope integration".
- If protocol B is **arbitrary external code** (any flash-loan provider, any DEX), the cross-protocol downgrade likely applies. Per VSCS: one severity level down.
- Sometimes there's a middle ground — flash-loans from Aave are so ubiquitous that "requires a flash loan" is essentially "available to any actor" and shouldn't downgrade. Argue from prevalence and accessibility.

---

## 9. Tax & legal — the boring stuff that ruins lives

### 9.1 Bounties as income

Bug bounty payouts are generally taxed as ordinary income in most jurisdictions, not capital gains. Specifics vary; **[verify with a local tax professional]**, but the typical framing:

- **US**: 1099-MISC or 1099-NEC equivalent treatment if you're a US person; ordinary income, self-employment if you're not on payroll. State income tax also applies.
- **UK**: trading income; income tax + National Insurance if "professional" hunter.
- **EU**: varies by country; typically income tax.
- **Singapore/UAE/some others**: lower or no income tax on bug bounty income — researchers do move for this reason. The legal optics of relocating *for* tax reasons differ across jurisdictions; consult a professional.

Crypto-specific wrinkles:
- If you're paid in stablecoins (USDC), the income is the USD value at receipt. Subsequent price movement is capital gain/loss.
- If you're paid in a project's native token, the income is the token's USD value at receipt; **subsequent volatility is your risk**. Many hunters convert immediately to stablecoin to lock in the income value for tax purposes.
- Mining/staking rewards from received tokens are also income (separate event from the receipt).

**Keep records.** Date of submission, date of confirmation, date of payment, USD value at payment, wallet addresses, transaction hashes. The receipts protect you in audit.

### 9.2 KYC for large payouts

Most large Immunefi programs require KYC for payouts above a threshold (often $1k–$10k, sometimes higher). KYC typically means:

- Government ID + selfie (passport/driver's license).
- Address verification (utility bill or bank statement).
- Sometimes source-of-funds explanation.

This conflicts with the pseudonymous-researcher norm. The trade-off:

- **Anonymous-only programs**: Hats Finance is the main one that supports fully pseudonymous payouts on-chain. Lower payouts on average; fewer programs.
- **KYC'd programs (most of Immunefi)**: higher payouts, more programs, but you must be willing to surface your real identity to the platform.

Many hunters maintain a pseudonym for public profile (the Whitehat Hall of Fame on Immunefi displays handles) while KYC'ing privately with Immunefi for payment.

### 9.3 Sanctions and OFAC

Crypto sanctions are real and consequential. You cannot be paid a bounty if you are:

- A resident of a sanctioned country (Iran, North Korea, Cuba, Syria, etc. — list varies).
- On a sanctions list yourself.
- Affiliated with a sanctioned entity.

Immunefi screens. Hats screens (less strictly). Many protocols screen the recipient wallet against Chainalysis/TRM databases before paying.

If you live in a borderline jurisdiction or have wallets that have ever touched mixers/sanctioned addresses, your payout may be held or rejected. **Use a clean wallet for receiving bounties.**

### 9.4 Lawyer up — when

Most disclosures resolve cleanly. The cases where you should consult a lawyer:

1. **The protocol threatens you** (legal action for "unauthorized testing" despite responsible disclosure).
2. **The protocol refuses to pay** a clearly-in-scope, clearly-confirmed finding.
3. **You receive a subpoena or law enforcement contact** related to a finding.
4. **You hold funds during a white-hat recovery operation** (this is genuinely legally risky — see §10).
5. **You're considering going public** with an unresolved dispute.

A "crypto-savvy lawyer" specifically means someone who has handled smart-contract disclosure cases or DAO governance work, not just general securities or crypto-finance counsel. The Web3 security legal niche is small; ask veteran hunters (some are public about their counsel) for referrals.

**Cost**: initial consultation often $500–$2k; full engagement on a dispute can run $25k+. Account for this when weighing whether to push a disagreement past mediation.

---

## 10. White-hat stories — what good looks like (and what dicey looks like)

Five stories that map the moral and technical territory of being a serious bounty hunter. Read each, then read the linked source.

### 10.1 satya0x / Wormhole — the $10M record

**February 24, 2022**. Whitehat `satya0x` disclosed a critical bug in the Wormhole core bridge contract on Ethereum. The bug: the UUPS proxy implementation had become uninitialized after a prior bugfix reverted the original initialization. An attacker could call `initialize()` directly on the implementation, pass their own Guardian set, and proceed with an upgrade as a Guardian they controlled.

The funds at risk: bridge TVL in the hundreds of millions. Wormhole verified and patched **the same day**. satya0x received $10,000,000 — the largest single bounty payout in Web3 history at the time.

**Lessons**:
- Uninitialized proxy implementations remain a live bug class even years after the Parity multisig story (see [[Tuan-05-Vulnerability-Classes-Part-1]] §4.4).
- Same-day patches are possible when the protocol has a competent ops team. Triage speed correlates with payout speed.
- The capped payout structure works: $10M is generous, but Wormhole's funds-at-risk justified higher — they paid the cap and the system did its job.

Source: Immunefi Medium, "Wormhole Uninitialized Proxy Bugfix Review".

### 10.2 pwning.eth / Aurora — the $6M nETH bug

**April 26, 2022**. `pwning.eth` disclosed an infinite-mint bug in Aurora, the EVM running on NEAR. The exit-to-NEAR mechanism let an attacker take ETH value from the caller, trigger the exit event in `ExitToNear`, send nETH back to the caller, and then redeposit the nETH into Aurora EVM through the Aurora Bridge — effectively doubling their balance. Compoundable.

Aurora's nETH pool on NEAR held ~70,000 ETH (~$200M at the time). Aurora paid $6M.

**Lessons**:
- Cross-VM / cross-chain integration is a goldmine for bugs that nobody else is looking at. The intersection of NEAR's runtime and Aurora's EVM was novel and underaudited.
- Deep protocol knowledge wins. The Immunefi writeup explicitly notes the bug "incurs the complex integration logic of NEAR and Aurora runtimes and such a discovery was impossible without deep analysis."
- The lesson for you: pick a niche that requires deep expertise (cross-chain, restaking, specific DeFi math). General-purpose hunters get outcompeted; specialists find what nobody else can.

Source: Immunefi Medium, "Aurora Infinite Spend Bugfix Review: $6m Payout".

### 10.3 Gerhard Wagner / Polygon — the $2M Plasma bridge bug

**October 5, 2021**. Wagner disclosed a double-spend bug in Polygon's Plasma Bridge. The attack: deposit ETH through the bridge, start the withdrawal process, wait a week, resubmit the same withdrawal with a **modified first byte of the branch mask**. The withdrawal cleared again. Repeatable up to 223 times per single deposit.

$850M was at risk in the bridge. Polygon paid $2M — at the time, the largest DeFi bounty.

**Lessons**:
- Bridge merkle-proof verification bugs are a recurring class. The Nomad bug (2022) was a different proof-verification miss; same family. Read the Wormhole, Nomad, Ronin, Poly Network case studies as a set; they map the bridge attack surface.
- The "modify a byte of the branch mask" detail is the kind of thing that you find only by reading the verification logic at the byte level. Read the *production code* of bridges and trust nothing about Merkle proofs without confirming the verification covers every byte.
- A $2M payout against $850M at risk is a ~0.24% rate. The 10% cap was clearly not in force here — protocol caps vary. Always read the cap.

Source: Cointelegraph / FinanceFeeds / Immunefi.

### 10.4 c0ffeebabe.eth / Curve — the MEV-bot white-hat play

**July 30, 2023**. A Vyper compiler bug (reentrancy lock failure in specific Vyper versions) was discovered to affect Curve liquidity pools. An attacker began draining $69M from various Curve pools. **The exploit was visible in the mempool**.

`c0ffeebabe.eth`, a known MEV searcher, ran a bot that front-ran the attacker's transactions on the CRV/ETH pool and the Metronome msETH pool — extracting $5.3M and $1.6M respectively from the exploit paths *before the attacker could*. c0ffeebabe.eth then returned the funds to Curve and Metronome.

**Lessons**:
- The "white hat MEV" play is a genuinely legitimate response to ongoing exploits. It requires: pre-existing MEV infrastructure, the ability to recognize the attack pattern in real time, and the willingness to send funds back (which is socially enforced — not legally).
- This is **not** a bounty hunt; it's an emergency response. The bounty norm of "submit before exploiting" doesn't apply — the bug is being actively exploited by someone else. You're racing the original attacker to limit damage.
- The line is razor-thin between "white hat MEV operator who returns funds" and "MEV bot that extracts funds and keeps them". Reputation and provable on-chain behavior is the only enforcement.
- If you find yourself in this position, **immediately publicly commit to returning funds** (a tweet from a known account, an on-chain message). Then deliver. Anything else is theft.

Source: The Block, "MEV bot runner 'c0ffeebabe.eth' returns $5.4 million amid Curve exploit"; Cointelegraph; Hacken.

### 10.5 "Mr. White Hat" / Poly Network — the awkward $611M return

**August 10, 2021**. An attacker exploited a cross-chain access-control bug in Poly Network and drained ~$611M across multiple chains. The next day, the attacker announced they planned to return the funds. Poly Network labeled them "Mr. White Hat", offered a $500k bounty and "chief security advisor" role. Over 15 days, the attacker returned essentially all the funds.

The community reaction was mixed: many in the security world objected to the "white hat" label, arguing it normalizes the steal-first-negotiate-after pattern. The attacker ultimately refused the bounty and asked it be reinvested in the cybersecurity community.

**Lessons**:
- The Poly Network outcome was *post-hoc* whitehat reclassification. This is not a model to emulate. Exploiting first and negotiating later is **theft until proven otherwise**, even if funds eventually return. The legal and ethical risk is enormous.
- The bounty system exists to prevent this exact dynamic. If you find a bug, **submit via the platform first**. Always. The Poly Network attacker had the technical skill to be a top hunter; they chose a path that risked their freedom for, ultimately, zero financial gain.
- The "we'll pay you a bounty and hire you" pivot from protocols under duress is real but does not legitimize the original action. If you are tempted by this path: don't. The reputational ceiling is permanently lower; the legal exposure is permanently higher.

Source: Wikipedia, Poly Network exploit; FinTech Magazine timeline; multiple news sources.

### 10.6 Bonus: Saurik / Optimism — the $2M deep-EVM bug

`Saurik` (Jay Freeman of Cydia/Cycript fame) disclosed a critical in Optimism that earned $2M. The bug was deep in the rollup's L1↔L2 message-passing logic.

**Lessons**:
- Cross-domain bugs in rollups are an underhunted surface. See [[Tuan-11-L2-Rollup-Modular-Security]].
- Reputation compounds. Saurik came in from the iOS security world and crossed over; many bounty millionaires have prior reputations in adjacent fields. **Your audit-competition results and case-study repo work in this course are exactly the kind of reputation that makes a bounty hunt 2x more likely to result in a "we'll take your call seriously" response from protocol teams.**

---

## 11. Lab — three exercises

### 11.1 Lab task structure

You will spend 4–6 hours on these. They are *reading* exercises mostly; the goal is to train your eye for the bounty-vs-contest distinction.

~/web3-sec-lab/wk-bonus-bounty/ ├── 01-read-disclosures/ │ └── notes.md # Structured notes on 10 disclosures ├── 02-program-survey/ │ └── target.md # Your chosen program + 5 things to check first └── 03-immunefi-format/ └── README.md # An earlier PoC reformatted as a bounty submission


### 11.2 Lab 1: Read 10 public Immunefi disclosures

Go to `medium.com/immunefi` (the Immunefi Medium blog). Filter for "Bugfix Review" posts. Read at least 10, ideally spanning different protocol types (DEX, lending, bridge, staking, L2). For each, capture:

| Field | Notes |
|-------|-------|
| Protocol | (e.g., Wormhole) |
| Date | (e.g., 2022-02-24) |
| Severity assigned | (Critical / High / etc.) |
| Bounty paid (USD) | (e.g., $10,000,000) |
| Bug class | (uninitialized proxy / reentrancy / oracle / etc.) |
| Funds at risk | (in USD) |
| Time-to-patch | (hours / days) |
| What made the PoC convincing? | (one sentence) |
| What would you have missed? | (one sentence — honest self-assessment) |

By the end of this exercise, you should be able to recognize the "shape" of a Critical disclosure on sight: where the impact is quantified, where the PoC sits, how the writeup positions the finding.

Suggested starter list (search for these on the Immunefi Medium):
1. Wormhole Uninitialized Proxy ($10M)
2. Aurora Infinite Spend ($6M)
3. Polygon Plasma Bridge ($2M)
4. Optimism (Saurik, $2M)
5. Sushi MISO ($350k)
6. ChainSwap ($1M+ multi-bridge)
7. Lido Bug Fix Review ($2M)
8. The Graph ($2.5M)
9. dForce ($60k for an underflow)
10. Any 2024–2025 review (read the latest 2–3 to see current style)

### 11.3 Lab 2: Pick one live program and write down 5 things to check first

Go to `immunefi.com/bug-bounty/` (or `cantina.xyz/bounties` or `code4rena.com/bounties`). Pick **one** program — not a tiny one, not the absolute biggest. Aim for: $500k–$10M max bounty, broad scope, recent activity.

For that program, write down:

1. **The exact scope.** Which contract addresses? Which repos/commits?
2. **The bounty formula and cap.** Critical pays how much? What's the formula?
3. **KYC threshold and rules.**
4. **Five specific things you'd check first** if you were going to hunt this program for a week. Be concrete: not "look for reentrancy" but "the `claimRewards()` function in `RewardDistributor.sol` lines 142–168 calls into user-supplied token contracts — check CEI and lock state".
5. **Audit reports linked.** What did they cover? What did they not cover? What was acknowledged-but-not-fixed?

You will *not* hunt the program. You will just produce this list. The skill being trained: program-evaluation speed.

### 11.4 Lab 3: Reformat one of your earlier PoCs as an Immunefi submission

Take one PoC from earlier weeks (the reentrancy PoC from [[Tuan-05-Vulnerability-Classes-Part-1]] is a natural choice). Repackage it as if you were submitting it to Immunefi:

1. **Make it a self-contained Foundry project**: clone-and-run in <60 seconds.
2. **Write the README** in the §6.3 structure: Summary, Severity, Funds at Risk, Attack Cost, Reproduction, Technical Details, Suggested Mitigation, Disclosure Timeline.
3. **Quantify impact in USD**: even though this is a toy vault, invent a realistic TVL ("assume the vault holds 1,000 ETH at $3,000/ETH = $3M") and walk through the drain math.
4. **Cite VSCS**: which severity tier and why (with rubric quote).
5. **Suggest mitigation in code**: a diff showing what the fix would look like.

The deliverable is a directory you could literally submit (if the vault were real and in-scope). Test the "60-second reproduction" claim: clone your own directory in a fresh terminal, follow your own README, see if it works.

### 11.5 Stretch: shadow a live disclosure

If you have time and a Twitter/X account: follow @immunefi, @code4rena, several known bounty hunters (`samczsun`, `pashov`, `0xfoobar`, `c0ffeebabe.eth`, etc.). When a disclosure or exploit happens in the next month, read the writeup on the day it publishes. Note what would have made you reach for the same finding *before* the writeup gave it away. Over months, this is how you internalize the actual decision-points of senior hunters.

---

## 12. Anti-patterns (add to master checklist)

- [ ] Hunting on a program without reading scope carefully → finding goes out-of-scope.
- [ ] Testing on mainnet → MEV bots eat your finding.
- [ ] Submitting without a working PoC → instant downgrade or rejection.
- [ ] Not pinning the fork block → "could not reproduce".
- [ ] Quantifying impact in tokens, not USD → severity dispute.
- [ ] Quoting "novelty" instead of "damage" → severity dispute, lose.
- [ ] Leaking findings on Discord/Twitter before patch → reputational and legal hazard.
- [ ] Skipping the audit reports → submitting a known issue.
- [ ] Submitting the same finding to multiple platforms → bans from all.
- [ ] Accepting "design choice" without engaging the user-harm vector.
- [ ] Not invoking Immunefi mediation when severity is disputed (mediation is free — use it).
- [ ] Lawyering up before mediation (alienates the protocol unnecessarily).
- [ ] Receiving payout in a volatile token, holding it through a 60% drawdown → tax owed on income you no longer have.
- [ ] Using a wallet with mixer/sanctioned history → payout held.
- [ ] Going public with an unresolved dispute → makes future bounties harder (protocols share notes).

---

## 13. Trade-offs

| Decision | Option A | Option B | Auditor's view |
|----------|----------|----------|----------------|
| Hunting style | Deep on one program (4–8 weeks) | Survey many programs | Hybrid: one primary, two secondaries. Pure-deep can yield nothing; pure-survey yields informationals. |
| Bounty platform | Immunefi (most volume, KYC, large bounties) | Hats Finance (decentralized, pseudonymous, smaller) | Immunefi for serious income, Hats for niche / pseudonymous work. Don't ignore HackerOne and Cantina either — they each have programs the others don't. |
| Disclosure cadence | Submit immediately, polish later | Wait until polished | Submit immediately. First-to-report wins. Polish in the next message. |
| Severity claim | Always claim the highest plausible | Claim conservatively, hope they bump up | Claim accurately with rubric citation. Inflated claims hurt your reputation; conservative claims sometimes leave money on the table. The middle ground is your real-world severity reading. |
| Public profile | Pseudonymous (handle only) | Real name | Pseudonym for public, real ID for KYC. The Immunefi Hall of Fame works in handles. Real-name hunters are over-represented at the firm-employed tier. |
| Income concentration | 100% bounty | Bounty + contest + audit firm | Diversify when starting. Bounty income is *extremely* variable. Pair it with contests (more predictable monthly cash flow) until you have ~$300k+ banked. |
| Token vs stablecoin payout | Take whatever the protocol pays in | Always convert to stablecoin on receipt | Stablecoin on receipt for tax-base reasons. Take native tokens only if you genuinely believe in the project's medium-term value and can hold without it derailing your tax planning. |
| Single bug class focus | "I'm the reentrancy guy" | Generalist | Single-class specialists win the deepest bugs and the highest payouts at the cost of program flexibility. Generalists hunt more programs at lower hit rate. Either path is viable; pick one based on your temperament. |

---

## 14. Quiz (≥80% to advance)

1. Q: A bug that requires the protocol's 7-of-11 multisig to act maliciously can theoretically drain all user funds. What's the likely VSCS severity?
   A: Likely High or Medium, not Critical. Per VSCS, attacks requiring "elevated privileges" are subject to downgrade. A 7-of-11 multisig is *significantly elevated* compared to a single EOA, but not impossible. Defend whichever way you submit, but expect a fight if you call Critical.

2. Q: What's the difference between "permanent freezing" (Critical) and "temporary freezing" (High) of funds?
   A: Permanent = cannot be recovered without contract redeployment / governance migration / hard fork. Temporary = recoverable by admin action or eventual paused-function reactivation. The distinguisher is "does the protocol have any in-band fix?"

3. Q: You find a Critical, write a PoC, and want to submit. The protocol's Discord has a public security channel. What do you do?
   A: Submit through Immunefi only. Do not post in Discord, do not DM team members, do not tweet. The bounty platform is the contractual channel; everything else is leak surface.

4. Q: Your fork-based PoC uses block 18_500_000. The protocol triager reports "we ran it on the latest block, can't reproduce". Whose fault?
   A: Yours, partially — you should have made the block requirement loud in the README. Also theirs, partially — the PoC instructions said to pin the block. Fix: re-run on their preferred recent block to confirm the bug still exists, and document the state difference if any.

5. Q: A protocol closes your report as "already known". What's the next step?
   A: Per Immunefi policy, demand evidence: a prior bug report, GitHub issue, PR, or other documented mention pre-dating your submission. If they can't produce it, request mediation through Immunefi.

6. Q: You're paid $200,000 in USDC for a critical. You're a US tax resident. Generally, what's the tax treatment?
   A: Generally ordinary income at the USD value of receipt ($200,000), reportable as self-employment / 1099 income depending on circumstances. Subsequent appreciation/depreciation of USDC vs USD is functionally nil. **[verify with a tax professional]**.

7. Q: A black hat exploit is happening *right now*, visible in the mempool. You see the same bug, can front-run with an MEV bot, can extract the same funds. What's the responsible play?
   A: If you have the infrastructure and skill: extract funds via front-running, **publicly commit to returning them immediately** (verifiable on-chain message or tweet from known handle), and return them to the protocol when they're ready to receive. This is the c0ffeebabe.eth play. If you don't have the infrastructure: don't fake it; you'll lose the race and look bad.

8. Q: Why does Immunefi automatically downgrade attacks that require another protocol to behave a certain way?
   A: To distinguish "this protocol is buggy" from "this protocol composes with another that's buggy". The downgrade is one severity tier. Argue against it only when the cross-protocol dependency is an explicit integration (B is hardcoded into A's design), not an arbitrary external dependency.

9. Q: A finding's PoC drains $50M of TVL from a protocol whose max bounty is $1M. What do you get paid?
   A: $1M, the cap. The 10%-of-funds-at-risk formula would compute $5M, but the cap is hard. Always read the cap before deciding how much time to spend on a program.

10. Q: You disagree with a severity downgrade and the protocol won't budge. Mediation is available. What stops you from invoking it on every disagreement?
    A: Time (mediation can take 2–6 weeks) and relationship cost (protocols remember). Invoke when the dollar gap is material (>$10k) and the rubric clearly supports your position. Don't invoke on a $1k margin or when your position is debatable.

---

## 15. Deliverables

- [ ] Lab 1: notes.md with 10 Immunefi disclosure summaries.
- [ ] Lab 2: target.md with one chosen program + 5 specific check-items.
- [ ] Lab 3: reformatted PoC as a clone-and-run Immunefi-style submission directory.
- [ ] Personal: a one-page document with **your** bounty hunting plan — which programs you'd target first, what bug classes you specialize in, what your income mix is (bounty vs contest vs audit-firm).
- [ ] Master checklist (§12) merged into [[audit-checklist-master]].
- [ ] Severity rubric notes merged into [[severity-rubric-immunefi-c4]].

---

## 16. Where this leads

This bonus closes the practical loop with [[Tuan-Bonus-Audit-Competition-Playbook]] — together they cover the two major *income streams* of independent Web3 security work. The remaining bonus chapters ([[Tuan-Bonus-Non-EVM-Solana]], [[Tuan-Bonus-Formal-Verification-Deep]], [[Tuan-Bonus-ZK-Circuit-Security]], etc.) extend your *attack surface*: bounty programs increasingly span non-EVM chains, ZK circuits, and L2 stacks; specialization here directly raises your bounty hit rate.

A practical sequencing for someone optimizing for income:

1. Finish the 16-week core (you're an auditor).
2. Do **competitions** for 2–3 months: build a public profile, learn the contest grind, accumulate $5–30k in winnings while reputation builds.
3. Transition to **bounties** with one primary program at a time, parallel to one ongoing competition stream.
4. As bounty income stabilizes, layer in **direct audit engagements** through firms or your own consulting.
5. Pick a deep specialty (cross-chain, restaking, ZK, perps math) — this is where the $10M findings live.

The big payouts in this lesson are real. They are also rare, and the path to them is *boring*: read code, write PoCs, file reports, dispute downgrades, get paid, repeat. The dramatic stories are the survivorship bias on top of months of quiet hunting that turned up informationals and mediums.

But here's the closer: the bug bounty system has paid out **over $110M to whitehats** as of 2025, **$25B+ in user funds protected** [verify: Immunefi figures]. You can be a part of that. The first $20k bounty is a 6-month grind for most; the second is a 6-week grind; the third doesn't surprise you anymore. The skill is real, the income is real, and the work matters.

---

*Last updated: 2026-05-16*
*See also: [[MOC-Web3-Security-Mastery]] · [[Tuan-Bonus-Audit-Competition-Playbook]] · [[Tuan-15-Audit-Methodology-Tooling]] · [[Tuan-16-Report-Writing-Capstone]] · [[severity-rubric-immunefi-c4]] · [[audit-report-template]] · [[Tuan-05-Vulnerability-Classes-Part-1]] · [[Case-Wormhole-2022]] · [[Case-Poly-Network-2021]] · [[Case-Curve-Vyper-Compiler-2023]]*

lthieu's notes

Explorer

Tuan-Bonus-Bug-Bounty-Immunefi