Bug Report Submission Checklist – Immunefi

General

Have you read the project’s bug bounty program?
Have you read the program’s reward payout terms?
Have you checked if the program requires KYC?
Is the asset you’re reporting on in scope?
If the asset is out of scope, does the bug bounty program say it adheres to Primacy of Impact?
Is the impact in scope?
Is there a PoC requirement for the severity of the impact
Did you make sure that you understand the impact you’re selecting?
Is the bug listed on the bug bounty program page a known issue?
Have you read Out of Scope Rules on the bug bounty program page?

Is your bug report title meaningful and descriptive?
Is the bug description clear?
Is the impact immediate, or non-immediate? If possible, list the amount of funds at risk *right now*.
Have you selected an severity level that is accurate, given the impact?
Is the attack vector you’re describing likely to succeed? (i.e. can it be executed all at once, or does it require many repeatable attacks over a long period of time?)
Have you provided sufficient evidence for all your claims?
Have you used our Bug Report Template?

Have you included a PoC?
Is the PoC runnable as-is?
Is the PoC clear enough? Use var names that are self explanatory (Attacker/Target), function names like _executeAttack.
Is the PoC optimized for maximum impact?
Have you ensured that the PoC does not cause damage in any way? E.g. does not interact with mainnet or public testnet?
Have you used our PoC Templates?
Have you read and followed our PoC Guidelines and Rules?
Did you make sure to show the kill-chain if reporting a subdomain takeover?

Have you attempted to engage in productive dialogue with the project first before calling in Immunefi for mediation and support?
Before requesting help from Immunefi because of a non-responsive project, have you read the SLAs for project response times?
Have you checked what Responsible Publication category the project subscribes to, if any?