Core Contracts

Vulnerability Details

The lock function incorrectly uses the raw locked RAAC amount (not the time-weighted voting power) when checking against MAX_TOTAL_SUPPLY. This leads to an overly restrictive cap on veRAAC tokens, as short-duration locks consume more supply allowance than their actual voting power warrants.

Protocol Parameters:

MAX_TOTAL_SUPPLY = 100M veRAAC

MAX_LOCK_DURATION = 4 years

Current State:

totalSupply() = 98M veRAAC (existing voting power from prior locks)

User Action
User Tries to Lock:

RAAC Amount: 4M

Lock Duration: 1 year

Calculated Voting Power (veRAAC)

calculated voting power

(4M RAAC * 1 year) / 4 years = 1M veRAAC

Expected Behavior

by the comment its clear that the max supply is enforced on veerac supply meaning the final mint amount of veeracs

not on the locked amount

https://github.com/Cyfrin/2025-02-raac/blob/89ccb062e2b175374d40d824263a4c0b601bcb7f/contracts/core/tokens/veRAACToken.sol#L62-L64

• New Total Voting Power: 98M + 1M = 99M veRAAC

• Result: Transaction succeeds (99M < 100M cap)

Actual Behavior

if (98M veRAAC + 4M RAAC > 100M veRAAC) → 102M > 100M → revert!

Impact

Unfair Rejection: Legitimate users are blocked from participating even when capacity exists.

Protocol Stagnation: Locks for short durations disproportionately consume the supply cap.

note: the same issue exists in increase function

Recommendations

the validation should be on the calculated veerac tokens not the raw amount locked