In UpliftOnlyExample.sol, the addLiquidityProportional function uses MULDOWN rounding when recording the initial LP deposit value, contrary to the code comment claiming it favors LPs. This actually results in LPs being charged higher fees than intended during withdrawals.
The comment //this rounding favours the LP suggests that the LP should be favored but on the contrary the code uses MULDIRECTION.MULDOWN meaning that the depositValue calculated when LP adds liquidity appears smaller instead of bigger as should be to favor LP.
Note that the lpTokenDepositValue recorded when the LP is adding liquidity is also used when calculating the fee when that same LP is removing that liquidity i.e onAfterRemoveLiquidity
Note that the higher the localData.lpTokenDepositValueChange, the higher the feePerLP calculated as seen above.
In order to favor the LP we need a small value of localData.lpTokenDepositValueChange.
Now the use of MULDIRECTION.MULDOWN when calculating lpTokenDepositValue in addLiquidityProportional function creates an issue where by localData.lpTokenDepositValueChange does not become small enough to favor LP because in the calculation it becomes;
large numerator (current - recorded)
small denominator (recorded value)
large numerator divided by small denominator leads to large localData.lpTokenDepositValueChange
Alice deposits 100 tokens when the pool value per LP token is 1000 USD. But due to MULDOWN rounding, her deposit is recorded as 990 USD per LP token
Pool value increases to 1100 USD per LP token
Actual price appreciation: (1100 - 1000)/1000 = 10%
But calculated as: (1100 - 990)/990 = 11.11%
Alice withdraws her position assuming upliftFeeBps is 2000 (20%)
Actual fee should have been: 10% * 20% = 2% of withdrawal
But charged: 11.11% * 20% = 2.22% of withdrawal
Result: Alice pays 0.22% more in fees than intended. On a $100,000 withdrawal, this is $220 in excess fees. the larger the price appreciation, the greater the excess fee becomes.
LPs are overcharged fees during withdrawal which is against protocol invariant as seen in the comment that LP should be favored.
Manual Review
Change rounding direction in addLiquidityProportional function:
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelyhood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelyhood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.