Core Contracts

Summary

The BoostController contract’s updateUserBoost function has a vulnerability. Instead of aggregating individual user boost values into the pool’s working supply, the function overwrites the workingSupply with a single user’s boost value. This design flaw can lead to misallocation of rewards, as the workingSupply fails to represent the cumulative boost of all users in a pool.

Vulnerability Details

The vulnerability is located in the updateUserBoost function, specifically on the line:

When a user updates their boost, the function calculates a new boost (newBoost) based on the user’s state. However, rather than updating the pool’s workingSupply by adding the difference between the new and old boost, the function directly assigns newBoost to workingSupply.

Scenarios Illustrating the Issue:

• Single User Update:
  Assume there is only one user in the pool. The user’s boost is updated from an old value to a new value. In this case, setting workingSupply = newBoost effectively reflects that one user’s boost.

  While correct for a single user, the method does not scale when multiple users are involved.

• Multiple Users Updating at Different Times:

  Initial State:

  • User A’s boost: 1000

  • User B’s boost: 2000

  • Correct aggregate workingSupply should be 3000.

  Update by User B:
  Suppose User B calls updateUserBoost and their boost is recalculated to 2500 (an increase of 500).

  • Intended update: The pool’s workingSupply should increase by 500, becoming 3500.

  • Current implementation: It sets workingSupply = 2500.
    Now, the workingSupply reflects only User B’s updated boost and discards User A’s contribution.

  Later Update by User A:
  If User A then updates their boost from 1000 to, say, 1500 (an increase of 500), the function again overwrites workingSupply = 1500.

  • Result: The pool’s workingSupply now reflects just User A’s new boost, and User B’s boost is lost from the aggregate calculation.

At any given time, the pool’s workingSupply becomes equal to the boost of the last user who updated their boost rather than the sum of all users’ boosts.

Impact

• Reward Misallocation:
  Systems that compute reward distributions based on the ratio of a user’s boost to the total workingSupply will calculate incorrect shares. This may allow a single user (or attacker) to claim rewards far exceeding their intended entitlement.

• Pool Dominance:
  The flaw permits the pool’s workingSupply to reflect only the boost of the last user who updated, leading to an unstable and unfair allocation of rewards.

Tools Used

Manual Review

Recommendations

Replace the overwrite operation with an incremental update that adjusts for the change in an individual user’s boost.