The _rebalanceLiquidity() attempts to deposit excess liquidity into the curveVault by approving it to spend tokens from reserve.reserveAssetAddress. However, deposited funds reside in reserve.reserveRTokenAddress, not reserve.reserveAssetAddress. This causes _depositIntoVault() to fail due to insufficient balance when calling approve() and deposit(), leading to deposit transaction reverts and liquidity management failure.
A user deposits reserve asset tokens into the protocol by calling deposit(amount).
Inside deposit(), ReserveLibrary.deposit() transfers funds from msg.sender to reserve.reserveRTokenAddress, not LendingPool.
After the deposit, _rebalanceLiquidity() is triggered to check if excess liquidity should be deposited into the Curve vault if it is not address(0).
If there is excess liquidity, _depositIntoVault(excess) is called:
The approve() function is called by LendingPool, but all liquidity is held in reserve.reserveRTokenAddress.
Since LendingPool has no funds, approve() and deposit() fail, reverting the entire transaction.
Proof of Concept (PoC)
Make a MockCurveCrvUSDVault
Update LendingPool.test.js
As seen above, after lendingPool.curveVault is set, deposit transaction reverts in _depositIntoVault().
Protocol core function(deposit) reverts
manual
Adds transfer asset proccess in _rebalanceLiquidity()
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.