Summary:

While the contract defines a VOTE_DELAY constant (10 days) and tracks lastvoTeTime for users, it fails to enforce the delay between votes. The code does not check or update the lastVoteTime mapping during voting.

Vunearbility Details:

There's a VOTE_DELAY constant defined but not enforced in the vote function. Also the modifier isn't checking the lastVoteTime. The code in vote function doesn't check if the user has waited (VOTE_DELAY) since their last vote. Also there is no update in lastVoteTime mapping when during voting . Further more in the vote function, there's no check for lastVoteTime. The user can vote multiple times without waiting. But the comment says there's a required delay between votes. That's a discrepancy. The code doesn't enforce the VOTE_DELAY, which is a vulnerability. Users can vote multiple times in quick succession, potentially spamming or manipulating weights.

The fact that GaugeController.sol has a mapping lastVoteTime in it contract storage but doesn't use it in the vote function makes it a flaw in the contract logic.

Impact:

Attackers can spam votes to manipulate gauge weights, compromising the fairness of the governance system and centralize control by overriding others' votes before the delay period.

Tools Used: Manual review

Recommendations:

Add vote delay enforcement in the vote function.