You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
DuplicateA valid issue that is a duplicate of an issue with `Has Duplicates` labelMediumA Medium severity issue.RewardA payout will be made for this issue
Incorrect Handling of Base Pool Caps in Superpool.sol Could Lead to Suboptimal Fund Distribution.
Summary
In the Superpool.sol contract, the current implementation of the deposit() function and its sub-functions may lead to suboptimal fund distribution across the base pools. Specifically, the method for checking and handling the base pool cap is flawed, potentially leaving some base pools underfunded even when they have available capacity.
Vulnerability Detail
The deposit() function in Superpool.sol handles user deposits and distributes them across various base pools using the _deposit() and _supplyToPools() functions. This function goes through depositQueue and deposits into each pool. During this process, the code calculates how much can be deposited into each base pool by considering the cap of the pool(poolCapFor) and the current total assets within it.
However, the current implementation doesn't properly handle the scenario where a base pool has not reached its cap. If the amount to be supplied (supplyAmt) exceeds the available capacity of a base pool (i.e., basepoolCap - total assets in the pool), the deposit is skipped entirely for that pool. This can lead to an inefficient distribution of funds, as the pool still has available capacity that could have been utilized.
If supplyAmt > basepoolCap - total assets in the pool we are not transferring the amount to that pool and going for next but we can transfer the basepoolCap - total assets in the pool amount.
Impact
This vulnerability cannot distribute funds to the basePools according to strategies leading to earn less interest and hence loss of rewards/interest for the lenders. Breaks the logic of depositQueue ordering.
sherlock-admin4
changed the title
Small Wool Squid - Incorrect Handling of Base Pool Caps in Superpool.sol Could Lead to Suboptimal Fund Distribution.
Atharv - Incorrect Handling of Base Pool Caps in Superpool.sol Could Lead to Suboptimal Fund Distribution.
Sep 15, 2024
DuplicateA valid issue that is a duplicate of an issue with `Has Duplicates` labelMediumA Medium severity issue.RewardA payout will be made for this issue
Atharv
High
Incorrect Handling of Base Pool Caps in Superpool.sol Could Lead to Suboptimal Fund Distribution.
Summary
In the
Superpool.sol
contract, the current implementation of thedeposit()
function and its sub-functions may lead to suboptimal fund distribution across thebase pools
. Specifically, the method for checking and handling the base pool cap is flawed, potentially leaving some base pools underfunded even when they have available capacity.Vulnerability Detail
The
deposit()
function inSuperpool.sol
handles user deposits and distributes them across various base pools using the_deposit()
and_supplyToPools()
functions. This function goes throughdepositQueue
and deposits into each pool. During this process, the code calculates how much can be deposited into each base pool by considering thecap of the pool(poolCapFor)
and the current total assets within it.However, the current implementation doesn't properly handle the scenario where a base pool has not reached its cap. If the amount to be supplied (supplyAmt) exceeds the available capacity of a base pool (i.e., basepoolCap - total assets in the pool), the deposit is skipped entirely for that pool. This can lead to an inefficient distribution of funds, as the pool still has available capacity that could have been utilized.
If supplyAmt > basepoolCap - total assets in the pool
we are not transferring the amount to that pool and going for next but we can transfer thebasepoolCap - total assets in the pool
amount.Impact
This vulnerability cannot distribute funds to the basePools according to strategies leading to earn less interest and hence loss of rewards/interest for the lenders. Breaks the logic of depositQueue ordering.
Code Snippet
https://github.com/sherlock-audit/2024-08-sentiment-v2/blob/main/protocol-v2/src/SuperPool.sol#L524
Tool used
Manual Review
Recommendation
Add the condition in
_supplyToPools()
functionDuplicate of #178
The text was updated successfully, but these errors were encountered: