Vote Spamming Alert
Summary
The contract declares a constant VOTE_DELAY intended to prevent users from voting too frequently; however, the vote() function does not enforce this delay.
Vulnerability Details
The intended time-based restriction (using VOTE_DELAY) is not implemented in the vote() function logic. There is no check that compares the current timestamp with lastVoteTime[msg.sender] + VOTE_DELAY.
Explain in relevant detail using numbers and creating scenarios demonstrating the impact
Suppose VOTE_DELAY is set to 10 days. In its absence, a user with 10,000 voting power could cast votes repeatedly—say, 5 votes in a single day. By rapidly changing their vote weight, they can artificially boost the weight of one gauge multiple times, thereby securing a disproportionately high reward share for that gauge. This undermines the fairness intended by the delay mechanism.
Impact
Without enforcing a minimum delay between votes, users can rapidly cast multiple votes in a short period. This can be exploited to manipulate gauge weights or inflate one’s voting influence, thereby skewing reward allocations and potentially undermining the governance process.
Recommendations
Incorporate a check in the vote() function:
Lead Judging Commences
GaugeController::vote never enforces VOTE_DELAY or updates lastVoteTime, allowing users to spam votes and manipulate gauge weights without waiting
GaugeController::vote never enforces VOTE_DELAY or updates lastVoteTime, allowing users to spam votes and manipulate gauge weights without waiting
Prize pool breakdown
Live
The contest is live. Earn rewards by submitting a finding.
Appeals
This is your time to appeal against judgements on your submissions.
Appeals Review
Appeals are being carefully reviewed by our judges.