Core Contracts

Summary

The BoostController::userBoosts mapping dual-purpose usage of the same data structure for both pool-specific boosts and boost delegation tracking creates ambiguous state interpretations, risking miscalculations of user boosts.

Vulnerability Details

The contract employs a nested mapping userBoosts[user][contextAddress] for two fundamentally different purposes without namespace separation:

1. Pool-Specific Boosts
   Used in functions like updateUserBoost() where contextAddress represents a pool address:

   UserBoost storage userBoost = userBoosts[user][pool];

2. Boost Delegations
   Used in delegation functions like delegateBoost() where contextAddress represents a recipient address:

   UserBoost storage delegation = userBoosts[msg.sender][to];

When any address serves both as:

• A supported pool (via supportedPools mapping)

• A boost delegation recipient

The mapping keys collide, causing:

• Overwritten Data: Delegation records overwrite pool boost data (or vice versa)

• State Corruption: Both systems share the same storage slots despite representing different concepts

• Logical Contradictions: Functions expecting pool context receive delegation data and vice versa

Attack Scenario Example

1. Admin adds 0xAAA as supported pool via modifySupportedPool()

2. User delegates boost to 0xAAA using delegateBoost()

3. The system now contains:

   userBoosts[user][0xAAA] = delegation_data

4. When updateUserBoost(user, 0xAAA) is called:

   • Accesses delegation data instead of pool boost data

   • Corrupts pool boost calculations with delegation parameters

Impact

Incorrect boost multipliers lead to wrongful reward distributions

Tools Used

Manual Review

Recommendations