The vulnerability in the current logic arises in the way the variable quantAMMSwapFeeTake affects the calculation of adminFee within the onAfterSwap function. Specifically, the way the division operation is structured can lead to incorrect fee distribution when the value of quantAMMSwapFeeTake is set to values greater than 0 but less than 1e18.
In UpliftOnlyExample contract, the onAfterSwap function will calculate the adminFee if quantAMMSwapFeeTake is greater than 0:
When quantAMMSwapFeeTake is set to a value like 0.9e18 (which corresponds to 90%), the formula uint256 adminFee = hookFee / (1e18 / quantAMMFeeTake) results in dividing by 1(1e18/0.9e18 = 1), which does not appropriately reflect the intended allocation for the admin fee. The result is that adminFee becomes the entire hookFee, thus assigning 100% of the fee instead of the intended 90%.
This logical mistake in fee calculation can lead to unintended financial outcomes where the protocol retains far greater earnings than anticipated by its economic structure, potentially leading to user dissatisfaction and undermining the trust in the protocol’s fee management policies.
The impact is MEDIUM, the likelihood is MEDIUM, so the severity is MEDIUM.
Manual Review
Consider following fix:
Likelyhood: High, quantAMMFeeTake is a percentage on calculated fees. Being between 30-70% is very likely. Impact: High, fees for LP providers will be lower than expected and 0 if the admin fees is above 50%.
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.