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.