Assurance work by formal methods experts

High

Any of:

• Permanent deadlock of some or all protocol operations.
• Loss of any non-trivial amount of user or protocol funds.
• Core protocol properties do not hold.
• Arbitrary minting of tokens by untrusted users.
• DOS attacks making the system (or any vital part of the system) unusable.

Medium

Any of:

• Sensible or desirable properties over the protocol do not hold, but no known attack vectors due to this (a "looks risky" feeling).
• Non-responsive or non-functional system is possible, but recovery of user funds can still be guaranteed.
• Temporary loss of user funds, guaranteed to be recoverable via an external algorithmic mechanism like a treasury.
• Loss of small amounts of user funds (e.g. bits of gas fees) that serve no protocol purpose.
• Griefing attacks which make the system less pleasant to interact with and can potentially be used to promote a competitor.
• System security relies on assumptions about externalities like "valid user input" or "working monitoring server".
• Deployments are not verifiable, making phishing attacks possible.

Low

Any of:

• Slow processing of user transactions can lead to changed parameters at transaction execution time.
• Function reverts on some inputs that it could safely handle.
• Users receive fewer funds than expected in a purely mathematical model, but the bounds of this error are very small.
• Users are not protected from obviously bad choices (e.g. trading into an asset with zero value).
• The system accumulates unrecoverable dust (e.g. due to rounding errors).

Informative

Not a vulnerability, but worth fixing. Any of:

• Not following best coding practices.
  • Missing input validation or state sanity checks
  • Code duplication
  • Bad code architecture
  • Unmatched interfaces or poor use of external interfaces
  • Use of outdated or known problematic toolchains (e.g. an outdated compiler version)
  • Domain-specific code smells (e.g. not recycling storage slots on EVM)
• Gas optimizations.
• Non-intuitive or overly complicated behaviors, which may lead to users or auditors misunderstanding the code.
• Lack of documentation, or incorrect or inconsistent documentation.
• Known undesired behaviors when the security model or assumptions do not hold.

High

Any of:

• Only trusted authorized users can perform the attack (e.g. core devs).
• Performing the attack costs significantly more than how much you benefit (e.g. it costs 10x to make the attack vs. what is won).
• Performing the attack requires coordinating multiple transactions across different blocks, and can be stopped if detected early enough.
• Performing the attack requires control of the network to delay or censor given messages.
• Performing the attack requires convincing users to participate (e.g. bribing them).

Medium

Any of:

• Semi-authorized (or allowed) users can perform the attack (e.g. "special" nodes, like validators or staking operators).
• Performing the attack costs close to how much you benefit (e.g. 0.5x - 2x).
• Performing the attack requires coordinating multiple transactions across different blocks, but cannot be stopped even if detected early.

Low

Any of:

• Anyone who can create an account on the network can perform the attack.
• Performing the attack costs much less than how much you benefit (e.g. under 0.5x).
• Performing the attack can happen within a single block or transaction (or transaction group).
• Performing the attack requires access to only a modest amount of capital and a flash-loan system.