The _calculateReward function miscalculates the rewards for a gauge due to incorrect scaling of weight fractions, potentially leading to excessive or insufficient fund distribution. The issue arises because both gaugeShare and typeShare are calculated as fractions in basis points (/ WEIGHT_PRECISION), but they are multiplied together before dividing by WEIGHT_PRECISION * WEIGHT_PRECISION, causing an unintended double scaling effect. This miscalculation results in an artificially lower reward allocation in some cases, preventing fair distribution, or an over-allocation in edge cases where WEIGHT_PRECISION adjustments occur. Additionally, _calculateReward does not check if the gauge is active, allowing inactive gauges to receive rewards. Furthermore, there is no upper bound on rewards, meaning if _calculateRWAEmission() or _calculateRAACEmission() returns unexpectedly high values, the function may allocate an unbounded amount, potentially draining funds. The problematic code snippet:
Since both gaugeShare and typeShare are already scaled, dividing by an additional WEIGHT_PRECISION * WEIGHT_PRECISION over-reduces the final amount, leading to incorrect reward assignments.
The primary impact is that malicious or misconfigured gauges can drain excessive rewards, disrupting the fair allocation mechanism and leading to potential loss of protocol funds.
Correct the reward calculation formula by properly scaling fractions, ensure inactive gauges do not receive rewards, and implement a maximum cap on distributed rewards to prevent overflow.
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.