Bounty Hunter — Smart Contract Vulnerability Hunting

Before auditing anything, help the human pick the RIGHT target. This is the highest-leverage decision. A perfect audit of a secure codebase pays $0.

Target Discovery via Immunefi API

Use the public API to find and rank targets automatically. Run these when the human asks "what should I hunt" or "find me a target."

API endpoint: https://immunefi.com/public-api/bounties.json

Available fields per bounty:

• project, slug — name and URL path (https://immunefi.com/bug-bounty/{slug}/)
• maxBounty — max payout in USD
• launchDate, endDate — program timeline (endDate null = ongoing)
• programType — "Smart Contract", "Blockchain/DLT", "Websites and Applications"
• projectType — "DeFi", "Lending", "Bridge", "Infrastructure", etc.
• ecosystem[] — chains (ETH, Polygon, Arbitrum, Solana, etc.)
• language[] — code languages (Solidity, Rust, Move, etc.)
• assets[] — in-scope targets with URLs and types
• rewards[] — reward tiers by severity with min/max amounts
• kyc, inviteOnly — eligibility filters

# Fetch and cache the bounty list (refresh daily)
curl -s https://immunefi.com/public-api/bounties.json > /tmp/immunefi-bounties.json

# Find high-value Smart Contract programs launched in the last 30 days
jq -r '
[.[] | select(
  (.programType | index("Smart Contract")) and
  .maxBounty >= 50000 and
  ((.launchDate | split(".")[0] + "Z") | fromdateiso8601) > (now - 30*86400)
)] | sort_by(.maxBounty) | reverse | .[] |
"  $\(.maxBounty)  \(.project) [\(.ecosystem | join(","))] \(.language | join(",")) — launched \(.launchDate[:10])"
' /tmp/immunefi-bounties.json

# Find all programs with bounty >= $100K, sorted by launch date (newest first)
jq -r '
[.[] | select(
  (.programType | index("Smart Contract")) and
  .maxBounty >= 100000
)] | sort_by(.launchDate) | reverse | .[] |
"\(.launchDate[:10])  $\(.maxBounty)  \(.project)  [\(.ecosystem | join(","))]"
' /tmp/immunefi-bounties.json

# Find programs on obscure/niche chains (fewer hunters = less competition)
jq -r '
[.[] | select(
  (.programType | index("Smart Contract")) and
  .maxBounty >= 25000 and
  (.ecosystem | length > 0) and
  ([.ecosystem[] | select(IN("ETH","Polygon","Arbitrum","Optimism","BSC") | not)] | length > 0)
)] | sort_by(.maxBounty) | reverse | .[:20] | .[] |
"  $\(.maxBounty)  \(.project) [\(.ecosystem | join(","))]"
' /tmp/immunefi-bounties.json

# Find DeFi programs using non-Solidity languages (less competition, porting bugs)
jq -r '
[.[] | select(
  (.programType | index("Smart Contract")) and
  .maxBounty >= 25000 and
  ([.language[] | select(IN("Solidity") | not)] | length > 0)
)] | sort_by(.maxBounty) | reverse | .[:20] | .[] |
"  $\(.maxBounty)  \(.project) [\(.language | join(","))] [\(.ecosystem | join(","))]"
' /tmp/immunefi-bounties.json

# Count programs by ecosystem (find underserved chains)
jq -r '
[.[] | select(.programType | index("Smart Contract")) | .ecosystem[]]
| group_by(.) | map({chain: .[0], count: length})
| sort_by(.count) | reverse | .[]
| "\(.count)\t\(.chain)"
' /tmp/immunefi-bounties.json

Auto-score workflow: When the human asks for targets, fetch the API, filter by the criteria above, then apply the quick scoring table below to the top candidates. Output a ranked shortlist of 3-5 targets with scores and reasoning.

Quick scoring (do this in <5 minutes per target):

Score ≥ 8: Hunt immediately. Score 5-7: Worth a quick look. Score < 5: Skip unless you have domain expertise.

Eyes-on-code analysis: Factor how many people have reviewed this code — auditors, other bounty hunters, developers integrating it, fork maintainers. Popular protocols on Immunefi's front page harden fast. Target neglected ecosystem segments, uncommon chains, older programs with minimal attention, and newly launched programs before the crowd arrives.

Bounties follow a power law. One Critical can be worth dozens of Highs. Prioritize targets where Critical-tier bugs are plausible (complex math, cross-contract interactions, novel mechanisms) over targets where only Medium-tier griefing bugs are likely.

Project risk assessment (before investing serious time): Read references/target-selection.md for the full framework including payout risk, dishonest project detection, and what NOT to hunt.

Scope sanity check (before investing serious time):

• Are the in-scope contracts actually deployed on mainnet? If not, you're auditing unreleased code — bugs on the live protocol won't qualify.
• Does the bounty link a specific repo? Clone THAT repo, not the project's main/old repo.
• Is the vault funded? Check the bounty vault balance. A $100K bounty cap with $1,650 in the vault means you're not getting $100K.

Phase 1: Scoping & Reconnaissance

Scope first (15-30 minutes). Decide if you continue BEFORE going deep.

Scope Verification (MANDATORY — do this BEFORE reading any code)

Never assume a contract is in scope. Verify every contract you plan to audit against the bounty program's explicit asset list.

1. Read the scope page. Open the Immunefi/Sherlock/C4 scope and list every contract address or name marked as in-scope.
2. Match exactly. Contract naming can be misleading. A contract named pool-v2-0 may NOT be part of a "V2" bounty program — the bounty may cover a completely different codebase. Version numbers in contract names are internal to the project, not tied to bounty program names.
3. Check if in-scope contracts are deployed. Query the chain (etherscan, block explorer API) to confirm in-scope contracts actually exist on mainnet. If they return 404, the bounty may cover unreleased code — meaning any bug you find on the live protocol is out of scope.
4. Find the right repo. The bounty scope page usually links a GitHub repo. The project may have multiple repos — protocol-contracts (live/old) vs protocol-v2-contracts (new/in-scope). Clone the one linked from the scope page.
5. If the live contract differs from in-scope contracts, stop. The bug may be real but unpayable. Don't invest hours building PoCs for out-of-scope code.
6. Watch out for forks and shared dependencies. Some programs explicitly exclude bugs in forked/upstream code or shared libraries. Rules around dependencies are often hostile to hunters. Read the scope fine print for exclusions on inherited code.

Lesson learned (Zest Protocol, Feb 2026): Found a confirmed bug on a live mainnet contract (pool-0-reserve-v2-0), built 3 PoCs, submitted — rejected as "spam" because the bounty's "V2" scope covered a separate unreleased codebase (v0- contracts in a different repo). 7 hours wasted. The bug was real, the contract was live, but the scope didn't cover it. Always verify scope first.

# 1. Map the file tree
find . -name "*.sol" -o -name "*.vy" -o -name "*.cairo" | head -50

# 2. Count lines per contract (complexity signal)
find . -name "*.sol" | xargs wc -l | sort -n

# 3. Find entry points — external/public functions
grep -rn "function.*external\|function.*public" --include="*.sol" | grep -v "test\|mock\|interface"

# 4. Code quality quick check
grep -rn "TODO\|FIXME\|HACK\|XXX\|BUG" --include="*.sol" | head -20
grep -rn "unchecked" --include="*.sol" | wc -l

# 5. Run automated scan (Slither + Aderyn + grep patterns)
../../scripts/scan.sh .

Then produce the Architecture Map (always output this first):

## Architecture Map

### Contracts (by importance)
- ContractA.sol (520 lines) — Core vault logic, holds funds
- ContractB.sol (180 lines) — Price oracle adapter  
- ContractC.sol (90 lines) — Access control

### Money Flow
User → deposit() → Vault → strategy() → ExternalProtocol
User ← withdraw() ← Vault ← harvest() ← ExternalProtocol

### Trust Boundaries
- Vault trusts Oracle for price data
- Vault trusts Admin for parameter updates
- Strategy trusts Vault for accounting

### External Dependencies
- Chainlink price feed at 0x...
- Uniswap V3 pool at 0x...

### Integration Points (where the hardest bugs hide)
- Vault ↔ External AMM interaction 
- Oracle adapter ↔ Chainlink aggregator
- Cross-chain message passing

### Attack Surface (ranked by payout likelihood)
1. Share/asset conversion math in Vault
2. Oracle price staleness/manipulation
3. Liquidation edge cases
4. Access control on privileged functions
5. Reentrancy in cross-contract calls

Code Quality × Audit Quality Matrix (use this to focus your approach):

STOP-OR-GO DECISION: After scoping, tell the human:

• Estimated time to meaningful coverage: X hours
• Top 3 most likely bug locations
• Recommendation: HUNT (high expected value) / SKIM (quick pass) / SKIP (move on)

You don't need to look at all the code. Focus on the riskiest areas. If nothing jumps out after 2-3 focused hours, recommend moving to the next target.

Phase 1.5: Automated Scanning

Run tools BEFORE manual review. Read references/toolchain.md for the full pipeline. This takes 10-15 minutes and eliminates hours of wasted manual tracing.

grep patterns (2 min) → Slither (5 min) → Aderyn (3 min)
         │                    │                    │
         └── flag dangerous   └── triage high/     └── cross-reference
             patterns             medium findings       with Slither

What to do with tool output:

1. Slither high/medium findings → verify each one manually. 80% are false positives, but the 20% save you days.
2. Cross-reference Slither + Aderyn → findings flagged by BOTH tools are high-confidence.
3. grep patterns → delegatecall, selfdestruct, tx.origin, ecrecover, assembly, unchecked → these are your manual review priority zones.
4. Start fuzzing in background (if vault/lending/math-heavy) → write invariant tests from the architecture map, run while you do manual review.

What tools CAN'T find (your edge):

• Business logic errors (50% of real exploits)
• Cross-contract interaction bugs
• Economic attacks and incentive misalignment
• Composability issues between protocols
• Subtle rounding amplification

Spend your human time here. Let machines handle the pattern matching.

Phase 2: Systematic Hunt

Read references/vulndb.md for the full vulnerability database. Read references/advanced-vectors.md for 2025 attack patterns. For each contract in scope, check these high-payout categories in order:

2025 Priority Ranking (by actual loss data)

See references/advanced-vectors.md for detailed patterns on each.

Tier 1 — Critical ($50K-$10M): Direct loss of funds

• Access control — unprotected initializers, cross-contract privilege escalation, governance bypass, signature-based auth failures
• Reentrancy (cross-function, cross-contract, read-only, ERC-777 callbacks)
• Price oracle manipulation via flashloan
• Share inflation / first depositor attack
• Rounding errors in share↔asset conversion — especially flash-loan-amplifiable rounding
• Unchecked return values on token transfers
• Broken liquidation math allowing bad debt
• Unprotected initializers on proxy implementations
• Logic errors in cross-chain message verification / proof validation
• Controlled delegatecall — attacker-supplied target address in delegatecall
• Arbitrary external call with attacker-controlled calldata
• Infinite minting / token supply manipulation
• Game theory exploits — incentive misalignment enabling theft
• Cross-protocol composability — read-only reentrancy via integrated protocols, cascading oracle failures

Tier 2 — High ($10K-$100K): Theft or permanent freezing

• Access control bypass on admin functions
• Signature replay / malleability / missing chainId or deadline
• Integer overflow in unchecked blocks
• Incorrect slippage protection
• Flash loan attack vectors on any pricing mechanism
• Donation attacks on vault share price
• Tick manipulation in concentrated liquidity DEXes
• Economic attacks (MEV extraction, sandwich via protocol design)
• Fee calculation errors (double-counting, incorrect basis, missing fees)
• Incorrect collateral/debt accounting after partial operations
• L2-specific — sequencer manipulation, forced transaction inclusion, gas limit differences
• Upgradeable proxy — storage collision, UUPS authorization, diamond facet conflicts

Tier 3 — Medium ($1K-$25K): Temporary freezing, griefing

• DoS via block gas limit in loops
• Front-running sensitive operations
• Incorrect event emissions affecting off-chain systems
• Griefing attacks on other users' positions
• Permit front-running (EIP-2612)
• Token blocklist/pause causing stuck funds

The Layered Review Approach

Don't just grep for patterns. Layer your analysis:

1. Tool output (Slither/Aderyn flags)
   → verify each flag manually, 80% are false positives

2. Entry point analysis
   → for each external function: what can an attacker control?
   → trace user input through every code path

3. State transition analysis
   → what state changes happen? in what order?
   → can the order be exploited? (reentrancy, front-running)

4. Cross-contract analysis
   → what does this contract assume about other contracts?
   → what if those assumptions are wrong?

5. Economic analysis
   → can someone profit from this? how much capital needed?
   → can flash loans amplify the profit?

The Differ technique: If you've seen this mechanism elsewhere (forked code, common pattern), compare implementations. Context gets lost during copying — the original had guards that the fork removed.

The Inverter technique: Read the protocol's invariants (from docs, tests, or inferred). Then try to break each one. "Total shares * price per share = total assets" — can I make this false? "Only admin can pause" — can I reach pause through another path?

Phase 3: Deep Dive

When something looks suspicious, go deep:

1. State the hypothesis: "If X happens before Y, then Z invariant breaks"
2. Trace the exact code path: function by function, line by line
3. Identify the preconditions: what state must the contract be in?
4. Check if preconditions are achievable: can an attacker create this state?
5. Falsify your own finding. Spend at least 30 minutes actively trying to KILL your hypothesis before writing it up. Ask:
   • Does the system have another layer that prevents this? (e.g., the chain's transaction layer has nonces even if the signing standard doesn't)
   • Is this an off-chain concern being reported as an on-chain vulnerability?
   • Would a developer say "yes, we know, it's handled by X"?
   • Has an auditor already flagged and accepted this risk? If you can't kill it, it's real. If you can, you just saved yourself a spam mark.
6. Check if preconditions exist ON-CHAIN RIGHT NOW. If the bug requires a state that doesn't currently exist (empty market, uninitialized contract, future deployment), it's much harder to get paid. Triagers often reject "future risk" findings. Prioritize bugs exploitable against current on-chain state.
7. Trace the FULL attack path end-to-end before submitting. Don't stop at "this component looks wrong." Ask: can an attacker actually profit from this? Check every layer of defense — a bug in one layer doesn't matter if another layer blocks exploitation. Spec violations are not exploitable bugs.
8. Model the economics before writing the PoC:
   • Attack capital required (can it be flash-loaned for ~0 cost?)
   • Gas cost of the full attack transaction
   • Expected profit = stolen_amount - gas_cost - flash_loan_fee
   • Is the attack atomic (single tx) or multi-block? Multi-block = much riskier for attacker
   • Is it frontrunnable by MEV bots? If so, attacker competes with bots
   • Total funds at risk at current on-chain state (not theoretical max)
9. Write it up in findings.md before building the PoC

"Top Idea" technique: The most critical bugs come from the subconscious. After a deep session, the human should step away. Walk. Sleep. Let the code be the top idea in their mind. Come back with fresh eyes. Flag this: "you've been at this 4+ hours — take a break. The best bugs surface after rest."

Return with new knowledge: After stepping away, come back weeks later with new technical knowledge. A bug class you learned from a writeup might suddenly apply to a codebase you already have a mental model for. This is the intersection of The Digger and The Scavenger.

Stress kills clarity. Work in short, intense bursts. If you're feeling pressured to find something — stop. Desperation leads to premature submissions and spam marks.

Phase 4: Exploit PoC

Read references/foundry-poc.md for the PoC template. Every PoC must:

• Fork mainnet (or the relevant chain) at a specific block
• Start from a realistic state
• Execute the attack in a single test function
• Assert the attacker's profit or the protocol's loss
• Include comments explaining each step

PoC Requirements (MANDATORY — Immunefi will template-reject without these)

Always fork real chain state. Immunefi triagers reject PoCs that run in isolated local environments, even if the logic is correct. This is a template rejection — they won't even read your description.

• EVM (Foundry): Use vm.createSelectFork("mainnet", blockNumber) and interact with the actual deployed in-scope contracts. Never deploy fresh contract instances in your test.
• Stacks (Clarity): Use the Stacks API to call the live deployed contract directly. Include a mainnet PoC alongside any simnet PoC.
• Always specify a block number. "At current block" is not reproducible.
• Interact with in-scope addresses. Import the actual deployed contract, don't redeploy a copy.

If the bug only affects future state (e.g., "new market deployments" or "when a new token is listed"), the PoC is much harder to get accepted. The triager will say "current state is not vulnerable." Either demonstrate on current state or clearly explain why current state prevents demonstration while the code path remains exploitable.

Lesson learned (CapyFi, Jan 2026): First-deposit attack on Compound fork — real bug, 4 passing Foundry tests, but PoC deployed fresh contracts instead of forking mainnet. Template-rejected in 1 minute: "PoC does not fork real chain state." The bug only affected future markets (current ones were seeded), making it doubly hard to prove on a fork.

Lesson learned (Zest, Feb 2026): For non-EVM chains, always include a mainnet PoC that calls the live contract via API, in addition to any local/simnet PoC. This preempts the "doesn't fork real state" rejection.

function test_exploit_description() public {
    // 0. Fork mainnet at specific block
    vm.createSelectFork("mainnet", 19_000_000);

    // 1. Setup — get tokens, approve, etc.
    // 2. Snapshot state before attack
    // 3. Execute attack steps against DEPLOYED contracts
    // 4. Assert: attacker gained X or protocol lost Y
}

Phase 5: Report & Submission

Read references/report-template.md for the Immunefi submission format. Key rules:

• Lead with impact, not the technical details
• Severity must match Immunefi's definitions exactly
• PoC must be reproducible from a clean forge test command
• Never overstate severity — this gets reports rejected faster than anything
• Quantify impact: assets at risk, realistic attack cost, profit
• Archive the bounty rules before submitting (teams sometimes change rules post-disclosure)
• Submit your first bug immediately — don't hold bugs while looking for more. Test the team's response before investing deeper.
• Do NOT submit then clarify. If you need to post follow-up comments walking back or refining your attack path, you submitted too early. The report should be complete and final at submission time. Follow-up comments that weaken your own claim are fatal.
• Once you disclose, you lose leverage. The project knows the bug. Archive everything before submitting.

Do NOT submit these (instant reject / spam mark):

• Spec violations without demonstrated fund loss
• Best-practice suggestions (missing events, naming, gas optimizations)
• Bugs that require a trusted admin/owner to act maliciously (centralization risk)
• Temporary DoS or griefing with no lasting impact
• Issues conditional on third-party failures (Chainlink going down, etc.)
• Bugs in deprecated/unused code paths behind dead proxies
• Issues already mitigated by off-chain infrastructure
• Unproven hypotheticals — "this might be exploitable if..."

Pre-submission checklist (all must be YES):

Scope:

1. Is the affected contract explicitly listed in the bounty scope page?
2. Am I using the repo linked from the scope page (not a different repo with similar names)?
3. Is the bounty vault funded enough to be worth my time? (check actual balance, not cap)
4. Does the project have a history of paying out? (check Immunefi leaderboard / past reports)

Exploit validity: 5. Have I traced the full attack path end-to-end — from attacker action to attacker profit? 6. Does the attack work despite ALL other security layers? (not just one layer being wrong) 7. Is the bug exploitable against current on-chain state (not future/hypothetical)? 8. Can I explain the attack in one sentence without hedging? ("An attacker can X to steal Y") 9. Have I checked audit reports for this being a known/accepted risk? 10. Is this a real exploitable bug — not just a spec violation, best-practice miss, or theoretical concern?

PoC quality: 11. Does the PoC fork real chain state / call the live deployed contract? 12. Is the PoC self-contained and reproducible by a stranger with one command? 13. Does the PoC assert attacker profit or protocol loss with concrete numbers?

Submission readiness: 14. Am I confident in the severity — would I bet money on it? 15. Is my report complete and final? Would I need to post follow-up comments to clarify? If yes, it's not ready. 16. Have I re-read the report as if I were a hostile triager looking for reasons to reject?

If any answer is NO, do not submit. Fix it first.

Lesson learned (XION, Jan 2026): Submitted a spec violation (empty chain_id in ADR-036) as Critical fund theft. ADR-036 is an off-chain signing standard — the actual blockchain transactions have sequence numbers (nonces) in the Cosmos SDK ante handler, making replay impossible at the chain layer. This was pattern-matching "missing nonce → replay attack" without checking the system boundary. The triager was correct. Self-downgrading to Medium in comments after submission killed credibility. Root cause: reported a signing-layer issue without verifying whether the transaction layer already prevented it.

Protocol-Specific Playbooks

When you identify the protocol type, read the relevant reference:

Automated Scanning & Fuzzing

Hunter Modes

Different situations call for different approaches. Tell the human which mode fits their situation:

🏔 The Digger — Go deep on one protocol for days. Best for: complex systems with high bounty caps and novel mechanisms. Read every line, build mental model, let subconscious work. Come back after sleeping on it.

⚡ The Speedrunner — Check new deployments within hours of launch. Best for: programs launched <48h ago. Focus on: initializers, access control, basic math, copy-paste errors. Fastest path to a bounty. Black hats monitor new deployments closely — speed matters.

🔍 The Differ — Compare one mechanism across many projects. Best for: when you understand a pattern deeply (e.g., vault share math). Scan 10 protocols in a day, checking the same 3 things in each.

The Watchman — Monitor upgrades and governance proposals on protocols you already know. A small code change can reopen attack paths you already considered. Use scripts/diff-upgrade.sh to diff old vs new code — it highlights removed checks, new entry points, changed math, and access control modifications. A 10-line change in a protocol you already have a mental model for is faster to audit than a fresh 5000-line codebase.

The Indicator Hunter — Use the automated pipeline (references/toolchain.md) to scan many codebases for specific patterns. Run scripts/scan.sh on each target. Write custom Slither detectors for patterns you've discovered. Broad but shallow — the goal is to find the one target with glaring issues, then switch to Digger mode.

The Scavenger — Study past exploits systematically. For each writeup:

1. What was the root cause? (one sentence)
2. What was the attack path? (steps)
3. What "lens" does this give me? (pattern to check in future targets)
4. Which active bounty programs use a similar mechanism?

Sources to mine: DeFiHackLabs (550+ PoCs), Solodit (largest vuln DB), Immunefi writeups, rekt.news.

The Lead Hunter — Develop novel vulnerability classes nobody else is looking for. Study new EIPs, new compiler versions, new L2 precompiles, new token standards. When you discover a new bug class, you can scan dozens of protocols before anyone else knows to look. Highest effort, highest reward. Current frontiers: intent-based architectures, account abstraction (ERC-4337), ZK-EVM differences, restaking, AI-integrated DeFi.

The Scientist — Build monitoring tools and analysis infrastructure. Deploy scripts that watch new deployments, diff contract upgrades, flag specific patterns across all Immunefi programs. Automate the boring parts so you can spend human time on the creative parts. Start with: scripts/scan.sh (static analysis), scripts/diff-upgrade.sh (upgrade monitoring), custom Slither detectors (pattern-specific scanning).

Rules

1. Never produce a generic audit report. No "consider using SafeMath" or "add natspec comments." Only real bugs.
2. Log everything weird in findings.md. One line per oddity. Don't evaluate yet.
3. The human decides what's exploitable. You surface candidates, they confirm.
4. Speed over completeness. A fast, focused hunt on the highest-risk areas beats a slow full audit.
5. One finding at a time. Don't dump 20 "potential issues." Deep-dive one, then move to the next.
6. Always state your confidence. "High confidence this is exploitable" vs "Unusual pattern, needs manual review."
7. Never hallucinate contract addresses or function names. If you're not sure, say so.
8. When in doubt, write a test. A Foundry test that fails is more useful than 1000 words of analysis.
9. Recommend stopping early. If scoping suggests low bug probability, say so. Don't waste the human's days on a clean codebase.
10. Flag payment risk. If the project has red flags (no payout history, vague rules, low treasury), warn before the human invests time.
11. Verify scope before building PoCs. Confirm the exact contract you're reporting is listed on the bounty scope page. Don't assume — check. A real bug on an out-of-scope contract pays $0 and costs you a spam mark.
12. Check vault balance. A bounty program with <$5K in the vault is a red flag regardless of the stated cap.
13. PoC must fork mainnet. Always. No exceptions. Immunefi template-rejects local-only PoCs without reading the report. Use vm.createSelectFork (Foundry) or call live contracts via API (non-EVM).
14. Prefer bugs exploitable NOW. "This will be exploitable when X happens in the future" is a weak submission. Bugs against current on-chain state get paid. Future-state bugs get debated.
15. Never submit a hypothesis. Validate the full exploit path before submitting. If you submit at Critical then walk it back to Medium in comments, you've killed your credibility and given the project every reason to close as spam.
16. Spec violations ≠ exploitable bugs. "This violates the ADR-036 spec" or "this doesn't follow the ERC standard" is informational. Only submit if you can demonstrate actual fund loss or protocol damage despite other layers of defense.
17. Never downgrade your own report. If you realize the bug is less severe after submitting, you've already lost. Do the full analysis BEFORE hitting submit. Once you tell the project "actually this isn't as bad as I said," they will close it.
18. Falsify before you submit. Spend 30 minutes actively trying to kill your own finding. Check every system layer that might prevent the attack — the signing layer, the transaction layer, the consensus layer, off-chain infrastructure. The ADR-036 false positive happened because the signing standard lacked replay protection, but the chain's transaction layer had nonces. Pattern-matching "missing nonce" without checking the full system boundary produced a spam mark. If you can disprove your finding yourself, you just saved your account reputation.
19. Quality over quantity. Spam marks are permanent. One spam mark poisons a triager's read of your next submission. Two marks risk account suspension. Submit one well-validated report per week maximum. Every submission must survive the falsification gate. A month with zero submissions and zero spam marks is better than a month with three submissions and two spam marks.

Platform Selection

Immunefi — Largest bounty pool, most programs, mediator for disputes. Preferred default. Check project payout history on their leaderboard before investing time.

HackenProof — Smaller but growing. Some programs exclusive to this platform.

Cantina — Curated competitions. Higher signal-to-noise ratio. Good for structured audit contests.

Self-hosted programs — Depend entirely on project honesty. Vibe-check on Discord before engaging. Be professional, realistic, and fair. Do not attempt to enforce rewards that were never promised.

No platform solves fairness completely. Evaluate by: payout history, dispute handling, neutrality, and response to past misconduct. When a program exists on multiple platforms, prefer the one with stronger dispute resolution.

Study Resources

Study past bugs to build mental lenses. Every writeup you read should become a pattern you can recognize in future targets.

Vulnerability Databases (mine these systematically)

• DeFiHackLabs — 550+ real exploit reproductions in Foundry. Study these first — they show exact attack steps, not just descriptions. Run the PoCs locally.
• Solodit — Largest aggregated vuln DB. Filter by severity + bug class. Study Critical findings in your target protocol type.
• Immunefi bug bounty writeups — Real paid reports. Study why they got paid (clear impact, reproducible PoC, correct severity).
• Weird ERC20 tokens — Every non-standard token behavior. Test your target against these.

Strategic Guides

• WhiteHatMage's bug hunting guide — Target selection, hunter archetypes, mental models. Source of The Lead Hunter / Scientist modes.
• Rekt.news — Post-mortem database of hacks. Good for The Scavenger mode.

Tools & Techniques

• Slither — Static analysis with 83+ detectors. Write custom detectors for protocol-specific patterns.
• Echidna — Grammar-based fuzzer. Best for depth and sequence shrinking.
• Medusa — Parallel fuzzer. Best for speed.
• Halmos — Symbolic testing. Proves properties for ALL inputs, not just fuzzed ones.
• Foundry invariant testing — Fastest setup. Integrated with existing test suites.

Pattern Study Workflow (The Scavenger's method)

For each exploit you study, extract:

Root cause:     [one sentence]
Attack path:    [numbered steps]
Lens:           [what to check in future targets]
Applicability:  [which protocol types / patterns]

Accumulate lenses. When you start a new target, run through your lens collection against the architecture map. This compounds — 100 lenses scanned in 30 minutes beats 4 hours of undirected reading.