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

Users transferring their NFT position will retroactively get the new `upliftFeeBps`

0xhuntoor

Summary

When user transfer his NFT LP position to another wallet, the new upliftFeeBps is registered to poolsFeeData of the to, this contradict the intended design to have no retroactive upliftFeeBps applied to already open position and also opens an attack surface to dodge the old high fees for the current smaller ones

Vulnerability Details

NOTE!: its worth mentioning that this is a different bug from the bug that talks about complete dodging of UpLift fees through lpTokenDepositValue overriding

When user adds liquidity, the upliftFeeBps is registered in his poolsFeeData so that any future change doesn't apply to his position retroactively

File: UpliftOnlyExample.sol
219: function addLiquidityProportional()
​
249:
250: poolsFeeData[pool][msg.sender].push(
251: FeeData({
252: tokenID: tokenID,
253: amount: exactBptAmountOut,
254: //this rounding favours the LP
255: lpTokenDepositValue: depositValue,
256: //known use of timestamp, caveats are known.
257: blockTimestampDeposit: uint40(block.timestamp),
258: upliftFeeBps: upliftFeeBps
259: })
260: );
​
263: }

But the problem is that in afterUpdate hook that is triggered on NFT transfers, the upliftFeeBps of poolsFeeData of to is set to the current upliftFeeBps

File: UpliftOnlyExample.sol
576: function afterUpdate(address _from, address _to, uint256 _tokenID) public {
​
609: feeDataArray[tokenIdIndex].lpTokenDepositValue = lpTokenDepositValueNow;
610: feeDataArray[tokenIdIndex].blockTimestampDeposit = uint32(block.number);
611: feeDataArray[tokenIdIndex].upliftFeeBps = upliftFeeBps;
612:
613: //actual transfer not a afterTokenTransfer caused by a burn
614: poolsFeeData[poolAddress][_to].push(feeDataArray[tokenIdIndex]);
​

this causes two problems:

  1. New fees are applied retroactively, which is not the intention of the protocol (Broken functionality)

  2. There can be scenarios where upliftFeeBps was set by the admin to lower values than the ones the user initially deposited at (ie, events of lower fees, or simply the admin wants to do it due to increased competition in the field that provided less fees, etc)

    • When that happens, the user can transfer the NFT to other wallet of his own so that the upliftFeeBps variable gets overridden by the new one

Impact

  • Non intended design

  • User can decide to override their upliftFeeBps when they see it less costly to pay (overall profitable to them)

    • Leading to loss of funds (Fees) to the Quant Admin and LP providers (since there should have been larger fees donated to their pool)

Tools Used

Manual review

Recommendations

Don't override that variable, simply remove Line 611

Updates

Lead Judging Commences

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

finding_afterUpdate_update_upliftFeeBps

Likelihood: High, any transfer will trigger the bug. Impact: Low, will update upliftFeeBps to the new current value which will increase or decrease the fees, but at the moment there is no setter for upliftFeeBps ! So it won't change anything (but this setter should exists according the sponsor)

Support

FAQs

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