Core Contracts

Summary

In the delegateBoost function of the BoostController contract, where a user can delegate a boost to another address without updating their balance or the userBoosts mapping properly. This leads to a duplication of funds issue, allowing both the delegator and the recipient to utilize the same boost amount multiple times without restriction.

Vulnerability Details

The delegateBoost function allows a user to delegate a boost to another address, storing the delegation details in the userBoosts mapping. However, the function does not update the delegator's balance or enforce any restrictions on repeated delegations. This results in a scenario where a user can delegate multiple times TO OTHER DIFFERENT ADDRESSES WITHOUT BOUNDARIES, effectively duplicating the amount of boost available in the system.

File location: 2025-02-raac\contracts\core\governance\boost\BoostController.sol

Relevant Code:

The following lines check if the delegated address has already been delegated and does not prevent from delegating more than one address. Also it does not check if the user has already delegated his entire userBalance.

The function allows multiple delegations without properly updating the delegator's balance or preventing re-delegation. This results in an unlimited boost duplication exploit.

Example of Exploit:

Since the contract does not check if Alice has enough veRAAC to back all delegations, Alice could theoretically:

• Delegate 10,000 veRAAC to Bob

• Delegate 10,000 veRAAC to Charlie

• Delegate 10,000 veRAAC to Dave

• And so on…

Each recipient would receive a boost as if the veRAAC were fully available, even though Alice only has 10,000 veRAAC total. This effectively creates "fake" boost power out of thin air.

Impact

• Boost Duplication: A user can delegate more boost than they actually possess, leading to an inflation of the boost supply.

• Exploitation for Unfair Advantage: Malicious actors can repeatedly delegate their boost, leading to unfair allocation of rewards and disrupting the system's intended functionality.

• Pools may end up with more boost than actually exists, affecting calculations in critical parts of the protocol.

Tools Used

Manual review

Recommendations

• Deduct Delegated Boost from the User’s Balance: The contract should ensure that whenever a boost is delegated, the user’s effective balance is reduced accordingly(not tranfered but can be locked).

• Track and Prevent Multiple Delegations: The contract should modify the logic to prevent a user from delegating multiple times without proper balance updates.

• Add a mapping to track how much veRAAC a user has delegated in total.

Severity

The vulnerability is of high severity as it enables users to delegate more boost than they actually possess, resulting in the inflation of the boost supply. This exploit can be leveraged by malicious actors to gain unfair advantages, distort reward distributions, and create significant imbalances within the protocol. The lack of proper checks on multiple delegations undermines the system's intended functionality. Consequently, this flaw poses a critical risk to the integrity and stability of the entire system.