Core Contracts

Summary

In the delegateBoost function, the only check performed is on the to address being non-zero. There is no explicit check to ensure that the delegation target is a supported pool, even though boost data is maintained per pool in poolBoosts.

Vulnerability Details

The root cause is the missing validation step in delegateBoost to confirm that the to address is a supported pool (e.g., by checking supportedPools[to]). Without this check, delegations may be misapplied to any address.

For example, if a user delegates a boost of 10,000 tokens to an address that is not a genuine pool, that delegation will be recorded in userBoosts and affect poolBoosts calculations for that address. Later, if someone queries boost data for that “pool,” the data will be invalid, leading to misallocation of rewards or manipulation of boost metrics across the system.

Impact

Allowing boost delegations to arbitrary addresses could lead to delegations being recorded for unsupported or invalid pools. This can corrupt the boost accounting, leading to inaccurate pool boost metrics and potential exploitation by delegating to malicious or unintended targets.

Recommendations

Add a check at the beginning of delegateBoost to ensure that the to address is a supported pool:

This prevents delegations to arbitrary addresses.