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

`veRAACToken` Incorrect Use of locks Mapping Causes Inaccurate Lock Data Retrieval

federodes

Summary

The veRAACToken contract contains two separate storage variables, locks and _lockState.locks, intended to track user lock positions. However, the locks mapping is never updated, yet it is still referenced in multiple functions, leading to incorrect data retrieval.

Vulnerability Details

The contract defines two mappings for tracking user lock positions:

mapping(address => Lock) public locks;
LockManager.LockState private _lockState;

While _lockState.locks is correctly used and updated within the LockManager, the locks mapping is never assigned values. Despite this, the contract references locks[msg.sender] in multiple places:

  1. increase Function

    _updateBoostState(msg.sender, locks[msg.sender].amount);

    Here, locks[msg.sender].amount is always zero, as locks is never updated.

  2. getLockedBalance Function

    return locks[account].amount;

    This function returns incorrect values since locks[account].amount is never set.

  3. getLockEndTime Function

    return locks[account].end;

    Similar to getLockedBalance, this function always returns 0, providing inaccurate data.

PoC

Add the following test to test/unit/core/tokens/veRAACToken.test.js.

The test shows that after the user locks 1000 ETH, both the balance and endTime return 0.

it.only("should retrieve the return the locked balance and end time", async () => {
const amount = ethers.parseEther("1000");
const duration = 365 * 24 * 3600; // 1 year
​
// Create lock first
const tx = await veRAACToken.connect(users[0]).lock(amount, duration);
​
// Wait for the transaction
await tx.wait();
​
// Verify lock position returns 0 for both balance and endTime
const lockedBalance = await veRAACToken.getLockedBalance(users[0].address);
const lockedEndTime = await veRAACToken.getLockEndTime(users[0].address);
expect(lockedBalance).to.equal(0n);
expect(lockedEndTime).to.equal(0n);
});

Impact

The incorrect usage of the locks mapping results in:

  • getLockedBalance and getLockEndTime always returning 0, misleading users regarding their locked funds.

  • The increase function incorrectly referencing locks[msg.sender].amount, potentially affecting voting power calculations and other dependent logic.

Tools Used

Manual review

Recommendations

Remove the unused locks mapping and ensure all references use _lockState.locks.

Updates

Lead Judging Commences

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

veRAACToken::increase uses locks[msg.sender] instead of _lockState.locks[msg.sender] inside _updateBoostState call

Support

FAQs

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