There is a logic error in the getBoostMultiplier function of the BoostController contract. This function inaccurately calculates the boost multiplier, always returning the maximum boost value (denoted as 25000, which represents 2.5x). As a result, it disregards the user's actual veRAAC holdings and lock duration. This flaw effectively disables the intended boost mechanism, allowing all users to receive the maximum boost.
getBoostMultiplier (https://github.com/Cyfrin/2025-02-raac/blob/89ccb062e2b175374d40d824263a4c0b601bcb7f/contracts/core/governance/boost/BoostController.sol#L282)
The vulnerability lies in the following lines of code within the getBoostMultiplier function:
The calculation userBoost.amount * 10000 / baseAmount is mathematically equivalent to MAX_BOOST due to how baseAmount is calculated. Substituting the definition of baseAmount into the return statement yields:
Critical Severity: This vulnerability completely undermines the intended boost mechanism.
Unfair Reward Distribution: All users receive the maximum 2.5x boost, regardless of their veRAAC holdings or lock duration. Users who lock a small amount of RAAC for a short period receive the same boost as those who lock a large amount for the maximum duration. This situation is unfair and defeats the purpose of the veRAAC locking system.
Loss of Incentive: The incentive to lock RAAC for longer periods is eliminated, as the boost is consistently maximized.
Manual Review
Modify updateUserBoost: Store the base amount (before applying the boost) in userBoost.amount. The boosted amount should not be stored in persistent storage, as it can be calculated on the fly.
Modify getBoostMultiplier: Calculate and return the boost multiplier (in basis points).
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.