Core Contracts

Summary

The StabilityPool contract restricts most functions of the DEToken contract using the onlyStabilityPool modifier, but it only calls two such functions—mint and burn—during deposit and withdrawal operations. Additionally, the StabilityPool provides a function depositRAACFromPool, protected by the onlyLiquidityPool modifier, which is intended to handle RAAC token deposits from the liquidity pool (likely the LendingPool). However, an audit of the LendingPool interface and internal calls reveals that no contract or interface calls depositRAACFromPool. This indicates that these functions might be either unused or over-restricted, pointing to potential design oversights or incomplete integration of the StabilityPool with related components.

Vulnerability Details

DEToken Functions Access Control

• Implementation:
  The DEToken contract applies the onlyStabilityPool modifier to most of its functions to restrict access exclusively to the StabilityPool. In practice, the StabilityPool only invokes two functions—mint and burn—for managing user deposits and withdrawals:

  • Deposit:
    In the deposit function of StabilityPool, the contract transfers rToken from the user and calls deToken.mint(msg.sender, deCRVUSDAmount) to issue corresponding deTokens.

  • Withdrawal:
    In the withdraw function, it calls deToken.burn(msg.sender, deCRVUSDAmount) to redeem deTokens.

• Observation:
  No other DEToken functions protected by onlyStabilityPool are used, suggesting that the additional functionality in DEToken (if any) is either not needed or is inadvertently locked away due to overly strict access control.

RAAC Token Deposit Function

• Function:
  The depositRAACFromPool function is designed to allow the liquidity pool (presumably the LendingPool) to deposit RAAC tokens into the StabilityPool. It is protected by the onlyLiquidityPool modifier:

  function depositRAACFromPool(uint256 amount) external onlyLiquidityPool validAmount(amount) {

  uint256 preBalance = raacToken.balanceOf(address(this));

  ​

  raacToken.safeTransferFrom(msg.sender, address(this), amount);

  ​

  uint256 postBalance = raacToken.balanceOf(address(this));

  if (postBalance != preBalance + amount) revert InvalidTransfer();

  ​

  // TODO: Logic for distributing to managers based on allocation

  ​

  emit RAACDepositedFromPool(msg.sender, amount);

  }

• Observation:
  Despite its intended purpose, an inspection of the LendingPool contract and the ILendingPool interface shows that there are no calls to depositRAACFromPool. This lack of integration may indicate that either the function is obsolete, the intended interactions have not been fully implemented, or the design was revised but the function was left in the codebase.

Impact

• Design and Integration Concerns:
  The underutilization of DEToken functions (beyond mint and burn) and the absence of calls to depositRAACFromPool can lead to confusion regarding the intended functionality of the StabilityPool. This may affect future development, auditing, and maintenance.

• Low Severity:
  While these issues do not present an immediate security risk, they can impact the clarity and efficiency of the protocol's design, potentially leading to higher maintenance costs and integration errors in future upgrades.

Tools Used

• Manual Review

• Foundry

Recommendations

1. Review DEToken Access Control:

   • Confirm if only the mint and burn functionalities are required from DEToken by the StabilityPool.

   • If additional functionality is expected to be used, consider revising the onlyStabilityPool modifier or the DEToken interface to allow a broader set of authorized calls (e.g., using a role-based access control system).

2. Integrate or Deprecate depositRAACFromPool:

   • Verify the intended flow for RAAC token deposits from the liquidity pool. If the function is part of a planned feature, update the LendingPool or ILendingPool interface to call it as intended.

   • If it is no longer needed, consider deprecating or removing the function to reduce code complexity.