Issue Severity

A Critical issue is a vulnerability that can lead to the irreversible loss of user funds, complete protocol insolvency, or permanent network disruption. These are the highest-priority findings requiring immediate action.

• Examples: A logic flaw allowing an attacker to drain the entire contract balance, a reentrancy attack that locks funds permanently, or a bug that bricks core protocol functionality.
• Response: Typically requires an emergency patch and may necessitate a temporary pause of the protocol.

A High severity issue can lead to a significant loss of funds for a subset of users, manipulation of core protocol mechanisms, or a temporary denial of service for key functions.

• Examples: An access control flaw allowing unauthorized upgrades, an oracle manipulation vector affecting pricing, or a bug causing incorrect interest rate calculations in a lending pool.
• Impact: While not immediately catastrophic for the entire system, these vulnerabilities pose a serious threat to protocol integrity and user assets.

A Medium severity issue represents a material breach of intended functionality that does not directly lead to fund loss but can be leveraged to cause economic damage or degrade system performance.

• Examples: Incorrect event emissions that break off-chain indexers, gas inefficiencies leading to high transaction costs, or a failure to follow best practices that could compound with other bugs.
• Context: These are often violations of specifications or logic errors with constrained exploit scenarios.

A Low severity issue is a deviation from best practices or a minor flaw with minimal direct impact on security or functionality under normal operating conditions.

• Examples: Unused state variables, lack of NatSpec comments, typos in error messages, or using tx.origin for authentication in a non-critical function.
• Purpose: Addressing these issues improves code quality, maintainability, and reduces the "attack surface" but is not urgent.

Informational findings highlight opportunities for improvement that do not affect correctness or security. Gas Optimization is a specific sub-category focused on reducing the computational cost (gas) of contract execution.

• Examples: Suggesting more efficient data structures, identifying redundant checks, or recommending the use of immutable/constant variables.
• Value: While not a vulnerability, these optimizations can lead to significant cost savings for users and improve network efficiency.

Severity is determined by evaluating multiple factors, not just the bug itself. Key criteria include:

• Impact: The potential financial loss or operational damage.
• Likelihood / Exploitability: How easily the vulnerability can be triggered (e.g., requires a privileged role vs. any user).
• Scope & Prerequisites: The conditions needed for exploitation (e.g., specific asset prices, user actions).
• Permanence: Whether the effects are reversible or permanent.

This multi-factor analysis ensures findings are contextualized within the specific protocol's architecture and threat model.

Vulnerabilities that pose an immediate, high-risk threat to the protocol's core functionality or user funds. These typically allow for direct theft of assets, permanent freezing of funds, or unauthorized minting of tokens. Examples include: reentrancy attacks, flawed access control allowing admin takeover, and logic errors enabling infinite minting. Critical issues require immediate remediation before deployment.

Issues that can significantly compromise the system's security or lead to substantial financial loss, but may require specific conditions or be less straightforward to exploit than Critical flaws. Examples include: manipulation of oracle price feeds, temporary freezing of funds, or privilege escalation that doesn't grant full admin control. These are prioritized for fixes in the next upgrade cycle.

Vulnerabilities that breach security best practices or could lead to material loss under non-standard conditions or in combination with other issues. Impact is often limited or circumstantial. Examples include: failure to follow checks-effects-interactions pattern (without immediate exploit), gas inefficiencies leading to denial-of-service, or leak of non-critical information. These are addressed as part of scheduled maintenance.

Findings that do not pose an immediate risk but indicate deviations from best practices, code quality issues, or potential future weaknesses. Examples include: unused variables, unclear code comments, or gas optimizations. While not urgent, addressing these improves code maintainability and reduces the attack surface over time. Informational findings are often grouped as code style or gas usage reports.

The final severity of an issue is not absolute; it depends heavily on the protocol's context. Factors that influence severity include:

• Total Value Locked (TVL): A flaw in a $10B protocol is inherently higher risk.
• Access Controls: A public function flaw is more severe than one in a admin-only function.
• Time Sensitivity: A bug that can be exploited immediately post-deployment is more critical than one requiring a specific future state.
• Composability: Vulnerabilities that can be chained with other protocols (e.g., in DeFi lego) increase the potential blast radius.

A Medium severity issue stems from flawed incentive mechanisms or economic logic, leading to unsustainable protocol behavior or subversion of intended functions. The Iron Finance bank run (June 2021) was triggered by a death spiral where the algorithmic stablecoin IRON lost its peg, causing a cascading liquidation event that erased billions in Total Value Locked (TVL). This is a failure of economic design, not a code bug.

A Low severity issue represents a predictable economic inefficiency that can be exploited for profit without directly breaking protocol rules. Maximal Extractable Value (MEV) through techniques like sandwich attacks is a prime example, where bots profit by inserting transactions around a user's trade, worsening their execution price. While not a 'hack,' it represents a significant and pervasive tax on users.

An Informational severity issue highlights suboptimal code that does not pose a security risk but results in unnecessary costs or performance degradation. A common example is a smart contract function that performs redundant state reads or writes, causing users to pay higher-than-necessary gas fees. While not exploitable, fixing these issues improves user experience and protocol efficiency.