QuantAMM

Summary

A critical arithmetic error in the onAfterRemoveLiquidity function causes a protocol pool’s “uplift” fee calculation to zero out whenever the pool’s value grows less than 100%. Instead of charging an uplift fee, the code mistakenly reverts to the minimum fee, significantly under-collecting fees for moderate or even substantial positive gains. A proof-of-concept demonstrates that with a 50% price increase, the code applies only the minimum fee (5 BPS) instead of the intended 100 BPS uplift fee, potentially leading to major revenue loss.

Vulnerability Details

In the UpliftOnlyExample.sol#L474-L476 snippet below, the deposit’s value change lpTokenDepositValueChange is computed with integer division:

Since Solidity integer division truncates any fractional part, any gain smaller than the deposit’s full value leads to lpTokenDepositValueChange being zero. For example, if a position grows 50% (valueNow = 1.5 × depositValue), the difference (1.5D - 1.0D) is 0.5D, but integer division by 1.0D yields zero.

The immediate downstream effect is shown in UpliftOnlyExample.sol#L478-L490. The code checks whether lpTokenDepositValueChange > 0. If it is zero, the logic incorrectly falls back to the “minimum withdrawal fee,” instead of the intended “uplift fee.”

Hence, even when a depositor’s position appreciates by a moderate percentage (e.g., 10%, 50%, or 80%), the computed lpTokenDepositValueChange remains 0 and triggers the fallback minWithdrawalFeeBps. This drastically undercharges withdrawal fees, effectively nullifying the “uplift” fee logic for positive price changes under 100% growth. As a result, LPs will pay only the minimal fee in scenarios where they would normally be subject to a higher fee based on their real gains.

Impact

This flaw in fee calculation allows LPs to systematically evade the intended uplift fee whenever their position appreciates less than 100%. In real-world conditions, even moderate gains (like 10%, 30%, or 50%) get zeroed out, causing the protocol to charge only the minimum fee instead of a proportionally larger fee based on the actual uplift. As a result, the protocol forfeits significant revenue and violates the intended fee structure:

• Serious Undercharging: The pool cannot collect the correct “uplift” portion, leading to lost revenue that can accumulate quickly over multiple deposits/withdrawals.

• Broken Fee Mechanism: The entire premise of an uplift-based fee becomes unreliable, since nearly any typical growth scenario falls below a factor of 2×, thus never triggering the intended logic.

• Exploitable for Profit: Users aware of this vulnerability can strategically deposit and withdraw under moderate gains to exploit the cheaper fee, amplifying potential losses for the protocol.

Below is a proof-of-concept test demonstrating the incorrect fallback to the minimal fee in a “small positive price change” scenario. The test shows that a 50% increase in pool value still charges only the minimum withdrawal fee instead of the uplift fee:

PoC Test Code

Test Command

Test Result

Tools Used

Manual Review

Recommendations

To fix the integer‐division issue, scale up the difference by 1e18 before dividing by the original deposit value. This ensures fractional parts are not truncated to zero. Specifically:

1. Modify the computation of lpTokenDepositValueChange:

   localData.lpTokenDepositValueChange =

   - (int256(localData.lpTokenDepositValueNow) - int256(localData.lpTokenDepositValue)) /

   + (int256(localData.lpTokenDepositValueNow) - int256(localData.lpTokenDepositValue)) * 1e18 /

   int256(localData.lpTokenDepositValue);

2. Remove the extra * 1e18 factor (or equivalently, do not multiply by 1e18 a second time) when computing feePerLP:

   if (localData.lpTokenDepositValueChange > 0) {

   feePerLP =

   - (uint256(localData.lpTokenDepositValueChange) * (uint256(feeDataArray[i].upliftFeeBps) * 1e18))

   + uint256(localData.lpTokenDepositValueChange) * uint256(feeDataArray[i].upliftFeeBps)

   / 10000;

   } else {

   feePerLP = (uint256(minWithdrawalFeeBps) * 1e18) / 10000;

   }

With these changes, lpTokenDepositValueChange accurately represents a scaled fraction of growth (e.g., 0.5e18 for a 50% gain). The subsequent fee logic then compares it against zero as intended, preventing the protocol from under‐charging fees on modest or moderate gains. This aligns the computed fee with the pool’s actual value appreciation.