Skip to main content

​
Severity Matrix

The severity matrix serves as the baseline for assigning a severity to a bug. It’s often easier to think about the impact and the likelihood of the occurrence of an issue in two different categories.
  • A High impact situation would be one where funds can be lost.
  • A High likelihood situation would be one in which any participant can trigger such a bug in the protocol.
SeverityImpact: HighImpact: MediumImpact: Low
Likelihood: HighHighHighMedium
Likelihood: MediumHighMediumLow
Likelihood: LowMediumLowInformational
However, this is just the first step in assigning severity and has a lot of subjectivity in practice. When in doubt, consider what would happen to the protocol when such a bug is not fixed. If it leads to a catastrophic scenario that can be triggered by anyone or occur naturally, then it is very likely to be a High severity bug. If the protocol can function without the bug getting fixed, it’s likely to be a low severity bug. The last consideration to make is to put yourself in the shoes of the protocol designer. The best way to do this would be to think about how to mitigate the bug. We highly recommend everyone to submit a recommended mitigation for every finding. Doing this exercise can help you understand the tradeoffs that protocol designers have to make. For example, building a permissionless protocol often means making tradeoffs on certain properties — the Uniswap protocol allows anyone to deploy a pool and in most cases, these are perfectly legitimate pools, but, pools can be setup with malicious tokens to act in certain ways. There are two ways to mitigate such issues, adding a whitelist of all ‘genuine’ pools or alternatively rely on off-chain trust on what are the legitimate pools. If your suggested fix goes against the design philosophy of the protocol, it’s very likely to be at most an informational issue.

​
Mandatory PoC Rule

By default, all competitions have a mandatory PoC rule:
  • All high and medium severity submissions must be accompanied by a coded Proof of Concept (PoC) before the competition ends. This applies to researchers with a reputation score below 80.
  • Exceptions will be noted on the specific competition page.
  • Cantina Dedicated Researchers in a competition are exempt and can provide PoC upon request when needed.
To be considered valid, the PoC must compile and demonstrate the impact of the issue. See Submission Guidelines for PoC validity criteria and Finding Submission Examples for real examples. Exceptions when PoC is not required: Missing function(s), or when the researcher’s reputation score is ≥ 80.

​
Important Considerations

  • Issues that are ultimately user errors and can be easily managed in the front-end should at most be informational.
  • Issues that require admin access (or equivalent) to perform should at most be low severity, unless the protocol was designed to be resilient against such actions in the first place.
  • AI generated findings: submitting AI generated findings without validating them can lead to disqualifications or worse, a permanent ban.
  • The goal of getting a security review is for protocols to make meaningful changes to the protocols to improve its security. Make sure the findings you submit contribute to this cause.
  • In case of public competitions, a judge will act as an independent arbiter for any disagreements. After judging is done, there will be an escalation phase where people can contest some judgements. Anyone can currently contest a judgement, but there will be a penalty for escalations that were invalid.
  • Be mindful of the judges’ and the protocol-team’s time.

​
Protocol Behavior

The competition README must be used as the main reference for protocol behavior and not other sources.

​
Tips

  • Approval race conditions for ERC20 tokens will be considered invalid.
  • Assume by default that a protocol will be using only standard ERC20 tokens. Any findings that rely on weird token properties should at most be a low severity finding.
  • Losing dust amounts, say, due to rounding is at most a low severity finding.
  • Any finding that has been acknowledged in a previous report will be considered invalid.