QuantAMM

QuantAMM
49,600 OP
View results
Submission Details
Severity: low
Invalid

UpliftOnlyExample::addLiquidityProportional Function Fails to Properly Limit the Number of Deposits Per User to 100

Summary

In the addLiquidityProportional function, the contract does not effectively limit the maximum number of deposits per user. Although the function attempts to check the number of deposits with if (poolsFeeData[pool][msg.sender].length > 100), the condition is incorrectly implemented. It should be >= 100 instead of > 100. As a result, users are still allowed to deposit even after making 100 deposits, leading to potential unintended behavior, including denial-of-service (DDoS) attacks.

Vulnerability Details

The contract contains a logic error in the check used to limit the number of deposits for each user. Specifically, the condition poolsFeeData[pool][msg.sender].length > 100 should be changed to >= 100 to properly enforce the limit. The current implementation allows deposits beyond the 100 deposit threshold, which is not the desired behavior. This issue may result in:

  1. Deposit Limit Not Being Enforced: Users may be able to deposit more than 100 times, violating the intended deposit restriction.

  2. Inconsistent Behavior: The deposit limit logic is not working as expected, leading to inconsistent contract behavior, making the contract difficult to maintain and predict.

Impact

This vulnerability could lead to the following problems:

  1. Inconsistent Contract Behavior: Due to the incorrect deposit limit check, the contract will not behave as intended, causing difficulty in predicting its actions.

  2. Resource Exhaustion: The system could be abused by a single user making excessive deposits, potentially causing resource exhaustion, such as high gas costs or affecting the platform’s stability.

  3. Denial-of-Service (DDoS) Risk: The incorrect logic could be exploited by malicious users, leading to a flood of transactions and causing denial-of-service attacks, degrading the service for other users.

Tools Used

Manual code audit

Recommendations

It is recommended to fix the deposit check logic by changing the condition to >= 100. This ensures that the contract enforces the deposit limit correctly. Below is the corrected code:

function addLiquidityProportional(
address pool,
uint256[] memory maxAmountsIn,
uint256 exactBptAmountOut,
bool wethIsEth,
bytes memory userData
) external payable saveSender(msg.sender) returns (uint256[] memory amountsIn) {
// Fix: Correct the deposit limit check to >= 100
+ if (poolsFeeData[pool][msg.sender].length >= 100) {
revert TooManyDeposits(pool, msg.sender);
}
// Proceed with adding liquidity
amountsIn = _addLiquidityProportional(
pool,
msg.sender,
address(this),
maxAmountsIn,
exactBptAmountOut,
wethIsEth,
userData
);
uint256 tokenID = lpNFT.mint(msg.sender);
// Get the pool's LP token value
uint256 depositValue = getPoolLPTokenValue(
IUpdateWeightRunner(_updateWeightRunner).getData(pool),
pool,
MULDIRECTION.MULDOWN
);
// Record fee data for the deposit
poolsFeeData[pool][msg.sender].push(
FeeData({
tokenID: tokenID,
amount: exactBptAmountOut,
lpTokenDepositValue: depositValue,
blockTimestampDeposit: uint40(block.timestamp),
upliftFeeBps: upliftFeeBps
})
);
nftPool[tokenID] = pool;
}

By making this change, the contract will correctly enforce the deposit limit and prevent users from exceeding the allowed number of deposits.

Updates

Lead Judging Commences

n0kto Lead Judge 7 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

invalid_Uplift_101_deposit_strict_equal

Only 1 more NFT won’t have any impact. Informational.

Support

FAQs

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