Core Contracts

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

loss of veerac for users when calling increase

Summary

The protocol mints incorrect amounts of veRAAC tokens when users increase their locked RAAC without extending the lock duration. The calculation uses checkpointed balances (balanceOf) instead of real-time decayed voting power

When increasing lock amounts, the protocol calculates new voting power as:

uint256 duration = unlockTime - block.timestamp;
uint256 initialPower = (amount * duration) / MAX_LOCK_DURATION; // Normalize by max duration

Proof of Concept

Initial Lock: 100 RAAC for 4 years (1460 days) → 100 veRAAC

After 2 Years: Voting power decays to 50 veRAAC (no checkpoints written)

Action: Increase lock by 100 RAAC (total lock 200 )

newPower = 200 RAAC * (730 days remaining / 1460 days) = 100 veRAAC
mintAmount = 100

the calculated power for 200 (100 lock increase) will be 100

now when this amount is passed to the increase function it computes the amount to mint as

raacToken.safeTransferFrom(msg.sender, address(this), amount);
_mint(msg.sender, newPower - balanceOf(msg.sender));

balanceOf reflects the checkpointed voting power (last recorded value), not the real-time decayed power.

using balanceof to calculate the new power which is outdated balance and does not consider the adjustedbias will lead to users not recieving the intended amount

mintAmount = 100 (newPower) - 100 (balanceOf) = 0


the bugs stems from the fact the balanceof will hold the balance of the users veerac as the initial minted amount when he first locked his raac and after a 2 year decay in his veerac is not uo to dated in the balanceof function due to lack of ineraction

root cause

The increase function mints based on balanceOf (ERC20 balance) which doesn't account for linear decay over time. This leads to incorrect minting when users add to their lock without extending the duration

note a similar issue exists in the extend function

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

Example Scenario:

Initial lock: 100 RAAC for 4 years → 100 veRAAC minted.

After 2 years, voting power decays to 50 veRAAC (but balanceOf remains 100).

Increasing lock by 100 RAAC calculates newPower as 100, but minting uses 100 - 100 = 0 due to stale balanceOf.

Result: User’s veRAAC balance stays at 100 instead of increasing to 100 (50 decayed + 50 new)

Recommendations

use the up to date decayed power to calculate the new mint amount

Updates

Lead Judging Commences

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

veRAACToken::increase calculates new bias using original locked amount not accounting for decay, allowing unfair voting power boost through incremental locking

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

veRAACToken::increase calculates new bias using original locked amount not accounting for decay, allowing unfair voting power boost through incremental locking

Support

FAQs

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