A vulnerability has been identified in the BoostController::_calculateBoost
function, which incorrectly calculates the user's boost based on the user's veRaac token balance instead of the user's current voting power. This discrepancy leads to inaccurate boost calculations, potentially allowing users to gain unintended advantages in the boost mechanism. Additionally, the BoostController::delegateBoost
function also relies on balanceOf
, enabling users to delegate more veTokens than they currently possess, further exacerbating the issue.
The BoostController
contract includes several functions for managing user boosts, primarily updateUserBoost
and delegateBoost
. These functions depend on boost calculations to determine the boost amount for users. However, the boost calculation relies on the stale veRaac balance instead of the current voting power, leading to inaccurate results.
BoostController::updateUserBoost
Uses _calculateBoost
, which relies on IERC20.balanceOf(user)
instead of veToken.getVotingPower(user, block.timestamp)
.
This results in outdated balance references, leading to incorrect boost calculations.
BoostController::_calculateBoost
(internal function)
Fetches the user's balance using IERC20.balanceOf(user)
.
This does not account for veRaac’s decay mechanism, which dynamically changes voting power over time.
BoostController::delegateBoost
Uses IERC20.balanceOf(user)
, allowing users to delegate more veTokens than they effectively have in terms of voting power.
This discrepancy can be exploited to delegate an inflated boost amount.
BoostController::_calculateBoost
(Flawed Calculation)
BoostController::calculateBoost
(Correct Calculation)
BoostController::delegateBoost
Scenario Setup: A user has 1000 veRaac tokens but a decayed voting power of only 500 due to locking and time decay.
Incorrect Boost Calculation: _calculateBoost
uses balanceOf(user) = 1000
instead of getVotingPower(user) = 500
, giving the user an unfair boost.
Correct Calculation: calculateBoost
correctly considers votingPower
and provides a lower, fair boost.
Exploit Impact: A user could manipulate the system by holding a high balance without actually having the corresponding voting power, leading to an unfair advantage in boosted rewards.
To demonstrate this vulnerability, the following Proof of Concept (PoC) is provided. The PoC is written using the Foundry tool.
Step 1: Create a Foundry project and place all the contracts in the src
directory.
Step 2: Create a test
directory and a mocks
folder within the src
directory (or use an existing mocks folder).
Step 3: Create all necessary mock contracts, if required.
Step 4: Create a test file (with any name) in the test
directory.
Step 5: Add the following test PoC in the test file, after the setUp
function.
Step 6: To run the test, execute the following commands in your terminal:
Step 7: Review the output.
As demonstrated, the test confirms that the user's boost is incorrectly updated.
Protocol Imbalance: Users with high veRaac balances but low voting power receive disproportionately high boosts.
Unfair Advantage: Users can exploit the boost system by artificially maintaining a high balance.
Governance Integrity Risk: Boosting mechanisms tied to governance participation may be compromised.
Boost Manipulation: Users may receive incorrect boost amounts due to outdated balance references.
Delegation Exploit: Users can delegate more veTokens than they effectively possess.
Governance Manipulation: Boosting mechanics that rely on veRaac voting power can be distorted.
Manual Review
Foundry
To mitigate this vulnerability, the following changes should be implemented:
Modify _calculateBoost
to Use Voting Power:
Replace IERC20(veToken).balanceOf(user)
with veToken.getVotingPower(user, block.timestamp)
or,
Refactor updateUserBoost
to Use calculateBoost
:
Instead of _calculateBoost
, call calculateBoost
directly in updateUserBoost
.
Ensure delegateBoost
verifies the user’s actual voting power before allowing delegation.
Audit Other Related Functions:
Ensure that all boost calculations consistently use voting power rather than token balance.
Example Fix:
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.