Core Contracts

Summary

In the BoostController contract A critical accounting mismatch exists between delegated boosts and pool statistics, allowing delegated boosts to bypass proper tracking in pool totals. This leads to incorrect boost calculations and potential manipulation of protocol metrics.

Vulnerability Details

The vulnerability stems from two key flaws in the delegation logic:

1. Incomplete Boost Accounting in delegateBoost:
   When users delegate boosts via delegateBoost(), the delegated amount is stored in userBoosts but not added to the pool's totalBoost (in poolBoosts[pool]). This creates a discrepancy between the actual delegated boost and the pool's recorded boost total.

2. Unsafe Subtraction in removeBoostDelegation:
   The function attempts to reduce the pool's totalBoost by the delegated amount without ensuring it was previously added. Since delegated boosts are never reflected in totalBoost, this operation will often underflow (when totalBoost < delegation.amount) or leave stale data (when totalBoost == 0).

Attack Scenario:

1. Alice delegates 1000 boost to Pool X via delegateBoost().

   • userBoosts[Alice][X].amount = 1000

   • poolBoosts[X].totalBoost remains unchanged (e.g., 0).

2. After the delegation expires, Pool X calls removeBoostDelegation(Alice).

   • The contract tries to subtract 1000 from poolBoosts[X].totalBoost (which is 0), triggering an underflow revert (if using SafeMath) or leaving totalBoost incorrect.

Impact

• Inaccurate Boost Tracking: Pools display inflated/deflated boost totals, undermining reward distribution fairness.

• Protocol Manipulation: Attackers could spam delegations/removals to corrupt pool metrics, destabilizing the system.

• Denial-of-Service: Underflow reverts in removeBoostDelegation() could permanently lock delegated boosts.

Severity: Medium (breaks core accounting guarantees, but requires specific user actions to exploit).

Tools Used

• Manual code review focusing on state variable interactions.

• Control flow analysis for delegation/removal logic.

Recommendations

1. Sync Delegated Boosts with Pool Totals:
   Modify delegateBoost() to increment poolBoosts[to].totalBoost:

   function delegateBoost(...) external ... {

   // Add check: ensure 'to' is a supported pool

   if (!supportedPools[to]) revert PoolNotSupported();

   PoolBoost storage poolBoost = poolBoosts[to];

   poolBoost.totalBoost += amount; // Track delegation in pool total

   // ... rest of logic

   }

2. Remove Conditional Check in Removal:
   Update removeBoostDelegation() to unconditionally decrease totalBoost:

   function removeBoostDelegation(...) external ... {

   // Remove unsafe check

   poolBoost.totalBoost -= delegation.amount; // Reverts on underflow if misconfigured

   // ... rest of logic

   }

3. Add Validation in delegateBoost:
   Ensure delegations only target supported pools:

   require(supportedPools[to], "Invalid pool");

4. Testing:
   Add unit tests validating that:

   • totalBoost increases/decreases correctly during delegation/removal.

   • Delegations to unsupported pools revert.

By aligning delegation actions with pool accounting, the protocol will maintain accurate boost tracking and prevent exploitation.