Core Contracts

Summary

Unexpected behavious due to Incorrect check comparing
two differrent tokens that dont maintain a 1 : 1 ratio.

Vulnerability Details

contract : veRAACToken

The contract has set the
MAX_TOTAL_SUPPLY = 100,000,000 (veRAACToken)

Thus it is safe to assume that
the protocol does not intend the veRAACToken supply to exceed 100 million.

Firstly, Lets observe this check inside lock function

Here, the sum is performed on totalSupply() (representing veRAAC) and

amount ( RAAC tokens locked)

and compared to the MAX_TOTAL_SUPPLY (which is described as the maximum supply of veRAAC).

Its important to note that veRAACTokens are NOT 1:1 representations of RAAC Tokens.

veRAACToken minted depends on the amount and duration locked, and decays over time.

Which means in certain cases the condition would revert even if MAX_TOTAL_SUPPLY is not reached.

For simplicity, Consider the following example scenario
Assume
MAX_LOCK_DURATION = 1000 days
MAX_LOCK_DURATION = 250 days

Assume MAX_TOTAL_SUPPLY = 1000
and current totalSupply() = 950

Alice attempts to lock 60 RAAC for 250 Days

In this case votingPower would be (60*250) / 1000 = 15 veRAACToken

Thus new totalSupply() = 965 (still below MAX_TOTAL_SUPPLY)
So Alice should be allowed
to lock her 60 RAAC tokens and
mint 15 veRAACTokens

However , Alice's call reverts due to the incorrect check (950 + 60 > 1000)

Impact

Erroneous check results in unexpected behaviour.
For instance, the condition would revert even if actual totalSupply() of veRAACToken
does not reach MAX_TOTAL_SUPPLY cap.

Recommendations

The correct way to enforce the check is to revert
only if totalSupply of veRAACToken exceeds the MAX_TOTAL_SUPPLY .

This check could be done after the calculation of votingPower and
before the call to _mintveRAACTokens to the user as shown

if (totalSupply() + newPower > MAX_TOTAL_SUPPLY) revert TotalSupplyLimitExceeded();