DeepHigh
  • Welcome
  • Architecture
    • Compound
    • Venus
  • Threat Modeling
    • Identification of Function
    • Risk Library
    • Threat Enumeration
      • Enumeration
    • Risk Tree
  • Lending Invariant
    • Invariant
      • Aave V3
      • Venus
      • Euler V2
      • BIFI
      • Inverse Finance
      • Omni
      • BendDAO
      • Airpuff
      • Goldfinch
      • Wildcat
    • General Precautions
  • Edge Function
    • Flash Loan
    • BadDept
      • Auction
    • Mode
      • E-Mode
    • Leverage
    • Custom Pool
Powered by GitBook
On this page
  1. Lending Invariant

General Precautions

This page addresses common issues and precautions that are easy to overlook but can arise throughout the development process. The items listed here are not limited to specific features or modules; instead, they cover errors and security vulnerabilities that may occur across development as a whole. From preventing double spending and handling precision issues to managing out-of-bounds errors and missing zero-address checks, this section brings together risks that can compromise code stability and security.

Our aim with this section is to help developers maintain higher code quality and proactively mitigate issues stemming from potential vulnerabilities.

1. Double Spend (ERC20 & ERC721)

  • Description: Malicious actors can exploit allowance and lock mechanisms, bypassing proper token locking processes. This enables them to perform double spending, where tokens are spent twice without authorization.

2. Precision Issues

  • Description: Lack of precision handling, often due to missing decimals, can lead to inaccurate fund calculations. Attackers may exploit rounding errors to gain a financial advantage, especially in systems with small total supply or fractional tokens.

3. Out of Bounds Exception

  • Description: Improper handling of array operations, particularly when pushing values, can lead to out-of-bounds errors. This occurs if references are not updated correctly, leading to unexpected offsets that can crash transactions or result in unintended behavior.

4. Null Checks Missing in Functions

  • Description: Lack null address checks, causing unintended reverts or failures if an invalid address is inadvertently passed. This can lead to unintended consequences in for-loops or critical functions that rely on valid addresses.

5. Gas Limit Exceedance

  • Description: Loops and unbounded operations may cause transactions to exceed the gas limit. Without a cap on iterations, these processes can run indefinitely in worst-case scenarios, resulting in transaction reverts due to high gas consumption.

6. Division by Zero

  • Description: Division operations are not safeguarded against zero denominators. When variables result in zero values, division by zero errors can cause transactions to fail unexpectedly.

7. Overflow/Underflow Risks

  • Description: Arithmetic operations that do not use safemath can lead to overflow and underflow, which can cause incorrect or unintended results, potentially allowing attackers to manipulate values or crash functions.

8. Incorrect Value Reference

  • Description: Using incorrect references can lead to inaccurate calculations or incorrect fund allocations, creating financial discrepancies or vulnerabilities.

9. Immutable Settings

  • Description: Certain settings are immutable, meaning they cannot be altered once configured If misconfigured, these permanent settings can lead to operational issues or security risks without the option to rectify them.

10. Functions Expecting Decimals Might Fail with Non-Standard ERC20 Tokens

  • Description: Functions assume standard decimal implementations, but some tokens may not follow the standard or may lack decimal functions. This can cause errors or failure in calculations relying on expected decimal precision.

11. Hardcoding Constants

  • Description: Hardcoded constants, instead of flexible configurations, limit adaptability.

12. Duplicate Variable Names within Functions

  • Description: Variables with duplicate names, particularly within the same scope, can lead to variable shadowing. This can cause unexpected behavior due to confusion over which variable is referenced, increasing debugging difficulty and risking logical errors.

13. Documentation and Comment Mismatches

  • Description: Inaccurate or outdated documentation leads to confusion, particularly when comments contradict actual code behavior. This can mislead developers and increase the likelihood of introducing bugs or vulnerabilities.

14. Lack of Event Logs for Critical Actions

  • Description: Events are crucial for tracking off-chain actions. Lack of event logging in critical functions makes it difficult to monitor changes, increasing the risk of unnoticed errors or potential malicious actions going undetected.

15. Unnecessary Type Casting and Public Declarations

  • Description: Unneeded casting of data types (e.g., casting an already address type back to address) and marking functions as public instead of external lead to inefficient gas usage and potential unintended function calls.

16. Inadequate Indexing for Events

  • Description: Events without indexed parameters make it harder to search and filter events on-chain. This impacts data retrieval efficiency, limiting the ability to track specific transactions or actions.

17. Revert Risks from Zero Address Usage

  • Description: Zero address (0x0) checks are missing in critical functions, allowing invalid or unintended configurations that could lead to failures or unexpected behaviors if the zero address is assigned by mistake.

18. Logic Flaws with Math Operations

  • Description: Operations like performing division before multiplication can lead to precision loss due to rounding errors. Proper sequencing of arithmetic operations is essential to maintain accuracy in calculations.

19. Lack of Interface Compliance

  • Description: Discrepancies between interfaces and implementations, such as different return types or missing functions, can lead to compatibility issues and errors, especially if the implementation doesn’t inherit or adhere to the defined interface.

20. Unchecked Zero-Address and Fallback Handler Risks

  • Description: Functions that don’t validate addresses passed as parameters are vulnerable to misconfigurations if zero-addresses are inadvertently used, risking malfunction or unintended behavior.

21. Inconsistent Solidity Versions and License Mismatches

  • Description: Projects with inconsistent Solidity versions or mismatched licenses across contracts may face compatibility issues and legal uncertainties. This inconsistency complicates maintenance and potentially breaches compliance.

22. External Call Risks with Public Functions

  • Description: Public functions expose contracts to external access. Marking certain functions as public when they only require internal or external access can increase vulnerability to unauthorized calls or misuse, especially in inherited contracts.

24. Dependency on Off-Chain Processes

  • Description: Heavy reliance on off-chain processes creates a risk where on-chain functions may fail if the backend process is interrupted, making the contract vulnerable to service disruptions.

25. Unchecked Overflow in For Loops

  • Description: Loop variables susceptible to overflow without proper safeguards risk causing infinite loops, leading to out-of-gas errors and potential Denial of Service attacks if the loop is exploited.

26. Excessive String Comparison and Boolean Checks

  • Description: Frequent string comparisons and redundant Boolean operations increase gas costs and the potential for logic errors. Simplifying conditions or replacing strings with enums can improve efficiency and code clarity.

27. Security Risks with Non-EIP-712 Compliant Signatures

  • Description: Use of Non-EIP-712 compliant signing increases the risk of replay attacks across chains, as EIP-712 is more secure and chain-specific, reducing the risk of signature reuse.

28. Unused Variables and Imports

  • Description: Unused variables and imports increase contract size, complicating maintenance, and can lead to higher deployment and transaction costs. Removing these enhances code readability and efficiency.

30. Float Pragma

  • Description: Floating pragmas allow version flexibility, risking unexpected behavior with future Solidity updates. Fixed versions ensure consistency.

PreviousWildcatNextFlash Loan

Last updated 7 months ago