A vulnerability in the updateInterestRatesAndLiquidity
function results in incorrect calculations of interest rates and liquidity due to the use of an improperly scaled amount. This could lead to miscalculated borrower interest and an inaccurate representation of available liquidity.
In ReserveLibrary.updateInterestRatesAndLiquidity, the following incorrect parameter is used in LendingPool::_repay
and LendingPool::finalizeLiquidation
:
In LendingPool::_repay
In LendingPool::finalizeLiquidation
updateInterestRatesAndLiquidity
Why is This Incorrect?
The function expects liquidityAdded
and liquidityTaken
in underlying asset units.
amountScaled
is in scaled debt units, which means it does not correctly represent the actual liquidity added.
Using amountScaled
miscalculates reserve interest rates and available liquidity, which can distort protocol economics.
Incorrect interest rate calculations leading to overcharging or undercharging borrowers.
Misallocated lender yield, affecting lender returns.
Inaccurate liquidity tracking, which could cause improper borrowing and lending decisions.
Potential financial losses due to miscalculated protocol economics.
If exploited, this could result in financial inconsistencies, making the protocol unstable over time.
Manual Review
In LendingPool::_repay
Instead of amountScaled
, the function should use amount
, which represents the repayment in underlying asset units:
In LendingPool::finalizeLiquidation
Interest IS applied through the balanceOf() mechanism. The separate balanceIncrease calculation is redundant/wrong. Users pay full debt including interest via userBalance capping.
Interest IS applied through the balanceOf() mechanism. The separate balanceIncrease calculation is redundant/wrong. Users pay full debt including interest via userBalance capping.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.