Lack of decimal precision in `lpTokenDepositValueChange` will lead to incorrect uplift fee calculations
Summary
The Uplift fee charged to the LPs on withdrawals is calculated using the lpTokenDepositValueChange , however the lpTokenDepositValueChange has no decimal precision and as a result is always rounded down where possible, leading to a decrease in uplift fees generated by the protocol
Vulnerability Details
In UpliftOnlyExample::onAfterRemoveLiquidity, the lpTokenDepositValueChange is calculated as
Due to solidity always rounding down, a 1-99% increase in value will be rounded down to 0% and 101-199% increase in value will be rounded down to 100% and so on.
To better illustrate, consider the following scenario:
lpTokenValue at deposit was 10 usd (localData.lpTokenDepositValue = 10)
lpTokenValue at withdrawal now is 29 usd (localData.lpTokenDepositValueNow = 29)
lpTokenDepositValueChange is then calculated as (29 - 10) / 10 = 19 / 10 = 1.9 (190% increase in value)
However due to lack of decimal scaling, lpTokenDepositValueChange is rounded down to 1, leading to the protocol taking less fees (almost half of the expexted fee).
Impact
High - significant impact on protocol generated fees
Tools Used
Manual Review
Recommendations
Add decimal precision to lpTokenDepositValueChange ,for example
Lead Judging Commences
finding_onAfterRemoveLiquidity_lpTokenDepositValueChange_rounding_error_100%_minimum
Likelihood: High, every call to the function (withdraw) Impact: Low/Medium, uplift fees will be applied only when the price of one asset is doubled but fixed fees will still be collected.
Prize pool breakdown
Live
The contest is live. Earn rewards by submitting a finding.
Appeals
This is your time to appeal against judgements on your submissions.
Appeals Review
Appeals are being carefully reviewed by our judges.