Because of the way the usageIndex
is updated, the crvUSD
needed for the liquidation will be different in the StabilityPool::liquidateBorrower
function and the LendingPool::updateState
function
lets examine the flow of the LendingPool::borrow
deposit function:
it firstly calls the updateReserveState
, which updates the liquidityIndex
and usageIndex
and at the end of the function it calls the updateInterestRatesAndLiquidity
, which updates the variable that compute the liquidityIndex
and usageIndex
. The thing here is that at its end, the updateInterestRatesAndLiquidity
function calls updateReserveState
, aiming to update liquidityIndex
and usageIndex
itself, but this just can't happen because of the following check in updateReserveInterests
:
This means that the liquidityIndex
and usageIndex
will remain inupdated until the next time the updateReserveInterests
function is called.
With this out of the way lets go back to the StabilityPool::liquidateBorrower
function. The problem here is that it gets the user debt with the outdated usageIndex
, which will be updated in the first line of LendingPool::finaliseLiquidation
as seen here:
This will result in a difference between the usage index in the StabilityPool
contract and in the LendingPool
contract, which will lead to liquidation reverts pretty often because the approved amount will be less than the amount the should be transferred to RToken
Often liquidation reverts, because of insufficient allowance
Manual Review
call the LendingPool::updateState
in the StabilityPool::liquidateBorrower
function
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.