The vote function in the GaugeController contract is vulnerable to vote spamming due to a missing check on lastVoteTime[msg.sender]. The contract defines a VOTE_DELAY constant (intended to be 10 days), which should be the minimum time between consecutive votes by the same user. However, the vote function does not enforce this delay, allowing a user to call vote repeatedly within a short period (even within the same block), thereby manipulating the gauge weights.
The vote function in GaugeController.sol is designed to allow veRAAC token holders to vote on the weights assigned to different gauges. The relevant code is as follows:
The contract does have a lastVoteTime mapping:
And a VOTE_DELAY constant:
However, the vote function fails to check whether enough time has passed since the user's last vote.
Gauge Weight Manipulation: An attacker can artificially inflate or deflate the weight of a specific gauge, influencing the distribution of rewards.
Unfair Reward Distribution: By manipulating gauge weights, an attacker can direct a larger share of rewards to gauges they favor, at the expense of other users.
Undermining Governance: The integrity of the gauge voting system is compromised, as the weights do not accurately reflect the long-term preferences of veRAAC holders.
Define a custom error VoteTooFrequent in the IGaugeController interface and implement it in GaugeController.sol for better error handling and clarity.
Add a check to the vote function to ensure that VOTE_DELAY has elapsed since the user's last vote. Also, update lastVoteTime[msg.sender] after a successful vote.
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.