The setEmission function in the BaseGauge contract includes a check that prevents increasing the current emission rate. Specifically, if a new emission value is higher than the current periodState.emission, the function reverts with a RewardCapExceeded error. This behavior makes it impossible to raise the emission rate for the upcoming period using this function—even when such an increase is desired. Although derived contracts (such as those for RAAC and RWA gauges) provide alternative functions (setWeeklyEmission and setMonthlyEmission) that allow updating the emission rate, the restrictive logic in BaseGauge introduces inconsistency and limits flexibility.
What Went Wrong:
The BaseGauge contract defines the setEmission function as follows:
Here, the check if (emission > periodState.emission) revert RewardCapExceeded(); prevents any attempt to increase the emission. This means if the current week's emission is set to a lower value, it cannot be raised for the next week using this function.
Context and Implications:
Inflexible Emission Adjustment: The intended design may require the flexibility to adjust reward emissions upward in response to changing conditions. However, this implementation disallows such increases.
Inconsistency Across Contracts: While the BaseGauge function is overly restrictive, derived contracts provide separate functions (setWeeklyEmission for RAAC and setMonthlyEmission for RWA) that allow updating emissions without this limitation. This discrepancy can lead to confusion and potential mismanagement.
Limited Emission Flexibility:
The inability to increase the emission rate via setEmission can hinder the protocol's ability to adapt its reward distribution in response to market or governance changes.
Operational Confusion:
The presence of conflicting mechanisms (i.e., one function that prevents increases versus alternative functions that allow them) can confuse contract maintainers and governance participants.
Potential Economic Impact:
If the protocol cannot adjust reward emissions upward when needed, it might reduce the attractiveness of the reward system, potentially discouraging user participation and affecting the protocol’s overall economic model.
Manual Code Review: We analyzed the setEmission function in the BaseGauge contract and compared it with the alternative emission-setting functions provided in the derived RAAC and RWA gauge contracts.
Modify the Restrictive Check:
Revise the setEmission function to allow increases in emission. This could involve removing the check or modifying it to support dynamic adjustments for new periods.
Harmonize Emission Management:
Standardize the emission update mechanism across BaseGauge and its derived contracts so that all functions allow upward adjustments when appropriate, or clearly document the intended differences in behavior.
Medium – This issue can hinder proper reward emission management and create operational confusion, particularly in scenarios where an increase in emission is necessary. Although alternative functions in derived contracts mitigate the problem, the BaseGauge implementation still poses a risk of mismanagement and inflexibility.
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.