Core Contracts

Summary

The LockManager.sol contract defines a system-wide maximum locked token limit (maxTotalLocked), but this limit is never enforced in either createLock() or increaseLock().

While per-user limits are correctly enforced (MAX_LOCK_AMOUNT for lock() and maxLockAmount for increaseLock()), the absence of a global total cap check allows multiple users to collectively exceed the intended total locked supply, leading to potential governance and economic distortions.

Vulnerability Details

First off, _lockState.totalLocked isn't capped at MAX_TOTAL_LOCKED_AMOUNT in both veRAACToken.lock() and veRAACToken.increase(). Such check is implemented in LockManager.increaseLock() but the associated code lines have been commented out.

LockManager.sol#L163-L164

As an example, multiple users can lock tokens up to their individual limit, leading to a higher total than maxTotalLocked allows, breaking tokenomics and will specifically dilute the boost multiplier for a user's rewards long term due to totalVeSupply, the denominator that continues to grow larger (because of unbounded _lockState.totalLocked) returning a smaller than intended votingPowerRatio in BoostCalculatorcalculateBoost():

BoostCalculator.sol#L86-L90

Note: The above issue will surface should MAX_TOTAL_SUPPLY is being reached proportionately slower than MAX_TOTAL_LOCKED_AMOUNT.

Regardless, users can always sneak through increase() that's devoid of MAX_TOTAL_SUPPLY check and indefinitely make _lockState.totalLocked and totalVeSupply separately grow unbounded.

Impact

The unexpected behavior in tokenomics and governance, e.g. boost, calculations could lead to disproportionate voting power, i.e. users using multiple accounts could extend/consolidate their voting power unbounded whereas normal users are getting dwarfed correspondingly with their voting ability. In extreme cases, precision issue could surface on voters with very small voting power (i.e., veBalance or point.bias) and assigned params.minBoost only.

Tools Used

Manual

Recommendations

Uncomment such crucial check in LockManager.increaseLock(), and implement the same check in LockManager.createLock().