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

Incomplete implementation of deposit limit tracking

0xtheblackpanther

Summary

The UpliftOnlyExample implements a 100 deposit limit that can be bypassed through deposit cycling, while having an unused _nextTokenId variable that could have been utilized to track total historical deposits. This suggests an incomplete implementation of the deposit tracking mechanism.

Impact

  • The 100 deposit limit can be cycled (deposit->withdraw->deposit again) making the limit ineffective if it was meant to be a hard cap

  • _nextTokenId exists but is never used, suggesting a possible abandoned implementation of historical deposit tracking

PoC

// 1. Unused tracking variable
uint256 private _nextTokenId; // Never used but could track total deposits @audit-poc
​
// 2. Current limit implementation only checks array length
if (poolsFeeData[pool][msg.sender].length > 100) {
revert TooManyDeposits(pool, msg.sender);
}
​
// 3. Can be cycled:
- Make 90 deposits
- Withdraw (which reduces array via delete and pop())
- Make new deposits as array length < 100
- Repeat for unlimited deposits

Recommendation

Either remove the unused _nextTokenId variable or utilize it to track total historical deposits if that was the original intent

or add clear documentation about the gas optimization purpose:

// @notice Limit of 100 concurrent deposits per user to prevent excessive gas
// costs during withdrawals and transfers. Users can cycle deposits through
// withdraw-deposit pattern as this is a gas optimization, not a security measure.
if (poolsFeeData[pool][msg.sender].length > 100) {
revert TooManyDeposits(pool, msg.sender);
}
Updates

Lead Judging Commences

n0kto Lead Judge 7 months ago
Submission Judgement Published
Invalidated
Reason: Design choice

Support

FAQs

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