Core Contracts

Summary

The BoostController contract contains a critical flaw in its delegation mechanism, specifically regarding how boosts are managed for delegatees. The current implementation prevents delegatees from utilizing boosts that have been delegated to them, as these boosts are not recognized within the supported pools.

Vulnerability Details

The issue arises from the way boosts are stored and accessed in the contract. The mapping for user boosts is defined as follows:

When a user delegates their boost to another address, the boost is stored using the following line:

This means that the boost is recorded under the delegator's address (msg.sender) and the delegatee's address (to). However, the check for whether a pool is supported is performed in the updateUserBoost function:

Since the delegated boost is not added to a supportedPool, the delegatee cannot access or utilize the boost. Even if the delegator's address were to be added as a pool, it would not resolve the issue because the delegation mechanism specifically uses the mapping:

If the intention was to allow delegatees to utilize the boosts, the mapping should have been structured as since :

because the users is supposed to be mapped to the pool and not the other way round:

This discrepancy means that even if a delegator's address is added to the supported pools, the delegatee will still not be able to access the boost because it is not mapped correctly.

Impact

The inability for delegatees to utilize their delegated boosts significantly undermines the functionality of the BoostController contract. This flaw can lead to user dissatisfaction and a lack of trust in the delegation feature, as users may expect to benefit from boosts they have delegated.

Tools Used

• Manual code review

Recommendations

Update Supported Pools Logic: Ensure that when a boost is delegated, the corresponding pool is added to the supportedPools mapping. This will allow the delegatee to access and utilize the delegated boost.