Core Contracts

Summary

The claimRewards function is susceptible to front-running by MEV (Miner Extractable Value) bots due to the absence of a minimum claim amount and slippage protection, allowing manipulation of reward calculations via veRAACToken voting power changes. This fully valid medium-impact, high-likelihood vulnerability enables attackers to reduce legitimate users’ rewards by altering distribution shares within a transaction window, exploiting the public nature of Ethereum transactions.

Vulnerability Details

The claimRewards function calculates rewards based on current veRAACToken voting power without safeguards:

_calculatePendingRewards uses veRAACToken.getVotingPower(user) and totalVotingPower(), both snapshot-able at the current block.
No minimum claim or slippage check exists.
Attack Scenario:
User has 10,000 RAAC pending rewards; submits claimRewards.
MEV bot detects the transaction in the mempool:
Front-runs by increasing its veRAACToken voting power (e.g., locking more RAAC).
totalVotingPower rises, reducing the user’s share (e.g., from 10,000 to 9,000 RAAC).
Back-runs to revert its power, claiming inflated rewards later.
User receives less (e.g., 9,000 RAAC), losing $1,000 at $1/RAAC.
Repeated across users, extracting significant value.
The lack of constraints allows real-time manipulation within a block, a common MEV tactic.

Impact

The reduction of user rewards (e.g., $1,000 per claim, potentially $100,000+ across users) is a medium-impact issue, eroding trust and fairness without direct protocol loss. The high likelihood stems from Ethereum’s public mempool and MEV bot prevalence, making front-running a frequent risk for unprotected reward claims, especially in high-value scenarios.

Tools Used

Static Analysis Tools: Slither flagged the unprotected claimRewards call and reliance on mutable veRAACToken state, indicating MEV risks.

Recommendations

Implement minimum claim amounts, slippage protection, and a commit-reveal scheme for large claims: