Skip to main content
When submitting a finding through Cantina in a competition, it’s important to follow the outlined process and meet the requirements to ensure your submission is considered valid. This guide provides detailed information on the process, severity criteria, and mandatory submission rules to help you submit findings effectively.

​
Finding Submission Process

You can initiate a finding submission in two ways:
  1. By highlighting code during a code review
  2. By clicking the “New Finding” button in the top right corner of the Findings section
To submit a finding, you must fill out the following required fields (optional fields are also available):
  • 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.
You can add code to an existing finding if it doesn’t already include a highlighted area.

​
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/ImpactHigh ImpactMedium ImpactLow Impact
HighHighMediumMedium
MediumHighMediumLow
LowMediumLowInformational

​
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.

​
Proof of Concept (PoC) Requirements

​
PoC Validity Criteria

PoC validity: Your Proof of Concept must compile and demonstrate the impact of the issue. Additional precautions that help reviewers:
  • Mention which test file it’s part of
  • Ensure it’s valid for the audit branch
  • Note any additional requirements for the PoC to run
  • Provide the PoC output
  • Explain the PoC output vs. expected output

​
When PoC Is Not Required

Exceptions when PoC is not required:
  • Missing function(s)
Any other exceptions will be noted on the specific competition page.

​
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.
Invalid duplicates may result from:
  • Failure to identify the root cause clearly.
  • Insufficient impact analysis or unclear attack paths.
Incomplete or Invalid Attack Path: If the attack path from root cause to impact is poorly described or invalid, the finding may be downgraded or invalidated. This includes:
  • Incorrect POC: The POC cannot be executed, does not demonstrate the stated impact, or relies on unrealistic assumptions or conditions.
  • Insufficient Description (for issues without a coded POC): The description of how the root cause leads to the stated impact is incomplete, incorrect, or unclear.

​
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.
Final Judgment: While these guidelines serve as a reference, the final judgment on validity and severity rests with Cantina’s appointed judges, who will evaluate each finding based on the full context.

​
Cantina Assistant

Cantina Assistant is here to assist you in crafting more effective findings. With Cantina Assistant, you’ll be able to analyze your submission to ensure it follows the template, includes a valid proof of concept, and meets all criteria for a positive judgment. This increases your chances of clear communication and successful outcomes. For real-world examples of good and bad findings with PoC code, see Finding Submission Examples.