The vote function allows users to allocate their voting power (veRAACToken balance) to a gauge, influencing reward distribution. However, the contract does not properly enforce a voting delay, allowing users to rapidly change votes to manipulate gauge weights unfairly. While the contract defines a VOTE_DELAY constant (10 days), it fails to check whether the required delay has passed since the user's last vote before allowing a new vote. The function:
Since there is no check for lastVoteTime[msg.sender], a user can continuously update their votes, shifting weight between gauges within a single block to game the reward distribution system, allocating emissions to themselves unfairly.
The primary impact is that a malicious user can manipulate reward emissions by frequently reallocating votes, leading to an unfair distribution of rewards and governance power, disrupting the incentive mechanism.
Enforce the voting delay by adding a time check in vote before allowing a new 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.