Core Contracts

Summary

Users can allocate 100% of their voting power in multiple gauges since there isn't a mapping tracking the user's total allocations and that they do not add up to more than 10_000.

Vulnerability Details

Users can vote for gauges in the GaugeController contract. It "implements a Curve-style gauge voting and reward distribution system" with users voting to allocate gauge weights and weights determine the emission rates of rewards:

This implementation differs from the original Curve one. In this contract, users can vote the max weight allocation (10_000) on multiple gauges without having to decrease their weight on the previous gauge. There is no mapping that tracks the user's total power used to make sure that it does not go above 10_000 as standard.

Curve implementation creates a zero-sum game where increasing weight to one gauge requires decreasing weight elsewhere and the sum of all weights cannot exceed 10k, meanwhile The issue here is that:

1. It allows the same voting power to be reused multiple times

2. It removes the key economic trade-off of having to prioritize which gauges get higher weights

3. No meaningful differentiation between gauge importance

4. Potential for reward emission manipulation

5. Loss of the economic game theory that makes gauge voting valuable

Impact

Multiple economic trade-off and game theory reasons which make the original Curve gauges logical and efficient are missing here. There is no zero-sum game and the same voting power can be re-used. This makes the whole gauge voting pointless and it will not work at all since all gauges can effectively have the same weight and cancel themselves out. Rewards emissions will not work as intended.

Tools Used

Manual Review

Recommendations

Don't allow a user's total weight vote spread across multiple gauges to be more than 10_000 by tracking with a mapping.