In revenue distribution, when shares are calculated, it is calculated in a way that it will almost always round down to zero, and will silently fail.
GaugeController::distributeRevenue
is called by EMERGENCY_ADMIN to distribute revenue to gauges. It calls _distributeToGauges
function, which loops through gauges (twice) to calculate the rewards.
In the first loop, totalTypeWeight
is calculated as:
Then, on the second loop gaugeShare
is calculated as:
Now, totalTypeWeight
is the sum of each gauge’s gaugeWeights
value, so it is necessarily bigger than the individual gauge’s weight.
When amount multiplied with the current gauge’s weight is smaller than totalTypeWeight
, the division will round down to zero, and since the next line only calls notifyRewardAmount
only if gaugeShare > 0
it will just fail silently.
Revenue distribution will fail in many cases, breaking the distribution logic and making the dApp more cumbersome. The admin can just call the function with a different/higher amount, yes, but that also means that the admin cannot distribute the revenue with the correct, intended value, and has to either wait for amount accumulation, or opt for a different amount than it should be.
Consider using a decimal scaling like 1e18 in calculations including division.
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.