Core Contracts
Regnum Aurum Acquisition Corp
HardhatReal World AssetsNFT
77,280 USDC
View results
Previous Next
Submission Details
Severity: medium
Valid

Missing MAX_TOTAL_SUPPLY Check in increase::veeRAACToken.sol

oluwaseyisekoni

Summary

increase which allows a user to add tokens to an existing lock and mint additional veTokens, does not include a check to ensure that totalSupply() plus the minted amount (newPower - balanceOf(msg.sender)) does not exceed MAX_TOTAL_SUPPLY. In contrast, the lock function includes if (totalSupply() + amount > MAX_TOTAL_SUPPLY) revert TotalSupplyLimitExceeded(), albeit with its own unit inconsistency (addressed separately). While increase checks the per-user limit (MAX_LOCK_AMOUNT) via _lockState.increaseLock, the absence of a global cap check allows totalSupply() to surpass MAX_TOTAL_SUPPLY, violating a key protocol constraint and creating inconsistency with lock.

Vulnerability Details

increase::veRAACToken.sol

function increase(uint256 amount) external nonReentrant whenNotPaused {
_lockState.increaseLock(msg.sender, amount); // Checks MAX_LOCK_AMOUNT internally
_updateBoostState(msg.sender, locks[msg.sender].amount);
LockManager.Lock memory userLock = _lockState.locks[msg.sender];
(int128 newBias, int128 newSlope) = _votingState.calculateAndUpdatePower(
msg.sender,
userLock.amount + amount,
userLock.end
);
uint256 newPower = uint256(uint128(newBias));
_checkpointState.writeCheckpoint(msg.sender, newPower);
raacToken.safeTransferFrom(msg.sender, address(this), amount);
_mint(msg.sender, newPower - balanceOf(msg.sender)); // No MAX_TOTAL_SUPPLY check
emit LockIncreased(msg.sender, amount);
}

increase lacks a counterpart to lock’s totalSupply() + amount > MAX_TOTAL_SUPPLY check, allowing _mint(newPower - balanceOf(msg.sender)) to increase totalSupply() without cap validation.

Impact

  • The absence of a totalSupply() cap check in increase results in unbounded veToken Issuance:

_mint(newPower - balanceOf(msg.sender)) can push totalSupply() beyond MAX_TOTAL_SUPPLY if newPower significantly exceeds the user’s current balance, with no revert which violates the intended veToken supply cap, leading to over-issuance.

  • Inconsistency with lock:

    • Impact: lock attempts to enforce MAX_TOTAL_SUPPLY (despite unit issues), while increase bypasses it, allowing users to exceed the cap incrementally via repeated increases, creating an uneven application of protocol rules.

Tools Used

Manual review

Recommendations

Add MAX_TOTAL_SUPPLY Check with Correct Units:

  • Validate totalSupply() + (newPower - balanceOf(msg.sender)) before minting, aligning with veToken issuance:

function increase(uint256 amount) external nonReentrant whenNotPaused {
_lockState.increaseLock(msg.sender, amount);
_updateBoostState(msg.sender, locks[msg.sender].amount);
LockManager.Lock memory userLock = _lockState.locks[msg.sender];
(int128 newBias, int128 newSlope) = _votingState.calculateAndUpdatePower(
msg.sender,
userLock.amount + amount,
userLock.end
);
uint256 newPower = uint256(uint128(newBias));
uint256 mintAmount = newPower - balanceOf(msg.sender);
+ if (totalSupply() + mintAmount > MAX_TOTAL_SUPPLY) revert TotalSupplyLimitExceeded();
_checkpointState.writeCheckpoint(msg.sender, newPower);
raacToken.safeTransferFrom(msg.sender, address(this), amount);
_mint(msg.sender, mintAmount);
emit LockIncreased(msg.sender, amount);
}
Updates

Lead Judging Commences

inallhonesty Lead Judge 7 months ago
Submission Judgement Published
Validated
Assigned finding tags:

veRAACToken::increase doesn't check the token supply, making it possible to mint over the MAX

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!