First Flight #21: KittyFi
First Flight #21
Beginner FriendlyDeFiFoundry
100 EXP
View results
Previous Next
Submission Details
Severity: high
Valid

A potential Denial of Service (DoS) attack on `KittyVault::executeWhiskdrawal` occurs when the vault collateral is supplied to the Aave protocol.

v1vah0us3

Description

According to the contest documentation "The vault is responsible for maintaining the collateral deposited by user and supply it to Aave protocol to earn yield on it". So once 100% of the collateral in the vault is delivered to Aave to earn interest via KittyVault::purrrCollateralToAave, the totalMeowllateralInVault variable would hold a value of 0. As a result users will not be able to withdraw their collateral anymore by calling KittyPool::whiskdrawMeowllateral function, because the invoked function KittyVault::executeWhiskdrawal will throw an error on underflow of totalMeowllateralInVault variable. This failure results from trying to subtract an amount from totalMeowllateralInVault when it is already zero.

function executeWhiskdrawal(address _user, uint256 _cattyNipToWithdraw) external onlyPool {
uint256 _ameownt = _cattyNipToWithdraw.mulDiv(getTotalMeowllateral(), totalCattyNip);
userToCattyNip[_user] -= _cattyNipToWithdraw;
totalCattyNip -= _cattyNipToWithdraw;
@> totalMeowllateralInVault -= _ameownt;
​
IERC20(i_token).safeTransfer(_user, _ameownt);
}

Impact

Users who rely on withdrawing their collateral will be unable to do so once the vault’s collateral is fully deployed to Aave. This can lead to a situation where legitimate users are locked out of their funds, causing financial inconvenience or loss. The inability to withdraw funds can erode trust in the protocol.

Tools Used

Manual review, vscode

Recommended Mitigation

It's essential to ensure that the KittyVault.sol contract maintains a sufficient balance of collateral to fulfill withdrawal requests. One of the possible solutions would be implementing a strategy where the contract retains a minimum balance of collateral in the vault (liquidity buffer) that cannot be supplied to Aave. This ensures that there is always some collateral available for immediate withdrawal requests. In general, it is recommended to clearly communicate how liquidity and yield optimization will be managed and to set user expectations regarding withdrawal times and possible delays during high demand periods. Consider making the following change to KittyVault.sol:

​
+ uint256 public liquidityBuffer;
​
+ function setLiquidityBuffer(uint256 _newBuffer) external onlyMaintainer {
+ liquidityBuffer = _newBuffer;
+ }
​
function purrrCollateralToAave(uint256 _amountToSupply) external onlyMaintainer {
+ require(totalMeowllateralInVault >= _amountToSupply + liquidityBuffer, "InsufficientBuffer");
totalMeowllateralInVault -= _ameowntToSupply;
IERC20(i_token).approve(address(i_aavePool), _ameowntToSupply);
i_aavePool.supply( { asset: i_token, amount: _ameowntToSupply, onBehalfOf: address(this), referralCode: 0 } );
}
Updates

Lead Judging Commences

shikhar229169 Lead Judge 10 months ago
Submission Judgement Published
Validated
Assigned finding tags:

Users can't withdraw meowllateral if requested amount is not present in vault as it is supplied to Aave

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.