Core Contracts

Summary

The _applyBoost function is intended to increase a user's reward based on the amount of staking tokens they have deposited in the gauge (whether in RAAC or RWA). However, the current implementation calculates the boost based solely on the user's balance of veRAAC tokens (the governance token) obtained from the GaugeController. This design flaw means that the boost is determined by the total amount of veRAAC tokens held by the user rather than by the tokens actually staked in the gauge, which may result in users not receiving the maximum boost they deserve for their staked tokens.

Vulnerability Details

What Went Wrong:
The function is implemented as follows:

Instead of calculating boost based on the amount of tokens staked in the gauge (which is tracked in the gauge’s internal state), it relies on the balance of veRAAC tokens held by the user. This means:

Users who have locked a large number of tokens (and thus hold many veRAAC tokens) may get a high boost even if they haven’t staked a commensurate amount in the gauge.

Conversely, users who stake a significant number of tokens in the gauge might not achieve a maximum boost if their overall veRAAC token balance is low.

Why It Matters:
The intended incentive is to reward users proportionally to the amount they stake in the gauge. By basing the boost on the veRAAC token balance (which reflects locking rather than staking), the system may not properly incentivize users to deposit their tokens into the gauges. This misalignment could discourage staking, reduce overall participation, and lead to suboptimal reward distribution.

Even if a user who has not staked in this raac or rwa gauge can start accumilating the rewards, by simply calling the getreward()function(in this step they don't get rewards instantly but they will start accquiring the rewards even if they have never staked).

Example Scenario

User A:
Locks a large amount of RAAC tokens to receive many veRAAC tokens but only stakes a modest amount in the gauge.

User B:
Stakes a large amount in the gauge but does not lock additional tokens, resulting in a lower veRAAC balance.

Outcome:
Despite staking more tokens, User B receives a lower boost compared to User A because the boost calculation depends solely on the veRAAC balance. This creates an unfair advantage and may discourage large deposits into the gauge.

Impact

Incentive Misalignment:
The boost mechanism does not accurately reward users based on their staked tokens, potentially leading to a scenario where users with high veRAAC balances (but low staked amounts) benefit disproportionately.

Reduced Participation:
Users may be discouraged from staking in the gauges if they cannot achieve the expected boost based on their actual deposits, which can negatively affect overall protocol participation.

Economic Imbalance:
Incorrect boost calculation can lead to a misallocation of rewards, undermining the economic model of the protocol.

Tools Used

Manual Code Review: We analyzed the _applyBoost function and its dependencies, noting that it exclusively relies on the veRAAC token balance from the GaugeController rather than using the actual staking amounts in the gauge.

Recommendations

Modify the _applyBoost function to base the boost calculation on the actual amount of tokens staked in the gauge. For example, reference the internal staking balance (e.g., using the _balances mapping) instead of the veRAAC token balance.