The BaseGauge.sol contract defines minBoost and maxBoost to calculate user boosts. When users stake, withdraw, or getreward, the updateReward(msg.sender) function updates their reward state using the minBoost and maxBoost values. If the boostRange is improperly set, it causes underflow or overflow, leading to reward calculation failures.
RAACGauge and RWAGauge both inherits BaseGauge.sol defines minBoost and maxBoost which helps in calculating boost for the user in the BaseGauge. where minBoost should be lower than maxBoost. When user create checkpoint for reward Calculation SLOC#599-604 , stake SLOC#257-267, withdraw SLOC#269-280 or try to claim reward with getReward SLOC#323-347 it will first execute the updateReward(msg.sender) helps in user to Update reward state for an account state.reward is calculate for user to get users current weight including boost SLOC#584, SLOC#594.
This function _applyBoost() will use the minBoost and maxBoost value stored in the boostState at the contract deployment (in constructor) SLOC#140-143
and will calculate the Boost With Provided Params set in the function call of the _calculateBoost() SLOC#246
After that BoostCalculator::calculateBoost does this calculation SLOC#89.
in our case maxboost: 25000 and minBoost: 1e18 contract is deployed with version ^0.8.19 this already checks for the underflow and overflow value in contract and revert. boostRange value will lead to underflow and calculation fails. Reward can't be calculated due constantly failing of the function.
If any user try to execute any of this stake, withdraw, getReward, notifyReward, voteDierction, checkPoint functions it will revert due to undeflow of the boost calculation.
Manual Review
minBoost should be lower than maxBoost.
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.