Core Contracts

Summary

The voting power calculation in the governance system lacks proper checkpointing, allowing users to vote multiple times by transferring tokens between addresses.

Vulnerability Details

The castVote function in the Governance contract uses getVotingPower() without block number parameters:

This allows a malicious user to:

1. Vote with their current voting power

2. Transfer their veRAAC tokens to another address

3. Vote again from the new address

4. Potentially repeat this process multiple times

The lack of historical voting power tracking enables this double-voting attack vector.

Impact

• Double voting possibility through token transfers

• Manipulation of governance decisions

• Undermined voting integrity

• Potential for malicious proposals to pass through vote multiplication

Tools Used

• Manual code review

• Analysis of governance implementation

• Review of voting power calculation mechanisms

Recommendations

1. Implement a getPriorVotingPower(address account, uint256 blockNumber) function that returns historical voting power

2. Modify the castVote function to use voting power from the proposal creation block: