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.