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.