Core Contracts

Summary

Boost values are not properly calculated via getBoostMultiplier(), only the MAX_BOOST and MIN_BOOST values can be used, no in between.

Vulnerability Details

The BoostController contract is responsible for managing boost calculations and delegations within the RAAC protocol. It implements a mechanism to calculate boost multipliers for users based on their voting power and other parameters. The getBoostMultiplier() function is designed to return the current boost multiplier for a user in a specific pool. However, the logic within this function results in it returning either the minimum boost (MIN_BOOST) or the maximum boost (MAX_BOOST), with no intermediate values.

The getBoostMultiplier() function retrieves the user's boost amount and calculates a base amount by dividing the user's boost amount by the maximum boost. It then attempts to calculate the boost multiplier by dividing the user's boost amount by this base amount. However, this logic is flawed because it effectively results in a binary outcome: if the user's boost amount is non-zero, the function returns MAX_BOOST; otherwise, it returns MIN_BOOST. This behavior is not aligned with the intended functionality of providing a range of boost multipliers based on user-specific parameters.

The highest impact scenario is that users cannot receive a boost multiplier that accurately reflects their contribution or stake, leading to potential unfairness in the distribution of rewards or benefits within the protocol. This could discourage participation or lead to dissatisfaction among users who expect a more nuanced boost calculation.

Proof of Concept

1. A user interacts with the getBoostMultiplier() function, expecting a boost multiplier that reflects their specific voting power and other parameters.

2. The function checks if the user's boost amount is zero. If it is, the function returns MIN_BOOST.

3. If the user's boost amount is non-zero, the function calculates a base amount and attempts to compute the boost multiplier.

4. Due to the flawed logic, the function returns MAX_BOOST regardless of the user's actual voting power or contribution, as long as the boost amount is non-zero.

Impact

Wrong boost calculations causing inaccurate yield for protocol users.

Tools Used

Manual Review

Recommendations

To address this issue, the logic within getBoostMultiplier() should be revised to ensure that it can return a range of boost multipliers between MIN_BOOST and MAX_BOOST. This can be achieved by implementing a more accurate calculation that considers the user's voting power, total voting power, and other relevant parameters. The calculation should be designed to provide a continuous range of boost multipliers, rather than a binary outcome.

This revised logic calculates the boost multiplier based on the user's voting power relative to the total voting power, providing a more accurate and fair representation of the user's contribution.