QuantAMM

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

Griefing attack on users

Summary

Users can be prevented from using UpliftOnlyExample.addLiquidityProportional by increasing their poolsFeeData[pool][msg.sender].length via LP NFT transfers.

Vulnerability Details

While the addLiquidityProportional function has a check which prevents adding too many LP NFT, the afterUpdate has no such check.
This way malicious user can spam other user with LP NFT to prevent adding liquidity

function addLiquidityProportional(
address pool,
uint256[] memory maxAmountsIn,
uint256 exactBptAmountOut,
bool wethIsEth,
bytes memory userData
) external payable saveSender(msg.sender) returns (uint256[] memory amountsIn) {
if (poolsFeeData[pool][msg.sender].length > 100) {
revert TooManyDeposits(pool, msg.sender);
}
<...>
function afterUpdate(address _from, address _to, uint256 _tokenID) public {
<...>
if (tokenIdIndexFound) {
if (_to != address(0)) {
// Update the deposit value to the current value of the pool in base currency (e.g. USD) and the block index to the current block number
//vault.transferLPTokens(_from, _to, feeDataArray[i].amount);
feeDataArray[tokenIdIndex].lpTokenDepositValue = lpTokenDepositValueNow;
feeDataArray[tokenIdIndex].blockTimestampDeposit = uint32(block.number);//@audit is correct function for all chains
feeDataArray[tokenIdIndex].upliftFeeBps = upliftFeeBps;
//actual transfer not a afterTokenTransfer caused by a burn
>> poolsFeeData[poolAddress][_to].push(feeDataArray[tokenIdIndex]);

Impact

Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol)

Tools used

Manual Review

Recommendations

Consider implementing a restriction for LP NFT transfers when the poolsFeeData[pool][msg.sender].length exceeds the limit. Consider using an even lower limit for afterUpdate than for addLiquidityProportional or whitelisted senders.

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.