Core Contracts

Summary

Improper voting power calculation in GaugeController

Vulnerability Details

In RAAC, veRAAC token can be used to participate the governance.

1. We can use the veRAAC token to vote for proposals.

2. We can use the veRAAC token to vote for different gauges to get rewards.

   The voting power for proposal is _veToken.getVotingPower(msg.sender), and the voting power for gauge vote is veRAACToken.balanceOf(msg.sender). This will cause that the same veRAAC holder will have different voting power for proposal vote and gauge vote.

In veRAAC, we encourage users to lock their RAAC to keep RAAC price via providing some profit or right to veRAAC holders. Current implementation will decrease the users incentive to extent their lock.

Let's consider the below scenario:

1. Alice locks RAAC to get veRAAC in timestamp X, the locking period is 4 years.

2. In timestamp X + 4 years - 1 day, her voting power for proposals is decreased to almost zero. Now Alice wants to extend her veRAAC for 2 years to recover some voting power for proposals. But she will find out that her balanceOf veRAAC will decrease if she extend for 2 years, which means that it will decrease her voting power for gauges if she wants to extend her veRAAC for 2 years.

3. This will discourage users to lock more. If there is not enough incentive mechanism, RAAC price will drop.

Impact

The voting power calculation between gauges and proposal has some conflict. It will cause that users' voting power for gauges will decrease when they extend their lock.

Tools Used

Manual

Recommendations

Keep the voting power calculation between gauge and proposal consistent. When users create/increase/extend their lock, they will always have more voting power.