Core Contracts

Summary

There is an inconsistency between the internal and external boost calculation functions in the BoostController contract regarding how a user’s voting power is determined. One function uses the ERC20 balance of the veToken, while the other uses the veToken’s getVotingPower method.

Vulnerability Details

In the contract, two boost calculation functions exist:

1. The internal function _calculateBoost computes boost by retrieving the user's balance using:

   uint256 userBalance = IERC20(address(veToken)).balanceOf(user);

   uint256 totalSupply = IERC20(address(veToken)).totalSupply();

   This approach uses the raw ERC20 balance of the veToken.

2. In contrast, the external function calculateBoost obtains the user's voting power using:

   uint256 userVotingPower = veToken.getVotingPower(user, block.timestamp);

   This function relies on the veToken’s specific logic to calculate voting power, which may include time-weighted decay or other adjustments.

The discrepancy between these two methods means that boost calculations could yield different results depending on which function is used. The internal method may not account for the nuanced voting power mechanics implemented in the veToken contract.

Impact

Inaccurate Boost Calculation: Inconsistent methods for retrieving voting power can lead to discrepancies in boost multipliers. This may result in unfair reward distributions, with some users receiving an incorrect boost relative to their actual voting power.

Tools Used

• Manual code review

Recommended Mitigation

• Standardize Voting Power Retrieval: Choose a single, consistent method for obtaining voting power. Ideally, all boost calculations should use the veToken’s getVotingPower method to capture the correct, time-weighted voting power.

• Refactor Functions: Refactor the internal _calculateBoost function to use veToken.getVotingPower(user, block.timestamp) instead of IERC20(address(veToken)).balanceOf(user).