Core Contracts

Summary

The LendingPool::borrow() function does not correctly account for interest accrual when updating a user’s debt balance, leading to an inaccurate tracking of outstanding debt. Specifically, it only adds the scaled debt amount without considering prior balance increases due to accumulated interest. This incorrect debt tracking extends to multiple functions, including liquidation and repayment, causing miscalculations that can lead to protocol losses and inaccurate liquidations.

Vulnerability Details

The DebtToken::mint() function correctly accounts for accrued interest (balanceIncrease) when minting new debt tokens for users.

However, in the LendingPool::borrow() function, the user’s scaledDebtBalance is updated using:

This implementation fails to incorporate the accumulated interest on the user’s existing debt.

• Debt Growth is Ignored: Interest accrues over time on a user's debt, but since scaledDebtBalance is updated incorrectly, the protocol does not factor in the interest accrued between borrow transactions.

• Incorrect Borrowing Power Calculation: The function checks if the user has sufficient collateral using the condition:

  // Fetch user's total debt after borrowing

  uint256 userTotalDebt = user.scaledDebtBalance.rayMul(reserve.usageIndex) + amount; // @audit doesn't account for balance increase

  ​

  // Ensure the user has enough collateral to cover the new debt

  if (collateralValue < userTotalDebt.percentMul(liquidationThreshold)) { // @audit Incorrect Undercollateralization check

  revert NotEnoughCollateralToBorrow();

  }

  Since user.scaledDebtBalance does not reflect the actual debt (because balance increase is ignored), userTotalDebt is underestimated. This means users may borrow more than their collateral should allow.

• Excessive Borrowing & Protocol Insolvency Risks: By exploiting this issue, users can repeatedly borrow more than their effective collateralization, increasing the likelihood of insolvency for the protocol when liquidations fail to recover sufficient funds.

This issue also extends to:

• getUserDebt(), which fetches a user’s total debt using the same flawed calculation.

• initiateLiquidation(), which evaluates a user’s health factor based on an incorrect debt value.

• closeLiquidation(), which incorrectly checks for debt clearance before allowing liquidation to close.

• finalizeLiquidation(), which relies on an inaccurate debt calculation when burning DebtTokens.

• _repay(), where the function mistakenly compares repayment amounts to userScaledDebt instead of the full debt amount, leading to improper repayments.

Impact

• Users can borrow more than they should: Since the debt calculation underestimates the actual debt, borrowers may withdraw excessive amounts, leaving insufficient collateral to cover their obligations.

• Liquidations may be delayed or skipped: Because the system underestimates debt, users who should be liquidated might not be flagged as undercollateralized in time.

• Protocol insolvency risk: The incorrect debt calculations can lead to situations where debt surpasses collateral but is not properly recognized, causing financial losses to lenders and liquidity providers.

Tools Used

Manual Code Review – Identified incorrect debt tracking logic in borrow().

Recommendations

Implement a similar balanceIncrease calculation as used in the DebtToken::mint() function the correctly account for the balance increase in between borrows in the LendingPool.