The BoostController
contract contains an inconsistency in how it calculates boost values. The external calculateBoost
function incorrectly uses a user's time-weighted voting power instead of their veToken
balance, while the internal implementation correctly uses the balance. This mismatch can lead to incorrect boost calculations, potentially resulting in manipulated reward distributions.
In the calculateBoost function, the contract retrieves a user's voting power using veToken.getVotingPower():
However, the calculateTimeWeightedBoost
function expects a user's veToken balance as its second parameter, not their voting power:
Meanwhile, the internal _calculateBoost function correctly uses the user's veToken balance:
In veToken systems, voting power and token balance are different metrics:
The balance represents the raw veToken amount
Voting power is time-weighted and decays linearly as the lock approaches expiry
Users may receive higher or lower boosts than intended, leading to unfair reward distributions. This opens up an an attack vector where sers could time their interactions to exploit differences between these calculations.
Manual Review
Modify calculateBoost to use veToken balance (recommended):
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.