Summary

The delegateBoost function lets users send boost power to themselves, which doesn’t do anything useful. There’s no rule stopping msg.sender from being the same as to, so users can waste gas on a pointless action that doesn’t increase their boost.

Vulnerability Details

This issue happens because the delegateBoost function doesn’t check if the person giving the boost (msg.sender) is the same as the person getting it (to). Let’s look at the code.

Here’s the delegateBoost function:

• No Self-Check: It checks if to isn’t zero (if (to == address(0))) and if there’s already a delegation (if (delegation.amount > 0)), but it doesn’t say, “Hey, you can’t delegate to yourself!” So, if msg.sender equals to, it still works.

• What Happens: It saves the delegation in userBoosts[msg.sender][msg.sender]—like User A delegating to User A. It sets the amount, expiry, and delegatedTo to their own address.

Now, look at how boosts are calculated:

solidity

• Boost Ignores It: This only uses userBalance—the user’s own veTokens. It doesn’t check userBoosts[user][user] for self-delegations, so the delegated amount doesn’t help.

Why It’s Pointless

• Normally, delegation means giving your boost to someone else to help them—like sharing power. Delegating to yourself should either be blocked or add to your boost, but here it just sits in userBoosts doing nothing.

• Later, in removeBoostDelegation:

  solidity

  PoolBoost storage poolBoost = poolBoosts[msg.sender];

  poolBoost.totalBoost -= delegation.amount;

  • It tries to subtract from poolBoosts[msg.sender] (already a bug, as msg.sender isn’t a pool), but since the boost wasn’t added anywhere useful, this subtraction is meaningless too.

Impact

1. Someone might self-delegate expecting a benefit (since it’s allowed), then get frustrated when nothing happens.

Tools Used

manual review

Recommendations
Stop users from delegating to themselves