QuantAMM

Summary

In the UpliftOnlyExample contract, the intended minimum withdrawal fee (minWithdrawalFeeBps) can be bypassed for small positive price changes, meaning users may end up paying a fee lower than the stated minimum. Specifically, when lpTokenDepositValueChange is positive but the computed “uplift-based” fee is still less than the minimum, the code applies only the smaller fee. This discrepancy contradicts the naming and presumed design for a strict “minimum” fee, enabling partial fee evasion.

Vulnerability Details

At lines 478–490 of UpliftOnlyExample.sol, the contract calculates withdrawal fees based on whether the pool value has increased or decreased since the time of deposit, as shown below:

The underlying intention (implied by the variable name minWithdrawalFeeBps) is that withdrawals should never pay a fee below a certain “minimum.” However, whenever lpTokenDepositValueChange is strictly greater than zero—even if it is an extremely small positive value—the contract uses an “uplift-based” formula. This formula can sometimes yield a fee that is lower than the intended minimum.

As a result:

1. Users only pay the stated minimum fee if the pool has decreased in value (i.e., lpTokenDepositValueChange <= 0).

2. Even very small positive changes can bypass the “minimum” because the computed uplift fee might be smaller than minWithdrawalFeeBps in practice.

3. Fee evasion: By carefully timing or engineering a slight increase in pool value between deposit and withdrawal, a user can end up paying less than the contract’s nominal “minimum withdrawal fee,” contradicting the function’s naming and expected behavior.

Impact

1. Breach of Minimum Fee Assumptions
   The contract’s naming (minWithdrawalFeeBps) and design suggest that withdrawals should never drop below a specified fee floor. The current logic, however, allows a withdrawal fee to be lower than the stated minimum whenever there is a small positive price change.

2. Fee Evasion Possibility
   Users can game minor upward movements in pool value to reduce or sidestep what should be the minimum withdrawal fee. Repeatedly doing so can significantly decrease overall fees paid by adversarial actors.

3. Undermined Tokenomics
   Any protocol revenue model or fair distribution of exit fees relies on the confidence that a stated “minimum fee” is enforced. Once discovered, sophisticated participants (e.g., bots) could exploit minor price fluctuations to systematically reduce their fees, eroding protocol revenue and fairness.

Recommendations

1. Enforce a Floor on the Uplift Fee
   Whenever lpTokenDepositValueChange is greater than zero, calculate the uplift-based fee as normal, then apply a clamp:

   if (lpTokenDepositValueChange > 0) {

   uint256 rawUpliftFeePerLP =

   (uint256(lpTokenDepositValueChange) * (uint256(feeDataArray[i].upliftFeeBps) * 1e18)) / 10000;

   ​

   // Enforce a true minimum fee, never allowing it below minWithdrawalFeeBps

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

   feePerLP = rawUpliftFeePerLP > minFeePerLP ? rawUpliftFeePerLP : minFeePerLP;

   } else {

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

   }

   This ensures that the fee is always at least the stated minimum, even if the computed uplift-based fee is smaller.

2. Confirm Fee Logic Matches Protocol Specification
   If the project’s design intentionally allows reduced fees on small positive changes, rename variables or clearly document it. Otherwise, keep the code strictly aligned with the concept of a “minimum fee.”