Finding Submission Process
You can initiate a finding submission in two ways:- By highlighting code during a code review
- By clicking the “New Finding” button in the top right corner of the Findings section
- Severity: The criticality of the issue, helping to determine its urgency. It is based on factors like Likelihood and Impact, ranging from Critical (severe consequences) to Low (minimal impact).
- Likelihood (optional): The probability of exploitation.
- Impact (optional): Potential consequences if exploited.
- Title: A concise description that clearly conveys the essence of the vulnerability.
- Description: A detailed explanation of the problem, including cause, effects, and any proof of concept (PoC) or supporting material (e.g., diagrams).
- Select Template: Choose a structured template to format your report.
Finding Severity Criteria
The severity of a finding is determined by its impact and likelihood.- Impact relates to the potential damage or consequences caused by the issue (e.g., loss of user funds, disruption of services).
- Likelihood indicates how likely the vulnerability is to be exploited (e.g., can it be triggered by any user, or does it require special conditions?).
Severity Matrix
| Likelihood/Impact | High Impact | Medium Impact | Low Impact |
|---|---|---|---|
| High | High | Medium | Medium |
| Medium | High | Medium | Low |
| Low | Medium | Low | Informational |
Impact Criteria
- High: Loss of user funds, breaks core functionality.
- Medium: Temporary disruptions, minor fund exposure, non-core functionality failures.
- Low: Issues without risk to assets or core functions.
Likelihood Criteria
- High: Easily triggered by any user, likely exploitation.
- Medium: Issues requiring constraints or planning (e.g., capital or other users’ actions).
- Low: Requires rare conditions or admin action.
Exceptions to Severity Matrix
Some issues are capped in severity (unless explicitly stated otherwise):Low Severity
- Minimal loss due to rounding errors.
- Issues with “weird” ERC20 tokens.
- Errors in view functions not used in the protocol.
Informational Severity
- Admin errors (wrong parameters in a function call).
- Malicious admin actions (unless explicitly covered in the scope).
- User errors that don’t affect other users.
- Protocol design-related issues.
Invalid Submissions
- Speculative Issues related to future code or integrations.
- Known Issues that have already been reported.
Key Considerations
- Protocol Behavior: Always refer to the competition README for protocol behavior.
- Mandatory PoC Rule: All high and medium severity submissions must be accompanied by a Proof of Concept (PoC) unless the researcher’s reputation score is above 80. Exceptions will be noted on the competition page.
- Cantina Dedicated Researchers are exempt from this rule and can submit PoCs upon request.
- Escalation Process: If there’s a disagreement over severity or findings, there’s a formal escalation process. Invalid escalations will incur penalties, so ensure your case is strong before submission.
Duplication Rules
To consider a submission a potential duplicate:- Root Cause Identified: The finding must identify the root cause of the issue.
- Medium or Higher Severity: The impact should be significant.
- Valid Attack Path: A clear, realistic path must link the root cause to the impact. This can be shown through a PoC or a detailed description of the code.
- Failure to identify the root cause clearly.
- Insufficient impact analysis or unclear attack paths.
Additional Submission Quality Guidelines
- Ensure clarity and context in your findings so they can be properly evaluated.
- Judging time is limited, so ensure that your findings are clear, actionable, and well-supported for efficient review.