Core Contracts

Summary

The BoostController contract implements a boost system where users can receive multipliers on their rewards or voting power. The system is designed to provide variable boost multipliers between 1x (10000) and 2.5x (25000) based on user contributions.

Vulnerability Details

The getBoostMultiplier function is intended to calculate a user's boost multiplier for a given pool. However, due to a miscalculation in the formula, the function always returns a fixed value of MAX_BOOST (25000) when userBoost.amount > 0, regardless of the actual userBoost.amount.
The issue arises from the calculation of baseAmount:

Since baseAmount is derived from userBoost.amount, the division cancels out the variable component, always yielding the maximum boost.

Impact

Impact
All users with any non-zero boost amount receive the maximum 2.5x multiplier, completely breaking the intended variable boost mechanics and creating unfair advantages in the protocol's reward and voting systems.

Impact Explanation

Medium. While this issue significantly impacts the protocol's boost mechanics and creates unfairness in reward distribution, it doesn't result in direct fund loss or complete system failure. However, it undermines a core protocol mechanism designed for balanced incentivization.

Proof of Concept:

Consider two cases to illustrate the incorrect calculation:

Example 1:

userBoost.amount = 20
baseAmount = 20 * 10000 / 25000 = 8;
multiplier = 20 * 10000 / 8 = 25000; // Always MAX_BOOST

Example 2:

userBoost.amount = 10
baseAmount = 10 * 10000 / 25000 = 4;
multiplier = 10 * 10000 / 4 = 25000; // Again, always MAX_BOOST

In both examples, the function incorrectly returns MAX_BOOST instead of a value dependent on userBoost.amount.

Tools Used

Manual Review

Recommendations

The boost calculation formula should be revised to properly scale between MIN_BOOST and MAX_BOOST based on the user's boost amount. A possible implementation would be:\