Core Contracts

Summary

The calculateUtilizationRate function in the ReserveLibrary is implemented incorrectly due to improper handling of scaling between the reserve’s liquidity and usage values. This miscalculation ends up to incorrect settings for key parameters such as rateData.currentUsageRate, rateData.currentLiquidityRate, reserve.liquidityIndex, and reserve.usageIndex.

Vulnerability Details

In ReserveLibrary.sol, the function calculateUtilizationRate computes the utilization rate using the formula:

Here, the function assumes that both totalLiquidity and totalDebt are on the same scale. However, the protocol stores reserve.totalLiquidity as an unscaled amount while reserve.totalUsage (representing debt) is a scaled value derived from the DebtToken’s total supply. For example, in LendingPool.sol, the deposit/withdrawal functions and the borrow/repay flows pass unscaled amounts for liquidity changes, yet reserve.totalUsage reflects scaled debt values.

Because the calculation mixes unscaled liquidity with scaled debt, the derived utilization rate is incorrect. This error then propagates into subsequent computations:

• The borrow rate is calculated using an incorrect utilization rate.

• The liquidity rate, which depends on the utilization rate, is misconfigured.

• The liquidity and usage indices (reserve.liquidityIndex and reserve.usageIndex) are updated based on these faulty rates.

Impact

• Interest Rate Misconfiguration: Incorrect interest rates may result, leading to unexpected borrowing costs or lending returns.

• Protocol Instability: Mispriced loans and inconsistent interest accrual can undermine the financial model of the protocol, potentially harming both borrowers and lenders.

• User Losses: Inaccurate fees or rewards can lead to financial losses for users.

Tools Used

Manual code review

Recommended Mitigation

• Normalize Scaling: Modify the calculateUtilizationRate function to correctly account for the difference in scales between reserve.totalLiquidity (unscaled) and reserve.totalUsage (scaled). This may involve either scaling up the liquidity amount or unscaling the debt amount before performing the division.

• Consistent Arithmetic: Ensure that all arithmetic operations involving liquidity and debt are performed on values that are consistently scaled.