Core Contracts

Description:
The BoostController::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:
This issue renders the function ineffective for dynamic boost calculation. Instead of varying based on the user's actual contribution, the multiplier is always the same (MAX_BOOST), making the boost logic meaningless. This could lead to incorrect reward distributions, unfair advantages, or unintended protocol behavior.

Proof of Concept:
Consider two cases to illustrate the incorrect calculation:

1. Example 1: userBoost.amount = 20

   baseAmount = 20 * 10000 / 25000 = 8;

   multiplier = 20 * 10000 / 8 = 25000; // Always MAX_BOOST

2. 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.

Recommended Mitigation:
Revise the formula to correctly calculate the boost multiplier without always defaulting to MAX_BOOST. A possible fix could involve properly normalizing userBoost.amount relative to MAX_BOOST without introducing self-canceling terms.