Core Contracts

Summary

The updateUserBoost function in the BoostController contract incorrectly overwrites workingSupply of the entire pool with the newBoost value of the most recent user's update. This is not the intended design, the intended design is to overwrite the working supply of that particular user not the entire pool. This behavior does not accurately track the cumulative workingSupply of the pool, as it disregards the contributions of other users. Additionally, there is no restriction or time lock on when this function can be called, allowing users to repeatedly replenish lost boosts (e.g., from delegation) and redelegate them, potentially leading to manipulation of the pool's rewards distribution.

Affected code: [BoostController::updateUserBoost](https://github.com/Cyfrin/2025-02-raac/blob/89ccb062e2b175374d40d824263a4c0b601bcb7f/contracts/core/governance/boost/BoostController.sol#L198)

Vulnerability Details

The issue lies in the following line of the updateUserBoost function where this line retrieves the boost details of the pool

and this line overwrites the workingSupply of the pool with the newBoost value of the user being updated, instead of adjusting it incrementally. As a result, the workingSupply of the pool no longer reflects the cumulative boost contributions of all users. Instead, it only reflects the boost amount of the most recently updated user.

Furthermore, the function lacks any restrictions or time locks on when it can be called. This means that a user can repeatedly call the function to replenish lost boosts (e.g., from delegation) and redelegate them, potentially manipulating the pool's rewards distribution.

Impact

1. Incorrect Pool Accounting:

   • The workingSupply of the pool is no longer accurate, as it does not account for the working supply boost contributions of all users. This can lead to incorrect calculations and rewards distribution within the pool.

2. Loss of User Contributions:

   • When a user updates their boost, the contributions of other users are effectively erased, as the workingSupply is overwritten. This can lead to unfair rewards distribution and potential loss of funds for users.

3. Potential Exploitation:

   • An attacker could repeatedly call the updateUserBoost function to overwrite the workingSupply with their own boost amount, potentially manipulating the pool's rewards distribution.

4. No Time Lock or Restrictions:

   • The lack of restrictions or time locks on the function allows users to repeatedly replenish lost boosts and redelegate them, leading to potential manipulation of the pool's rewards distribution.

Proof of Concept (PoC)

The following test case demonstrates the issue:

Recommended Fix

To fix this issue, the workingSupply should be updated incrementally based on the difference between the new and old boost amounts, similar to how totalBoost is updated. Additionally, a time lock or restriction should be added to prevent users from repeatedly calling the function to manipulate the pool's rewards distribution. Here is the corrected code:

2 Time Lock or Restriction:

• A time lock or restriction should be added to prevent users from repeatedly calling the function to manipulate the pool's rewards distribution. This can be implemented by adding a cooldown period or limiting the number of times a user can call the function within a certain time frame.