Aave DIVA Wrapper

Summary

The WToken constructor in AaveDIVAWrapperCore.sol initializes the token with the same name and symbol, which is considered a bad practice. Names and symbols are important identifiers for tokens and should provide clarity to users. Using identical values for both fields reduces the ability to distinguish between the token’s full name and its shorthand symbol, potentially confusing users or integrators.

Vulnerability Details

Type: Poor Naming Convention / Bad Practice

• Location: AaveDIVAWrapperCore.sol, in the creation of the WToken instance:

  WToken _wTokenContract = new WToken(

  @> string(abi.encodePacked("w", _collateralTokenContract.symbol())), // Symbol and Name will be the same

  _collateralTokenContract.decimals(),

  address(this) // wToken owner

  );

  ​

• Issue:

  • The constructor for WToken sets both the token’s name and symbol to the same value, as seen in the WTokencontract:

    @> constructor(string memory symbol_, uint8 decimals_, address owner_) ERC20(symbol_, symbol_) {

    _owner = owner_;

    _decimals = decimals_;

    }

    ​

  • This practice reduces the clarity of the token's identity. Typically:

    • The name should be a descriptive, human-readable identifier (e.g., "Wrapped USDC").

    • The symbol should be a short, recognizable code (e.g., "wUSDC").

• Problem:

  • User Confusion: Identical names and symbols can confuse users when interacting with the token.

  • Industry Standard Violation: Most ERC-20 tokens in the ecosystem differentiate the name and symbol for clarity.

  • Missed Opportunities: The name field is valuable for describing the token’s function or relationship to the collateral.

Impact

This issue has a Low severity level but affects usability and clarity. It does not directly compromise the security or functionality of the contract but goes against best practices and may create confusion for integrators and end-users.

Tools Used

The following tools and techniques were used to identify and analyze the issue:

• Static Code Review: Manual inspection of token creation logic.

• Solidity Compiler (v0.8.26): Verified constructor behavior and ERC-20 compliance.

Recommendations

1. Fetch and Use the Collateral Token Name: Instead of setting the name to match the symbol, use the collateral token’s name() function to derive a more descriptive name for the WToken. For example:

   WToken _wTokenContract = new WToken(

   string(abi.encodePacked("w", _collateralTokenContract.symbol())), // Symbol

   + string(abi.encodePacked("Wrapped ", _collateralTokenContract.name())), // Name

   _collateralTokenContract.decimals(),

   address(this) // Owner

   );

   CopyEdit

   WToken _wTokenContract = new WToken( string(abi.encodePacked("w", _collateralTokenContract.symbol())), // Symbol string(abi.encodePacked("Wrapped ", _collateralTokenContract.name())), // Name _collateralTokenContract.decimals(), address(this) // Owner );

2. Update the Constructor of WToken: Modify the constructor to accept both the name and symbol as separate parameters:

   constructor(

   string memory symbol_,

   + string memory name_,

   uint8 decimals_,

   address owner_

   - ) ERC20(symbol_, symbol_)

   + ) ERC20(name_, symbol_) {

   _owner = owner_;

   _decimals = decimals_;

   }

   ​

3. Document the Change: Clearly document the improved naming convention and the rationale behind the change for developers and auditors.

4. Test Changes Thoroughly: Ensure the changes are tested with a variety of collateral tokens to confirm compatibility.

Example Implementation

Updated WToken Constructor

Updated Token Creation