Summary

The protocol's veRAAC token implementation does not restrict transfers, allowing malicious users to vote multiple times on governance proposals. By repeatedly transferring veRAAC tokens between addresses, an attacker can amplify their voting power, leading to governance manipulation.

Vulnerability details

• veTokens (vote-escrowed tokens) are meant to be non-transferable to ensure fair and long-term governance participation. However, the protocol's veRAAC token lacks transfer restrictions in transfer() and transferFrom(), allowing users to move veRAAC between wallets. This enables a vote amplification exploit, where a user can:

  1. Vote on a governance proposal.

  2. Transfer veRAAC to another wallet.

  3. Vote again from the new wallet.

  4. Repeat the process indefinitely, skewing governance results.

This completely breaks governance security, as decisions are no longer made by long-term aligned token holders, but by those who can move tokens quickly.

Impact

Severity: Critical

• Governance can be hijacked, leading to malicious protocol changes, such as:

  • Whitelisting a malicious contract.

  • Changing reward distribution unfairly.

  • Draining treasury funds.

• The integrity of all governance votes is compromised, making the system unreliable.

Tools used

• Manual code review

Recommendations

1. Make veRAAC non-transferable by overriding transfer() and transferFrom() to always revert:

   solidity

   ​

   function transfer(address, uint256) public override(ERC20, IveRAACToken) returns (bool) {

   revert("veRAAC tokens are non-transferable");

   }

   ​

   ​

   function transferFrom(address, address, uint256) public override(ERC20, IveRAACToken) returns (bool) {

   revert("veRAAC tokens are non-transferable");

   }