Core Contracts

Summary

In the veRAACToken contract, several functions are designed to manage the locking, unlocking, increasing, and extending of RAAC tokens, as well as their lock durations. The protocol utilizes a dual-gauge system for rewards distribution, where user rewards are determined based on both their boost factors and internally recorded boost balances.

However, there is a critical issue in how these functions update boost balances. Specifically, the functions lock, increase, extend, withdraw, and emergencyWithdraw do not update the users’ boost balances appropriately. Notably, the extend function fails to call _updateBoostState, and while the lock and increase functions do call _updateBoostState, that function itself does not invoke _boostState.updateUserBalance. Moreover, the current implementation passes the locked RAAC token amount (locks[msg.sender].amount) to update the boost state, even though the boost state should instead be updated using the newly calculated voting power (newPower), which accounts for time-weighted decay. This discrepancy can lead to significant reward manipulation, where users may not receive the rewards they are entitled to, thereby destabilizing the incentive structure and eroding trust in the protocol.

Vulnerability Details

1. Boost State Update Shortcomings:

   • The _updateBoostState function is designed to update global boost parameters such as overall voting power, total voting power, and total weight based on locked tokens. It also updates the boost period by calling _boostState.updateBoostPeriod().

   • Missing Call: The function does not invoke _boostState.updateUserBalance(user, newAmount), which is necessary for updating user-specific boost balances.

   • Incorrect Parameter: Additionally, the function is called with locks[msg.sender].amount (the raw locked RAAC token amount) rather than the calculated voting power (newPower) that reflects the current time-weighted state. As a result, the boost state does not correctly represent the actual voting power of the user, leading to inaccurate reward and governance weight calculations.

   function _updateBoostState(address user, uint256 newAmount) internal {

   // Update boost calculator state

   _boostState.votingPower = _votingState.calculatePowerAtTimestamp(user, block.timestamp);

   _boostState.totalVotingPower = totalSupply();

   _boostState.totalWeight = _lockState.totalLocked;

   ​

   _boostState.updateBoostPeriod();

   @> // @info: doesn't call _boostState.updateUserBalance(user, newAmount);

   }

2. Function-Specific Issues:

   • lock Function:
     After creating a lock via _lockState.createLock(msg.sender, amount), the function calls _updateBoostState(msg.sender, amount). Since this call does not forward the new voting power and omits the necessary user balance update in the boost state, the user's boost balance remains outdated.

   function lock(uint256 amount, uint256 duration) external nonReentrant whenNotPaused {

   //...

   //...

   //...

   ​

   // Create lock position

   _lockState.createLock(msg.sender, amount, duration);

   @> _updateBoostState(msg.sender, amount);

   ​

   //...

   //...

   //...

   ​

   emit LockCreated(msg.sender, amount, unlockTime);

   }

   • increase Function:
     When a user increases their locked amount using _lockState.increaseLock(msg.sender, amount), _updateBoostState is invoked with locks[msg.sender].amount rather than the new calculated voting power. This misrepresentation leads to an inaccurately low boost factor, adversely affecting both reward allocations and governance influence.

   function increase(uint256 amount) external nonReentrant whenNotPaused {

   _lockState.increaseLock(msg.sender, amount);

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

   ​

   //...

   //...

   //...

   ​

   emit LockIncreased(msg.sender, amount);

   }

   • extend Function:
     The extend function does not call _updateBoostState at all. Instead, it manually updates voting power by recalculating and then minting or burning tokens accordingly. This omission means that changes in lock duration do not reflect in the global boost state, leaving user-specific boost balances stale.

     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);

     ​

     @> // @info: doesn't call the \_updateBoostState function to update boost factors.

     ​

     // 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);

     }

3. Potential Exploitation:

   • Reward Manipulation:
     Inaccurate boost balances can be exploited by malicious actors to either underclaim or overclaim rewards. By carefully timing lock operations and relying on stale boost state data, attackers could skew the reward distribution mechanism in their favor.

   • Governance Discrepancies:
     Since governance weight is tied to the voting power (which is derived from boost factors), any inaccuracy in boost state updates may result in misrepresentation of voting power. This can lead to governance decisions being influenced by parties whose actual stake is lower than what is recorded.

Proof of Concept

To demonstrate this vulnerability, the following Proof of Concept (PoC) is provided. The PoC is written using the Foundry tool.

1. Step 1: Create a Foundry project and place all the contracts in the src directory.

2. Step 2: Create a test directory and a mocks folder within the src directory (or use an existing mocks folder).

3. Step 3: Create all necessary mock contracts, if required.

4. Step 4: Create a test file (with any name) in the test directory.

5. Step 5: Add the following test PoC in the test file, after the setUp function.

6. Step 6: To run the test, execute the following commands in your terminal:

7. Step 7: Review the output. The expected output should indicate that users internal balance and users specific parameters or members haven't updated.

As demonstrated, the test confirms that the users boost internal balance and other specific parameters or members haven't updated.

Notice: Some modifications have been made to let you show the issue.

veRAACToken::getUserBoostTimePeriods: (newly introduced getter for ease)

Impact

• Distorted Voting Power Calculations:
  The failure to update user-specific boost balances accurately leads to an inaccurate representation of voting power. Since boost factors are a key determinant in voting weight, any miscalculation undermines the integrity of governance outcomes.

• Inconsistent Reward Distribution:
  Rewards based on boost factors will be misallocated because the internal state does not reflect the true, updated voting power. Users may receive lower rewards than they are entitled to, or malicious actors might exploit this discrepancy to skew the reward system.

• Global Parameter Inconsistencies:
  The omission of proper boost state updates creates discrepancies in the overall governance system. Historical and real-time data used for governance decision-making become unreliable, making audits and performance tracking challenging.

• Increased Vulnerability to Exploitation:
  Attackers can exploit stale or inaccurate boost data to manipulate governance proposals and reward distribution. This manipulation can lead to governance takeovers or biased proposals that favor certain participants over others.

• Erosion of User Trust:
  Persistent inaccuracies in voting power and reward distribution will erode user confidence in the protocol, potentially reducing long-term engagement and participation in governance.

Tools Used

• Manual Review

• Foundry

• Console Log (foundry)

• SRC Mutation

Recommendations

• Modify the _updateBoostState function to include a call to _boostState.updateUserBalance(user, newAmount) so that user-specific boost balances are accurately updated whenever a lock is created or increased.

• In the extend function, add a call to _updateBoostState after extending the lock and calculating new voting power. This will ensure that changes to the lock duration correctly reflect in the global boost state and user boost balances.

One possible solution is as follows:

veRAACToken::_updateBoostState:

veRAACToken::extend:

veRAACToken::lock:

veRAACToken::increase: