Core Contracts

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

Missing Validation of Lock Amount in increase Function

Summary

The increase function in the veRAACToken contract lacks validation to ensure the total locked amount after increasing does not exceed MAX_LOCK_AMOUNT (10M RAAC), allowing a user to surpass this limit if their initial lock plus increase exceeds it. This fully valid medium-impact, medium-likelihood vulnerability could enable excessive locking, skewing voting power and boost calculations beyond intended protocol limits, potentially destabilizing governance or reward distribution.

Vulnerability Details

The increase function adds to an existing lock without checking the resulting total against MAX_LOCK_AMOUNT:

Issue:

lock checks amount > MAX_LOCK_AMOUNT (10M RAAC), but increase only calls _lockState.increaseLock, which lacks this check internally (assuming LockManager doesn’t enforce it).
No validation ensures userLock.amount + amount <= MAX_LOCK_AMOUNT.
Scenario:
User locks 9M RAAC via lock, below 10M limit.
Calls increase(2M); total becomes 11M RAAC.
No revert occurs, exceeding MAX_LOCK_AMOUNT, granting ~2.75M veRAAC (11M * 4 years / 1460 days).
Skews $10M governance voting or boosts (e.g., 27.5% unintended influence).
Analysis: The absence of a total limit check in increase (unlike lock) violates the protocol’s design constraint, allowing unbounded growth of individual locks, fully validating the vulnerability.

Impact

The ability to exceed MAX_LOCK_AMOUNT (e.g., 11M vs. 10M RAAC, adding $1M+ undue influence in a $10M pool) is a medium-impact issue, as it disrupts voting power fairness and boost calculations without direct fund loss, but affects governance integrity and reward distribution. The medium likelihood reflects the ease of execution by any user with an existing lock and sufficient RAAC, a plausible scenario in active governance participation.

Tools Used

Manual Code Review: Confirmed _lockState.increaseLock and subsequent logic lack validation of userLock.amount + amount against MAX_LOCK_AMOUNT,

Recommendations

Add validation to enforce MAX_LOCK_AMOUNT in increase:

function increase(uint256 amount) external nonReentrant whenNotPaused {
LockManager.Lock memory userLock = _lockState.locks[msg.sender];
if (userLock.amount == 0) revert LockNotFound();
if (amount == 0) revert InvalidAmount();
uint256 newTotalAmount = userLock.amount + amount;
if (newTotalAmount > MAX_LOCK_AMOUNT) revert AmountExceedsLimit();
_lockState.increaseLock(msg.sender, amount);
_updateBoostState(msg.sender, newTotalAmount);
(int128 newBias, int128 newSlope) = _votingState.calculateAndUpdatePower(
msg.sender,
newTotalAmount,
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));
emit LockIncreased(msg.sender, amount);
}
Updates

Lead Judging Commences

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

veRAACToken::increase doesn't check the maximum total locked amount

Support

FAQs

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