Core Contracts

Overview

The contract sets a hard cap on the total supply of veRAAC tokens at MAX_TOTAL_SUPPLY = 100_000_000e18. It enforces this cap within the lock(...) function:

However, no similar check appears in the increase(...) function—allowing users to exceed the total supply cap through incremental increases of their lock.

Attack Path & Proof of Concept (PoC)

1. Initial Lock with a Small Amount

   // 1) The user locks a small amount (e.g. 1 token),

   // passing the total supply check in lock(...).

   lock(1e18, someDuration);

   ​

   • Because 1 is far below MAX_TOTAL_SUPPLY, the contract does not revert.

2. Repeatedly Calling increase(...)

   • The user now calls:

     // 2) The user calls increase(...) with a large amount (or repeatedly with smaller amounts).

     // This function does NOT check totalSupply + newAmount <= MAX_TOTAL_SUPPLY.

     increase(50_000_000e18);

     increase(50_000_000e18);

     // etc.

     ​

   • Each increase call mints additional veRAAC tokens corresponding to the newly locked tokens.

   • The code snippet for increase does not verify (totalSupply() + amount) <= MAX_TOTAL_SUPPLY, thus the total supply can silently grow above the 100 million token cap.

3. Exceeding the Cap
   Eventually, the sum of tokens minted via repeated increase calls can push the veRAAC total supply well beyond 100,000,000 tokens—undermining the system’s intended supply limit.

Impact

• Exceeding the VeRAAC Hard Cap: A malicious or unknowing user can accumulate more veRAAC tokens than the system was designed to allow.

• Governance & Reward Distortion: Votes and rewards based on veRAAC balances may be skewed, granting the over-cap user disproportionate control or extra rewards.

Remediation

Insert the same total supply check found in lock(...) into increase(...), e.g.:

This ensures both creation paths (initial lock and incremental increases) respect the global supply cap.