# Severity matrices update

## Spearbit

| **Severity** | **Impact: High** | **Impact: Medium** | **Impact: Low** |
|:---|:---|:---|:---|
|**Likelihood: High** | Critical | High | Medium |
|**Likelihood: Medium** | High | Medium | Low |
|**Likelihood: Low** | Medium | Low | Low |

### Impact

- High - leads to a loss of a significant portion (>10\%) of assets in the protocol, or significant harm to a majority of users.
- Medium - global losses <10\% or losses to only a subset of users, but still unacceptable.
- Low - losses will be annoying but bearable-\/-applies to things like griefing attacks that can be easily repaired or even gas inefficiencies.

### Likelihood

- High - almost certain to happen, easy to perform, or not easy but highly incentivized
- Medium - only conditionally possible or incentivized, but still relatively likely
- Low - requires stars to align, or little-to-no incentive

### Action required for severity levels

- Critical - Must fix as soon as possible (if already deployed)
- High - Must fix (before deployment if not already deployed)
- Medium - Should fix
- Low - Could fix

## Cantina

| **Severity** | **Description** |
|:---|:---|
|**Critical**|_Must_ fix as soon as possible (if already deployed).|
|**High**|Leads to a loss of a significant portion (>10\%) of assets in the protocol, or significant harm to a majority of users.|
|**Medium**|Global losses <10\% or losses to only a subset of users, but still unacceptable.|
|**Low**|Losses will be annoying but bearable. Applies to things like griefing attacks that can be easily repaired or even gas inefficiencies.|
|**Gas Optimization**|Suggestions around gas saving practices.|
|**Informational**|Suggestions around best practices or readability.|

### Severity Classification

The severity of security issues found during the security review is categorized based on the above table. Critical findings have a high likelihood of being exploited and must be addressed immediately.

High findings are almost certain to occur, easy to perform, or not easy but highly incentivized thus must be fixed as soon as possible.

Medium findings are conditionally possible or incentivized but are still relatively likely to occur and should be addressed.

Low findings a rare combination of circumstances to exploit, or offer little to no incentive to exploit but are recommended to be addressed.

Lastly, some findings might represent objective improvements that should be addressed but do not impact the project's overall security (Gas and Informational findings).

## Cantina competitions (by Hari)

Assigning a severity to a bug you discovered can be challenging and sometimes subjective. We'll try to provide guidelines to make this process easier.

### 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 into 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.

| **Severity** | **Impact: High** | **Impact: Medium** | **Impact: Low** |
|:---|:---|:---|:---|
|**Likelihood: High** | High | High | Medium |
|**Likelihood: Medium** | High | Medium | Low |
|**Likelihood: Low** | Medium | Low | Informational |

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.

## Discussion 02/05/2024 with m4rio, high byte and Noah

> Noah mentions:
> "_We can expand "funds can be lost or core protocol requirements fail to function"
And provide examples
In gov for example, a critical is still a critical even with no funds involved
Or an ens domain not resolving correctly etc_"

`Ellipsis`