The _withdrawFromVault
function in the contract incorrectly attempts to withdraw assets from the user (msg.sender
) . Additionally, it sends the withdrawn assets to the lending pool instead of the RToken address. This flaw prevents users from borrowing or withdrawing assets when the protocol needs to replenish liquidity from the Curve vault. Furthermore, the incorrect withdrawal logic could result in users losing funds they are not supposed to pay, as the function attempts to withdraw assets from users instead of using protocol-controlled funds. The correct implementation should withdraw assets from the Curve vault, with the owner as the LendingPool (or RToken, based on protocol choice), and send them to the RToken address to ensure proper liquidity management.
The _ensureLiquidity
function checks the asset balance in the RToken address and attempts to withdraw from the Curve vault if there is insufficient liquidity. However, due to the incorrect withdrawal logic, the function fails to replenish liquidity, causing borrowing and withdrawal operations to revert. The _rebalanceLiquidity
function also attempts to maintain the desired liquidity buffer by depositing or withdrawing assets from the Curve vault.
The _withdrawFromVault
function attempts to withdraw assets from the user (msg.sender
) and send them to the lending pool (address(this)
). This is incorrect because the shares should be burned from LendingPool or another address where vault shares are controlled. And since lending and borrowing reserve assets are handlet at rToken contract withdraw reciever should be rToken contract.
Users cannot borrow or withdraw assets when the protocol needs to replenish liquidity from the Curve vault.
Manual
Update withdraw paramaters and set reciever =reserveRTokenAddress , owner= LendingPool
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.