Core Contracts

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

A proposer can manipulate his proposal using extend function leading to always having high voting power and always having a proposal success

[H-1] A proposer can manipulate his proposal using extend function leading to always having high voting power and always having a proposal success

vulnerability details

Description: When locking RAAC token for voting it requires duration < MIN_LOCK_DURATION || duration > MAX_LOCK_DURATION, which is okay, The issue now is that a malicious user can decrease these duration using the extend function

how is this possible?
the extend function in veRAAC token allow a user to either increase or decrease his duration

A function was called in the extend function by name extendLock
but this function only check if thetotalNewDuration > state.maxLockDuration

if (totalNewDuration > state.maxLockDuration) revert InvalidLockDuration();

So with this Someone can manipulate this by decreasing his locking period to 1 day or less

Impact: A proposer or a user can manipulate his or a proposal to success, also with this a proposal addresses that he will be transfering the raactoken to will always be bypassing the slope mechanism , this will lead to the addresses always having high voting power

Proof of Concept:

* When a proposal is created
* lets say for example the manipulators are two working together with 100k RAAC token each or one person with 200k RAAC token
* manipulator 1 (First address) first lock 100,000 RAAC token for 4 years bypassing the MIN_LOCK_DURATION in lock function
* manipulator 1 will be minted veRAACToken
* with this he can now create a proposal
* unlockTime is set to 4 years
* manipulator 1 create a proposal
* Now Manipulator 2 (second address) lock 100k RAAC token for same 4 years
* will also be minted veRAACToken
* unlockTime will also be set to 4 years
* Now Manipulator 2 (second address) votes for the proposal
* Now Manipulator 2 (second address) can use extend to decrease the duration period so that he can be able to withdraw
* Manipulator 2 (second address) can withdraw after using extend to decrease his duration
* then after withdrawing his veRAAC will get burn and his RAAC token will be transfered to his address
* now he can transfer the RAAC token to another address and vote with it, this process can be repeated many times to gain must of the vote in his proposal favor
* since voting lasts for weeks a user can keep repeating this process until the voting periods ends
* at the end the proposal will definately be success
* remember this method can also be used to vote against

code snippet extendLock function

function extendLock(
LockState storage state,
address user,
uint256 extensionDuration
) internal returns (uint256 newEnd) {
Lock storage lock = state.locks[user];
if (!lock.exists) revert LockNotFound();
if (lock.end <= block.timestamp) revert LockExpired();
// Calculate remaining duration from current lock
uint256 remainingDuration = lock.end - block.timestamp;
// Calculate total new duration (remaining + extension)
uint256 totalNewDuration = remainingDuration + extensionDuration;
// Check if total duration exceeds max lock duration
if (totalNewDuration > state.maxLockDuration) revert InvalidLockDuration();
// Calculate new end time
newEnd = block.timestamp + totalNewDuration;
// Update lock end time
lock.end = newEnd;
emit LockExtended(user, newEnd);
return newEnd;
}

code snippet extend function

/**
* @notice Extends the duration of an existing lock * @dev Increases the lock duration which results in updated voting power * @param newDuration The new total duration for the lock, in seconds */
function extend(uint256 newDuration) external nonReentrant whenNotPaused {
// Extend lock using LockManager
uint256 newUnlockTime = _lockState.extendLock(msg.sender, newDuration);
// Update voting power
LockManager.Lock memory userLock = _lockState.locks[msg.sender];
(int128 newBias, int128 newSlope) = _votingState.calculateAndUpdatePower(
msg.sender,
userLock.amount,
newUnlockTime
);
// Update checkpoints
uint256 oldPower = balanceOf(msg.sender);
uint256 newPower = uint256(uint128(newBias));
_checkpointState.writeCheckpoint(msg.sender, newPower);
// @audit A user can create lock for 4 years and vote then after voting // he can use extend lock to decrease it to be able to withdraw // Update veToken balance if (newPower > oldPower) {
_mint(msg.sender, newPower - oldPower);
} else if (newPower < oldPower) {
_burn(msg.sender, oldPower - newPower);
}
emit LockExtended(msg.sender, newUnlockTime);
}

Recommended Mitigation:
is important to only allow users to only increase there duration and not reduce it , even tho the protocol want to allow users to decrease there duration is important not to allow them decrease pass min duration for this type of attack not to happen

Updates

Lead Judging Commences

inallhonesty Lead Judge 3 months ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement
inallhonesty Lead Judge 3 months ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

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