QuantAMM

Summary

in UpliftOnlyExample::addLiquidityProportional() lpTokenDepositValue gets rounded down,
but during onAfterRemoveLiquidity to calculate lpTokenDepositValueNow, its also rounded down, which combined will leak value on the long run.

Vulnerability Details

in UpliftOnlyExample::addLiquidityProportional() we round down the share price registered in poolsFeeData Here
The comment is saying that this favors LP providers, but its not always the case

• Since in onAfterRemoveLiquidity we also round down Here
  This makes it that in some cases,

1. The calculation of share price during addLiquidityProportional() part doesn't truncate (perfect divisions with no remainder)

2. While The calculation of share price during onAfterRemoveLiquidity() truncate the remainder (rounded down)
   In the above scenario, the change of Share price would be less than the actual change

• Since the truncated lpTokenDepositValueNow minus the non truncated lpTokenDepositValue will be lower.

This in the long run leak value on every removeLiquidityProportional and sometimes, those truncated weis will be the decisive cut point to choose to charge upLift fees or normal minWithdrawalFeeBps

NOTE!: if the intention is to be in favor of user calling addLiquidityProportional() then

The above scenario will be reversed with yet bad non intended behavior on that user

1. His lpTokenDepositValue truncates when depositing

2. His lpTokenDepositValueNow doesn't truncate when withdrawing
   widening the gap change of lpTokenDepositValue more than the actual change causing magnified fees paid

Impact

Leakage of value on the long run for QuantAmm admin and current LP providers
OR
Fees over payment by the user that was not the intended design

Tools Used

Manual review

Recommendations

Round up in getPoolLPTokenValue() call during onAfterRemoveLiquidity

If the intention is to lower fees on user during onAfterRemoveLiquidity() then round up during addLiquidityProportional() only and don't change it in onAfterRemoveLiquidity()