Core Contracts

Summary

The veRAACToken contract exhibits two critical issues related to voting power representation. First, the ERC20 token balances (veRAAC) are minted as static values that do not decay over time, despite the underlying voting power decaying as locks approach expiry. Second, the checkpoint mechanism records these static balances rather than the decayed voting power, resulting in inaccurate historical snapshots. Together, these flaws can lead to governance decisions based on inflated and outdated voting metrics.

Vulnerability Details

1. Static Voting Power Representation:
   When a user locks RAAC tokens, the contract calculates their initial voting power based on the lock duration and mints an equivalent static veRAAC token balance. However, while the actual voting power should decay linearly over time, the token balance remains unchanged. This discrepancy means that users retain an influence level on-chain that does not reflect the diminishing weight of their lock as time passes.

2. Checkpoint Decay Mismatch:
   The checkpoint mechanism is designed to capture historical voting power snapshots. However, the checkpoints are written using the static veRAAC token balances rather than the time-decayed voting power. As a result, historical data retrieved from these checkpoints does not accurately represent the true voting power at that moment, leading to potential errors in governance proposals and reward calculations.

POC

1. Static Voting Power Representation:

   • Initial Lock:
     A user locks 100 tokens for 1 year (assume MAX_LOCK_DURATION is 4 years). The contract calculates the voting power as:
     initialVotingPower = (100 * 365 days) / (1460 days) ≈ 25 tokens
     The user is minted 25 veRAAC tokens.

   • After 6 Months:
     Ideally, the voting power should decay roughly to 12.5 tokens due to the reduced remaining lock duration. However, the user's veRAAC balance remains 25 tokens, leading to an inflated representation of their voting power.

2. Checkpoint Decay Mismatch:

   • Checkpoint Creation:
     When a snapshot is taken (e.g., for a governance proposal), the contract writes the user's current veRAAC balance (25 tokens) into the checkpoint.

   • Historical Query:
     Later, when the system queries the voting power for historical decision-making, it retrieves the static 25 tokens from the checkpoint, even though the true decayed voting power should be approximately 12.5 tokens. This mismatch leads to erroneous historical records.

Impact

Governance proposals and reward distributions based on these inflated voting power values may not truly reflect the current influence of each participant, skewing outcomes.

Malicious users might exploit the static nature of the token balance to exert undue influence on governance decisions long after their effective voting power has decayed.

Tools Used

Manual Review

Recommendations

Refactor the voting power calculation and checkpoint logic so that both current and historical voting power values dynamically reflect the linear decay over time rather than relying on static veRAAC token balances.