Skip to content

Latest commit

 

History

History
96 lines (60 loc) · 3.84 KB

078.md

File metadata and controls

96 lines (60 loc) · 3.84 KB

Glamorous Plum Baboon

Medium

Improper Decimals Validation in executeInitReserve

Summary

The executeInitReserve function contains a hardcoded validation for underlyingAssetDecimals, which must be greater than 5. This arbitrary restriction may lead to the rejection of valid tokens with fewer decimals (for example tokens with 0-5 decimals), preventing them from being initialized as reserves. This issue can impact protocol flexibility and token adoption.

Description

The executeInitReserve function validates the decimals of the underlying asset with the following requirement:

require(underlyingAssetDecimals > 5, Errors.INVALID_DECIMALS);

This hardcoded validation may be unnecessarily restrictive, as tokens with fewer than six decimals exist and can be valid candidates for reserves. Not all assets adhere to a specific decimal range, and hardcoding this value can lead to a rejection of valid tokens that might otherwise operate correctly within the protocol.

For example: i, USDT typically has 6 decimals, which barely meets the requirement.
ii, WBTC (Bitcoin wrapped token) uses 8 decimals.

However, assets like WBTC on certain chains may use fewer than 6 decimals, resulting in an unjustified rejection.

By making this restriction configurable or explicitly documenting this limitation, the protocol can avoid compatibility issues with valid tokens.

Root Cause

The root cause is the hardcoded assumption in the executeInitReserve function located in Line 54 of the ConfiguratorLogic library:

https://github.com/sherlock-audit/2025-01-aave-v3-3/blob/main/aave-v3-origin/src/contracts/protocol/libraries/logic/ConfiguratorLogic.sol#L54

This assumption enforces a restriction without accommodating for edge cases or providing flexibility for different token standards.

Impact

  • Severity: Medium
  • Scope: This bug impacts the usability of the protocol by unnecessarily limiting the types of tokens that can be initialized as reserves. This reduces the flexibility of the protocol and may alienate valid token projects.
  • Exploitation Vector: None. This issue is not exploitable; however, it restricts adoption and integration of tokens that fail the decimals check.

Proof of Concept (PoC)

A simple example that demonstrates the issue:

Steps to Reproduce:

  1. Deploy a custom ERC-20 token with fewer than 6 decimals (e.g., 5 decimals). Example:
contract CustomToken {
    string public name = "Custom Token";
    string public symbol = "CT";
    uint8 public decimals = 5; // Only 5 decimals
    uint256 public totalSupply = 1_000_000 * (10 ** decimals);
}
  1. Attempt to initialize this token as a reserve by calling the executeInitReserve function.

Expected Result:

The token should be initialized successfully as a reserve.

Actual Result:

The call reverts with the error INVALID_DECIMALS because of the hardcoded validation:

require(underlyingAssetDecimals > 5, Errors.INVALID_DECIMALS);

Recommended Mitigation

  1. Make the Decimal Restriction Configurable: Introduce a configuration parameter or mechanism that allows this decimal requirement to be dynamically set or overridden based on protocol needs. For example:
require(underlyingAssetDecimals > MIN_DECIMALS, Errors.INVALID_DECIMALS);

Where MIN_DECIMALS is a configurable parameter that can be adjusted by the protocol's governance or admin.

  1. Provide Documentation for the Assumption: If the restriction must remain hardcoded, explicitly document the reasoning behind this choice and warn users about potential limitations with tokens that fail the validation.

  2. Log a Warning Instead of Reverting: Consider logging a warning for unsupported tokens instead of hardcoding reverts, allowing developers to inspect and handle edge cases.