The quantAMMSwapFeeTake variable is initialized with a value of 0.5e18 (5%) and is updated dynamically through the setQuantAMMSwapFeeTake function. The NatSpec documentation suggests that this value represents the percentage of the total swap fee allocated to the protocol for running costs. However, the behaviour of the variable may lead to misunderstandings, as it does not revert to the default value (0.5e18) after being updated. Instead, it retains the last value set by the function until explicitly updated again. This persistence might contradict user expectations based on the NatSpec notice.
The NatSpec comment for the variable states:
@notice The % of the total swap fee that is allocated to the protocol for running costs.
This could imply that the value is fixed or reverts to the default value (0.5e18) when not explicitly set.
The current implementation allows the quantAMMSwapFeeTake variable to persist the last set value indefinitely until changed by a subsequent call to setQuantAMMSwapFeeTake.
This behavior might cause confusion among developers, auditors, or users who assume the value automatically resets to its initial setting or who expect it to be immutable.
Trust and Clarity: The lack of alignment between documentation and behaviour could lead to misunderstandings about how the protocol allocates swap fees.
Operational Risks: In the absence of explicit constraints, the variable can be set to extreme values (e.g., 0% or 100%), which could significantly disrupt the protocol's revenue model.
Manual Review
Clarify NatSpec Documentation:
Update the NatSpec comment for quantAMMSwapFeeTake to reflect that the value is adjustable and persists until explicitly updated.
Introduce an Optional Reset Mechanism:
Provide a function that resets the value of quantAMMSwapFeeTake to its initial default (0.5e18), if required by the protocol's design.
Validate Input Range:
Ensure that any value set for quantAMMSwapFeeTake is within an acceptable range to prevent disruption to the protocol.
This finding highlights the need for consistency between variable behaviour and its documentation to prevent misinterpretation and maintain protocol integrity.
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelyhood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
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.