Security Bug Bounty

4. Impact

• Quantify impact: fund loss, privilege escalation, permanent DoS, data exfiltration, or integrity break. Estimate worst-case loss and affected users/scope.
• Note exploit reliability and required capital (if any).

5. Mitigation

• Propose smallest safe fix (code/logic/config), plus regression test idea. If unsure, suggest defense-in-depth controls and monitoring.

6. Disclosure packaging

• Choose format: platform template (HackerOne/Immunefi/etc.) or standalone markdown.
• Include supporting artifacts: PoC scripts, logs, screenshots, or links to on-chain txns.
• Add a clear summary: title, severity rationale, root cause, attack path, impact, and fix.

7. Follow-up

• Track CVE/program IDs, coordinate timelines, and be responsive to triager questions. Avoid sharing sensitive details publicly until cleared.

Templates

Use this concise markdown skeleton when drafting a report:

Title: <short vulnerability name>

Summary:

• Location: <service/contract/file>
• Class: <auth/accounting/oracle/replay/reentrancy/dos/upgrade/web>
• Impact: <fund loss/priv-escalation/dos/data>
• Preconditions: <what attacker needs>

Reproduction:

1. <step>
2. <step>
3. <step>

Expected vs Actual:

• Expected: <safe behavior>
• Actual: <vulnerable outcome>

Impact:

• <quantified effect + scope>

Mitigation:

• <smallest fix>
• Tests: <regression idea>

Artifacts:

• <tx hashes/logs/PoC link>

Guidance

• Be precise, avoid speculation, and keep steps reproducible.
• Never include private keys or secrets; redacted logs are fine.
• If unsure about severity, map to High when direct fund loss or privilege gain is possible; otherwise Medium, and clearly justify.
• Respect rate limits and ToS; avoid stressing production systems.