/web3-triage-report

name: web3-triage-report
description: Bug triage validation system, Immunefi report format, and 20 real paid bounty examples dissected. Use this when validating a finding before submitting, writing an Immunefi report, checking if a bug is actually valid, or studying real examples of paid vulnerabilities.

TRIAGE, REPORT WRITING & REAL EXAMPLES

---

PART 1: TRIAGE

THE 7-QUESTION GATE

Ask these IN ORDER before writing a single word of your report. ONE wrong answer = STOP and move on.

---

Q1: Can an attacker use this RIGHT NOW, step by step?

Complete this template:

1. Setup:   [what I need]
2. Call:    [exact function, exact params]
3. Result:  [what I have that I didn't have before]
4. Cost:    [gas + capital]
5. ROI:     [profit / cost ratio]

If you cannot complete steps 2 and 3 with specific function calls: **KILL IT.**

---

Q2: Is the impact in the program's accepted impact list?

Go to the Immunefi program page. Find "Impacts in Scope." Match your bug to one of these EXACTLY.

Example impact tiers:

• "Direct theft of any user funds" — Critical
• "Permanent freezing of funds" — Critical
• "Protocol insolvency" — Critical
• "Theft of unclaimed yield" — High
• "Permanent freezing of unclaimed yield" — High
• "Temporary freezing of funds" — High
• "Smart contract unable to operate due to lack of token funds" — Medium
• "Griefing (no profit motive, but damage to users)" — Medium
• "Contract fails to deliver promised returns, but doesn't lose value" — Low

If your bug does not match any impact in scope: **KILL IT.**

---

Q3: Is the root cause in an in-scope contract?

Confirm the exact deployed address is in scope on the program page.

If the bug is in Aave, Uniswap, OpenZeppelin, or any external dependency: **KILL IT.**

---

Q4: Does it require admin/privileged access?

"Admin can drain funds" = centralization risk = **KILL IT.** "Admin can set parameter X which under condition Y creates DoS" = borderline.

Salvage path: can the bug trigger WITHOUT the admin doing anything unusual?

• If yes: valid
• If no: likely invalid (requires admin mistake — almost always out of scope)

---

Q5: Is this already known/acknowledged in prior audits?

Find the audit reports for the protocol. Search for "Risk Accepted," "Acknowledged," "Won't Fix."

If your bug matches a known finding: **KILL IT.**

Edge case: if acknowledged finding + NEW code around it creates a new attack path → that is a new bug, not the acknowledged one. Must prove the new path.

---

Q6: Is the economic attack viable?

Attacker spends: gas + capital
Attacker gains: tokens stolen or protocol damaged

If profit < cost: KILL IT.

Example:

• DoS via dust harvest: costs 1 wei USDC + gas, disables yield for $81K TVL → VIABLE.
• Withdraw-fee arbitrage: fee (0.1%) > diluted yield from attack → NOT profitable → KILL IT.

---

Q7: Is this already public?

• Is it on social media or in a disclosed report?
• Was it previously submitted and disclosed?
• Is the "sensitive" data visible in the UI already?

If yes: **KILL IT.**

---

THE SEVERITY MATRIX

Score = Impact × Likelihood × Exploitability (each 1–3)

| | Impact=1 (info leak) | Impact=2 (partial) | Impact=3 (theft/freeze) | |--|--|--|--| | L=1 E=1 | 1 (Info) | 2 (Low) | 3 (Low) | | L=2 E=2 | 4 (Medium) | 8 (High) | 12 (High) | | L=3 E=3 | 9 (High) | 18 (Critical) | 27 (Critical) |

**Rule: When borderline, round DOWN. Over-classification destroys credibility.**

---

THINK LIKE AN ATTACKER TEMPLATE

Before writing your report, fill in this attack scenario:

Protocol: [name]
Target contract: [address + function]
Preconditions: [what state must exist?]
Attack sequence:
  1. Attacker calls [exact function] with [exact params]
  2. [What happens in the contract]
  3. [What state changes]
  4. Attacker ends up with: [X more tokens / broken state / DoS]
Total cost: [gas estimate + capital requirement]
Total gain: [$X stolen / $Y TVL frozen]
Viable? [yes/no + reason]

If you can't fill in steps 1–4 with specific values, the bug is not ready to submit.

---

THINK LIKE A TRIAGER CHECKLIST

A triager reviewing your report will immediately check:

• [ ] Does the title match an accepted impact?
• [ ] Is the vulnerable function clearly identified (file + line)?
• [ ] Is the root cause explained (not just "there is a bug")?
• [ ] Is there comparison evidence ("function A has this, function B doesn't")?
• [ ] Does the PoC run without errors?
• [ ] Is the severity appropriate to the actual impact?
• [ ] Is the bug already in the known issues list?
• [ ] Does the fix make sense (proves you understand the root cause)?

If your report can't pass this checklist: revise before submitting.

---

SEVERITY DOWNGRADE TRIGGERS

| Condition | Severity drops | |-----------|---------------| | Requires specific admin configuration | -1 level | | Impact limited to a small subset of users | -1 level | | Requires long time window (>24h) to exploit | -1 level | | Protocol can detect and pause before loss | -1 level | | Impact is yield loss, not principal loss | -1 level | | Bug is theoretical with no practical attack | Down to Info | | Attack costs more than attacker gains | Invalid |

---

VALID vs INVALID COMPARISON TABLE

| Bug | Valid? | Reason | |-----|--------|--------| | DISTRIBUTOR_ROLE never granted → claimFor() permanently uncallable | **Valid (Medium)** | Deployment bug, not admin action, real impact on users | | `- 1` strands 1 wei per harvest | **Valid (Low/Info)** | Real, quantified, honest about minor impact | | Front-run harvest (acknowledged in prior audit) | **Invalid** | Known issue = instant rejection | | Admin can change fee to 100% | **Invalid** | Centralization risk = almost always OOS | | Harvest DoS via dust (requires admin misconfiguration) | **Borderline** | Must prove it triggers without unusual admin action | | ecrecover returns address(0) = anyone can pass | **Valid (Critical)** | No precon