Core Contracts

Summary

The delegateBoost function lets users give their boost power to someone else, but the contract doesn’t actually let the recipient use it. The delegated boost gets saved, but it’s ignored when calculating or applying boosts, making the delegation feature useless.

Vulnerability Details

The delegateBoost function lets one user (the delegator) give boost power to another user (the recipient).

• It checks if the delegator (msg.sender) has enough veTokens and saves the delegation in userBoosts[msg.sender][to] with:

  • amount: How much boost is given.

  • expiry: When it ends.

  • delegatedTo: Who gets it (to).

• But that’s it, it doesn’t tell the rest of the contract to use this boost for the recipient.

The _calculateBoost function decides how much boost a user gets:

• It only looks at userBalance—the veTokens the user owns themselves. It doesn’t check userBoosts[someone][user] to see if anyone delegated boost to this user.

• Same thing in calculateBoost, which uses veToken.getVotingPower(user, block.timestamp)—still just the user’s own power.

• The updateUserBoost function puts the boost into a pool:

  function updateUserBoost(address user, address pool) external override nonReentrant whenNotPaused {

  // ... (checks)

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

  PoolBoost storage poolBoost = poolBoosts[pool];

  uint256 oldBoost = userBoost.amount;

  uint256 newBoost = _calculateBoost(user, pool, 10000);

  userBoost.amount = newBoost;

  userBoost.lastUpdateTime = block.timestamp;

  if (newBoost >= oldBoost) {

  poolBoost.totalBoost = poolBoost.totalBoost + (newBoost - oldBoost);

  } else {

  poolBoost.totalBoost = poolBoost.totalBoost - (oldBoost - newBoost);

  }

  poolBoost.workingSupply = newBoost;

  // ... (events)

  }

  • newBoost comes from _calculateBoost, which ignores delegations.

  • It updates userBoosts[user][pool], but doesn’t look at userBoosts[delegator][user] to add any delegated boost.

The delegated boost gets stuck in userBoosts[msg.sender][to] and never reaches the recipient’s actual boost power. The contract has a `removeBoostDelegation function that subtracts the delegated amount from the recipient’s pool when it expires

This shows the delegated boost was meant to help the recipient’s pool—but since it’s never added anywhere, this subtraction either does nothing (if totals are too low) or messes up the pool unfairly.

Impact

1. Users can delegate boost, but it doesn’t help the recipient get more rewards or power in pools. The whole point of delegation fails.

2. People might delegate expecting it to work (since the contract lets them), then get upset when it does nothing.

3. When delegations expire, removeBoostDelegation tries to subtract the boost from the recipient’s pool totals. Since it was never added, this could unfairly lower totals or just be ignored, depending on the numbers.

Tools Used

Manual Review

Recommendations

When delegateBoost runs, add the amount to the recipient’s userBoosts[to][pool] for a specific pool (needs a pool parameter)