The functions setQuantAMMUpliftFeeTake
and setQuantAMMSwapFeeTake
both modify the same state variable, quantAMMSwapFeeTake
. If there is no distinct variable for the uplift fee (e.g., quantAMMUpliftFeeTake
), this is likely an oversight. The current implementation leads to redundant and potentially confusing code, as both functions appear to manage different fees but share the same state variable.
If these functions are truly intended to manage different values, a new state variable must be introduced. Otherwise, setQuantAMMUpliftFeeTake
and its associated getter should be removed to eliminate redundancy.
The state variable quantAMMSwapFeeTake
is modified by both functions:
setQuantAMMSwapFeeTake
Function:setQuantAMMUpliftFeeTake
Function:Both functions modify the variable quantAMMSwapFeeTake
and use it inconsistently in their respective getter functions.
Code Redundancy: setQuantAMMUpliftFeeTake
and getQuantAMMUpliftFeeTake
add no new functionality but create confusion.
Loss of Purpose: The distinction between swap fees and uplift fees is lost, potentially leading to errors in the protocol’s operation.
Misleading Emit Events: The emitted events (SwapFeeTakeSet
and UpliftFeeTakeSet
) suggest different actions but result in identical state changes.
If these fees are intended to represent different metrics, introduce a new state variable (e.g., quantAMMUpliftFeeTake
) for the uplift fee. Update the associated functions accordingly:
If no distinct variable for the uplift fee is intended, remove setQuantAMMUpliftFeeTake
and getQuantAMMUpliftFeeTake
entirely:
Likelyhood: High, calling setters or getters Impact: Low/Medium, both getters return `quantAMMSwapFeeTake` and `setQuantAMMUpliftFeeTake` modify `quantAMMUplfitFeeTake`. Real impact: those 2 values will be always the same.
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.