QuantAMM

QuantAMM
49,600 OP
View results
Submission Details
Severity: medium
Valid

Users can bypass the token limit to accumulate excess tokens and DoS legitimate users in `UpliftOnlyExample` contract

Summary

The afterUpdate() function in the UpliftOnlyExample contract is called after each NFT transfer to update the fee data associated with the transferred NFT. However, there is no restriction on the number of NFTs a recipient can hold, potentially allowing a user to exceed the intended limit of 100 tokens per address.

Vulnerability Details

The contract is designed to limit each address to a maximum of 100 deposits, as enforced in the addLiquidityProportional function.

The afterUpdate() function, which updates poolsFeeData after an NFT transfer, and which does not enforce this limit when NFTs are transferred between addresses.

So the lack of 100-token limit for the recipient, allowing them to accumulate more than 100 tokens through transfers.

Users can bypass the intended 100-token limit by receiving tokens through transfers, allowing them to hold more than the permitted 100 tokens. Additionally, they can transfer a large number of NFTs created with dust deposits, potentially disrupting or griefing other legitimate users.

Impact

  1. Accumulating Excess Tokens:

    • A user can bypass the 100-token limit by receiving NFTs through transfers, allowing them to accumulate an excessive number of tokens in a single address. This could lead to resource exhaustion and potential manipulation of the pool's operations.

  2. Denial of Service (DoS) via Dust Liquidity:

    • A malicious user can exploit this vulnerability by adding minimal "dust" liquidity to create numerous NFTs.

    • These NFTs can then be transferred to other users, filling their poolsFeeData array with small, insignificant deposits.

    • The FILO (First In, Last Out) model for liquidity removal requires processing these small deposits first, making it difficult for affected users to remove their larger, meaningful liquidity positions efficiently.

    • Transferring a large number of NFTs can also lead to out-of-gas issues during execution, effectively causing a DoS attack on NFT transfers and liquidity removal.

  3. Liquidity Addition Restriction:

    • Users who have reached or exceeded the 100-token limit due to these dust NFTs are unable to add more liquidity, as the contract enforces this limit during the addLiquidityProportional function.

Tools Used

Manual Review

Recommendations

Add a check to ensure the recipient does not exceed 100 tokens after a transfer:

function afterUpdate(address _from, address _to, uint256 _tokenID) public {
if (msg.sender != address(lpNFT)) {
revert TransferUpdateNonNft(_from, _to, msg.sender, _tokenID);
}
+ if (poolsFeeData[pool][_to].length > 100) {
+ revert TooManyDeposits(pool, _to);
+ }
Updates

Lead Judging Commences

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

finding_afterUpdate_does_not_check_limit_NFT_per_user

Likelihood: Medium/High, anyone can receive an unlimited NFT number but will cost creation of LP tokens and sending them. Impact: Low/Medium, DoS the afterUpdate and addLiquidityProportional but will be mitigable on-chain because a lot of those NFT can be burn easily in onAfterRemoveLiquidity.

Support

FAQs

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

Give us feedback!