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.
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.
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.
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.
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.
Manual Review
Add a check to ensure the recipient does not exceed 100 tokens after a transfer:
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.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.