Summary of Resolving Reports and Closing Invalid Submissions

A bug report is considered resolved when it is either:

• • Rejected as invalid (marked with the 'Closed' status)
  • Paid out by the project (marked with the 'Paid' status)

*Note that resolution for a `Paid` report does not necessarily have to include a fix to the vulnerability but only an acknowledgement and payment to the whitehat, affirming that it is a valid submission. 

When resolving reports, do not:

• • • Downgrade the severity of a vulnerability without a clear reasoning
    • Decide not to pay a vulnerability found in an asset in scope saying that the contract is unused 

If a report is closed as out of scope and/or the project does not intend to fix the vulnerability, the whitehat may request further mediation assistance from Immunefi.

Whitehats may also publicize vulnerabilities as long as they follow the rules outlined in our Responsible Publication policy.

Please refer to our SLAs and Notifications article which details the required resolution times based on severity level of the report. 

Closing Invalid Submissions

Before closing any submission, you must cite one of the following:

• Scope - with reference to the in-scope targets on the bug bounty page
• Severity - with reference to the corrected severity under the Immunefi severity system
• Technical validity - with reference to unrealistic preconditions, privileged access required, or malfeasance on the part of the victim, or the PoC/steps to reproduce don’t work
• Intended behavior - the behavior demonstrated is part of the correct functioning of the system
• UI/UX issues - the vulnerability is in non-security-critical frontend code or in the user’s own wallet software
• Spam - begging for an airdrop, submitting an empty report, etc
• Known issues - If the reported issue is already known to the team. Must include a reference to a previous bug report, GitHub PR, audit report, blog post, etc.