The main categories for classifying data based on root causes and vulnerabilities.
| Title | Description |
|---|---|
| DAO | Root cause issues related to Decentralized Autonomous Organizations. |
| DoS | Vulnerabilities causing Denial of Service attacks. |
| Flashloan | Issues unique to flash loans that enable quick, uncollateralized loans. |
| Oracle | Problems specific to oracles providing external data to smart contracts. |
| Logic error | General logic errors within code execution. |
| Reentrancy | Reentrancy attack vulnerabilities allowing repeated function calls. |
| Access Control | Flaws in permission and access systems within applications. |
| Liquidation | Issues in processes for liquidating assets. |
| Slippage | Problems related to price slippage in transactions. |
| ERC4626 | Issues related to ERC4626 vault application integrations. |
| Input Validation | Before user actions, external inputs, or execution, there is no check to ensure they meet the expected conditions. |
| Bad Randomness | The use of insecure or predictable randomness, which can lead to vulnerabilities such as manipulation or exploitation. |
| Chainlink | Issues related to the use of Chainlink oracles, including but not limited to API calls, data retrieval, and utilization of oracle services. |
| Arithmetic | A vulnerability caused by incorrect numeric operations such as precision loss, unsafe conversions, overflows, or improper scaling. |
| Re-org Attack | A vulnerability that arises when smart contract logic assumes finality or determinism in block ordering, making it exploitable via chain reorganizations that reorder or replace recent blocks. |
| Pause | A contract state that conditionally disables specific functions under certain circumstances, such as emergencies or admin control. |
| Accounting Error | A flaw in the tracking or calculation of balances, shares, or rewards that leads to incorrect state representation or value distribution. |
| MEV | The act of maximizing the extraction of economic value within a blockchain system by manipulating the ordering of transactions, front-running transactions, or reordering transactions within a block. This typically results in losses for users or unfair distribution of system resources. |
| Upgradeable | When a contract is deployed using a proxy pattern or other upgradeable architecture, issues with its storage structure, initialization, permissions, or logic errors can lead to incorrect upgrades or inability to upgrade the contract properly. |
| ERC20 | Issues related to ERC20 tokens |
| call / delegatecall | Involves low-level external calls such as call, delegatecall, and staticcall. |
| Uniswap | Issues related to Uniswap integrations. |
| Cross-Chain | Involves security risks associated with cross-chain interactions, including issues related to message verification, asset bridging management, state consistency across different chains, and oracle synchronization. |
| ERC777 | Issues related to ERC777 tokens |
| Governance | This pertains to vulnerabilities, design flaws, or abuse of permissions within the governance mechanisms of a contract or protocol. This includes but is not limited to proposal processes, voting logic, role changes, timelocks, emergency permissions, and upgrade permissions related to governance modules. |
| Multisig | Covers all vulnerabilities related to the design and use of multisignature contracts (Multisignature Wallets / Modules), including issues in authorization management, signature verification, transaction execution, and security assumptions. |
| Rebalance | Refers to a defect in the protocol's logic design or implementation during asset weight adjustment, position balancing, pool weight adjustment, or supply rebalance. |
| ERC1155 | Issues related to ERC1155 tokens |
| XSS Attack | Refers to a vulnerability in a contract or Web3 application where improper filtering, encoding, or validation of external inputs allows an attacker to inject and execute malicious JavaScript code. |
Detailed classifications within each root cause vulnerability or application-specific issue.
| Title | Description |
|---|---|
| Violating CEI / Missing nonReentrant | Issues related to violation of Critical Event Identification or missing nonReentrant protection. |
| Missing Approval | Missing approve() call before attempting transferFrom, causing token transfer to fail. |
| Inflation Attack | An exploit where a malicious user artificially inflates the asset or share baseline through manipulating initial conditions or specific parameters, resulting in unfair gain and unequal distribution of assets or shares within the system. |
| Not EIP Compliant | Implementation does not adhere to the standards and requirements defined in the relevant EIP, potentially causing unexpected behavior or vulnerabilities. |
| Asset Theft | Allows an unauthorized user to illicitly transfer or misappropriate assets from other. |
| Rounding Error | Issues arising from incorrect rounding in ERC4626 vault functions, potentially leading to inaccurate asset or share allocations and deviations from the expected behavior as per the EIP 4626 specification. |
| Invalid Validation | Fails to correctly verify input or conditions, potentially allowing incorrect or harmful behavior. |
| Cannot partial liquidations | Whales (large holders) cannot be liquidated due to specific limitations in the protocol. |
| Liquidation – Dust repay / front run evade liquidation | Fine-grained errors related to dust repayment during liquidation and front running evasion. |
| onERC721Received callback | Vulnerabilities associated with the callback function onERC721Received. |
| Price Manipulation / Arbitrage opportunity | Opportunities for price manipulation or arbitrage within the system. |
| Bypass Mechanism | Mechanisms allowing bypassing of intended security measures. |
| Invariant Violation | Breaches of assumed constants or invariants in system logic. |
| Does not match with Doc / Implementation Error | Discrepancies between implementation and its documentation. |
| Invalid Slippage Control / Missing slippage check | Errors or missing checks in mechanisms designed to control or validate slippage. |
| No Incentive to Liquidate Small Positions | Economic disincentives preventing effective liquidation of small positions. |
| Hardcoded Parameter | Important contract parameters, are hardcoded and cannot be dynamically configured, limiting flexibility and adaptability to changing conditions. |
| minOut set to 0 | Problems with minimum output values set to zero. |
| Missing deadline | Situations where a required deadline parameter is missing. |
| Self liquidation | Vulnerabilities or issues that allow self liquidation under non-ideal conditions. |
| Missing minOut / maxAmount | Errors where minimum output (minOut) or maximum amount (maxAmount) parameters are missing. |
| Deprecated Library | Usage of outdated or unsupported function libraries, which may lead to operational disruptions or security vulnerabilities. |
| Out of Gas | Transaction fails due to exceeding the gas limit allocated for its execution. |
| Stale Value | The system uses outdated or obsolete data, which can be manipulated or exploited by attackers. |
| Front Run | The act of exploiting transaction ordering to execute a transaction before another, in order to manipulate price, contract state, or system behavior for unfair advantage. |
| Reward Manipulation | Exploiting weaknesses in a protocol’s reward distribution logic—such as timing, balance tracking, or eligibility checks—to gain more rewards than fairly earned. |
| Token Decimal | The precision used to define token fractions in smart contracts, where incorrect setting or manipulation can cause calculation errors and transaction inaccuracies. |
| Incorrect Parameter | A flaw where function inputs are provided with wrong order, invalid values, or improper types, causing incorrect behavior or logic errors. |
| No Recovery Mechanism | Lack of mechanism to recover from failed, frozen, or misconfigured components. |
| Centralization Risk | Critical functions or system components are controlled by a single party, creating a risk of misuse, censorship, or manipulation. |
| Precision Loss | Loss of numeric precision due to integer division or insufficient scaling (e.g., result becomes 0). |
| Scaling | Failure to apply proper unit conversion or scaling factor in arithmetic operations involving tokens with different denominations or expected decimal precision. |
| Peg / Depeg | Covers all design or implementation errors related to asset peg mechanisms, including improper maintenance of the peg (depeg), return biases, reliance on incorrect sources, or lack of detachment handling. |
| State Update Inconsistency | State Update Inconsistency occurs when the state of a smart contract is updated in an inconsistent or incorrect manner, leading to discrepancies, inaccuracies, and unintended outcomes in future operations, calculations, or decisions. This may impact various aspects of the contract, such as pricing mechanisms, liquidation processes, or liquidity management, and could result in financial losses or manipulative opportunities. |
| Duplicate Value | A vulnerability where two or more distinct entities (e.g. assets, records, or users) unintentionally share the same key or identifier (e.g. mapping key, oracle reference), causing one to overwrite or shadow the other. |
| Arbitrary Add/Remove/Set | The contract allows unauthorized addresses to arbitrarily add/remove or set key states or resources, leading to privilege abuse or system anomalies. |
| Storage Gap | In upgradeable contracts, to avoid storage slot conflicts and overwrites during upgrades, a fixed-length gap of empty storage space is reserved for future extension of contract state variables. The absence of or incorrect design of the storage gap may lead to state corruption or data overwriting after the upgrade. |
| Missing Return Check | The return value is not verified. |
| Misuse of Dependency | When using external dependencies (libraries, modules, or contracts), failing to reference them correctly according to their design or context, leading to functional anomalies, security risks, or upgrade failures. |
| Role Takeover | A situation where a user or contract illegitimately gains control over a privileged role by removing, overriding, or replacing the originally designated role holder. |
| Missing Time Constraint | The contract does not check time-related conditions (such as block.timestamp, deadline, expiry) |
| Unauthorized Upgrade | Refers to the lack of authorization checks during the contract upgrade process, allowing unauthorized addresses to perform contract upgrade operations. |
| Missing Initialization | The contract does not properly initialize necessary states (such as permissions, dependencies, parameters), which may lead to the contract being unusable or exhibiting abnormal behavior. |
| slot0 | The contract directly relies on Uniswap's slot0 (which provides instantaneous price and liquidity data) as its quoting source without applying any time-smoothing mechanisms (such as TWAP). This makes the price highly susceptible to short-term manipulations, for instance through flash loans. |
| Bad Condition | This refers to errors or omissions in the conditional logic within the code that result in critical state checks, control flow branches, or security mechanisms not being triggered properly. Such errors can lead to severe issues, including loss of funds, permission bypasses, state inconsistencies, or logical corruption. |
| Unfair Liquidation | This occurs when a user, despite not violating the protocol's rules, is liquidated due to insufficient protective measures or design flaws in the protocol. |
| Nonce | The absence or misuse of a nonce mechanism can lead to operations being re-executed, replayed, or subjected to race conditions. |
| Fee On Transfer Token | Vulnerability, incompatibility, or oversight arises due to the behavior of fee-on-transfer tokens — tokens that deduct a fee during transfers, causing the received amount to be less than the sent amount. |
| payable / receive() | Improper design of payable or receive() / fallback() functions leading to issues in fund reception, control, or logic. |
| Rebase Token | Covers security or accounting issues arising from the use or integration of Rebase Tokens, which have dynamic supply adjustment mechanisms. |
| Whale | Involves situations where a single or a few addresses hold large amounts of assets, leading to asymmetric risks such as market manipulation, concentrated governance, unusual liquidations, and distorted rewards within the protocol. |
| ERC777 Callback | When interacting with ERC777 tokens, misuse of callbacks can lead to external contracts controlling states unexpectedly, causing security risks or business logic errors. |
| EVM Compatibility | The contract design or protocol assumes certain EVM behaviors (such as gas model, opcode support, call patterns, address format, precompile availability, etc.) are consistent across all chains. However, differences in these behaviors on various EVM-compatible chains or Layer 2 solutions can lead to logic errors, functionality failures, or security vulnerabilities. |
| Case Sensitive | The comparison logic for user input, addresses, function names, or identifiers is case-sensitive, leading to behavior that does not match expectations. |
| Execution Order Dependency | Protocol logic relies on a specific transaction order or execution timing.This can lead to issues such as repeated execution, asset loss, or state errors. |
| Cross-Function Reentrancy | Cross-Function Reentrancy** refers to a scenario where a contract makes an external call during the execution of a function and is vulnerable to an attacker reentering through a different entry function upon the external call’s return. This can cause unsynchronized state reads, writes, or asset manipulations, leading to logic errors or security vulnerabilities. |