Open hats-bug-reporter[bot] opened 1 week ago
The reported issue concerning the potential bypass of the minDeposit
logic in ETHmultivault.sol
has been reviewed. Here is our detailed response:
Intended Functionality: The minDeposit
parameter is designed to enforce a minimum deposit amount based on the initial msg.value
provided by the user. This ensures that users deposit a certain minimum amount of ETH, as intended by the protocol.
Deposit Logic: The current implementation checks msg.value
against generalConfig.minDeposit
before subtracting the protocol fee. This design choice ensures that the initial deposit amount meets the required minimum threshold, regardless of the subsequent fee deduction.
Protocol Design: The logic ensures that the minDeposit
requirement applies to the gross deposit amount. This approach simplifies the deposit process and maintains clarity for users, as they only need to ensure their initial deposit meets the minimum requirement without considering fee adjustments.
Conclusion: The existing implementation of the minDeposit
check aligns with our protocol design and intent. The minimum deposit requirement is based on the initial deposit (msg.value
), not the net amount after fee deductions. Therefore, we consider this issue to be functioning as intended and do not see it as a vulnerability.
Status: This issue is invalid.
yes i agree this could be design choice but until its not changed.
the protocolFee is dynamic in protocol. it means the minimum value of deposit also changes and it literally becomes dynamic thing. its can be problematic when third party contracts interacts with protocol.
i don't think this is also design choice otherwise there is no meaning of minDeposit.
Github username: -- Twitter username: -- Submission hash (on-chain): 0x5b8ab189aae573aeb8736742f6e7dc71e6dbae98c32968393f22688903674032 Severity: low
Description: Description\
minDeposit
is created to prevent users from depositing under a specific amount which set from protocol side trough functionsbut the problem is the logic of
minDeposit
is easily bypasable because of the wrong condition checkhere in
depositAtom
function the condition check ofif (msg.value < generalConfig.minDeposit)
done before reducing the fee amount thus it acually makes it possible to bypass the minDeposit logic by just setting minimum value to just same asminDeposit
and then the protocol fee will be subtracted from themsg.value
and eventually the amount would fall under minimum deposit and this conditions could do nothing about it.Recomendation
consider moving the protocol fee subtraction to before the
if
checkuint256 protocolFee = protocolFeeAmount(msg.value, id);
uint256 userDepositAfterprotocolFee = msg.value - protocolFee;
if (userDepositAfterprotocolFee < generalConfig.minDeposit) { revert Errors.MultiVault_MinimumDeposit(); }
if (msg.value < generalConfig.minDeposit) { revert Errors.MultiVault_MinimumDeposit(); }
uint256 protocolFee = protocolFeeAmount(msg.value, id);
uint256 userDepositAfterprotocolFee = msg.value - protocolFee;