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.