Core Contracts

Summary

The BoostController contract includes a configurable parameter (boostState.maxBoost) that is intended to allow adjustment of the maximum boost multiplier. However, in the boost calculation logic within the _calculateBoost function, a constant value (MAX_BOOST, set to 25000, representing a 2.5× multiplier) is used to cap boosted amounts. This discrepancy means that even if administrators update the maximum boost through setBoostParameters, the effective cap remains fixed at 2.5×. It is currently unclear whether this behavior is an intentional design decision or an unintentional oversight.

Vulnerability Details

The function _calculateBoost computes a user's boost and then applies a cap as follows:

Here, MAX_BOOST is a constant set to 25000. Although the contract maintains a configurable parameter boostState.maxBoost (which can be updated via the setBoostParameters function), this parameter is never used in the calculation. As a result, even if an administrator sets a new value for the maximum boost, the effective cap remains at 2.5×.

Intentional vs. Unintentional:

• Unintentional: If the original design intended to allow flexibility in the maximum boost multiplier, then using the fixed constant MAX_BOOST is an oversight. This bug prevents any boost multiplier above 2.5× from being applied, contrary to expectations set by the configuration function.

• Intentional: If the design deliberately enforces a fixed cap of 2.5× for safety or economic stability, then having a configurable parameter for maximum boost becomes misleading. Administrators might expect to adjust the boost multiplier, but the implementation would override any changes.

This issue goes down to affect the following functions one or the other:

• _calculateBoost: The function that computes and caps the boost value directly uses the constant MAX_BOOST.

• updateUserBoost: This function calls _calculateBoost to update a user’s boost; hence, it inherits the issue.

Impact

1. Suppose the intention was to allow a higher boost multiplier to incentivize greater participation or lock-up amounts. In that case, the inability to adjust the cap may lead to a misalignment with the protocol’s economic design. The protocol may not be able to offer the intended rewards.

2. Administrators may be misled into believing that changing boostState.maxBoost through setBoostParameters will affect the boost calculations. In reality, the constant cap remains unchanged, resulting in potential misconfigurations and a false sense of control over boost parameters.

Tools Used

Manual Review

Recommendations

1. Modify the _calculateBoost function to use the configurable parameter boostState.maxBoost instead of the constant MAX_BOOST. This change will make sure that updates made via setBoostParameters are properly reflected in the boost calculations.

2. Clarify Design Intent. If the fixed cap of 2.5× is intentional, update the code to reflect this decision and consider removing the configurable parameter to avoid confusion.

   If flexibility is desired, clearly document that the maximum boost multiplier is fully adjustable and that the implementation should adhere to the configured value.