Core Contracts

Summary

The veRAACToken contract provides various functionalities, including locking, unlocking, increasing, withdrawing, and extending both the locked amount and duration of RAAC tokens. When a user locks RAAC tokens, they receive a proportionate amount of veRAACTokens. This locking mechanism ensures that users can increase the amount and duration of their existing locks but cannot create multiple separate locks. The protocol's documentation explicitly states that users must not be able to create more than one lock, reinforcing this restriction to maintain consistency in the system.

However, due to a bug in the contract, users can bypass this restriction and overwrite or destroy their existing locks by creating a new lock using the veRAACToken::lock function. This flaw allows users to circumvent the intended locking behavior, leading to unintended consequences that compromise the integrity of the protocol. Instead of reinforcing a single lock, the system mistakenly permits the replacement of previously locked tokens, introducing inconsistencies in the contract’s state.

This vulnerability has severe implications for the protocol’s core mechanisms. It disrupts fundamental components such as voting power calculations, the total supply of veRAACTokens, boost states, checkpoint states, and lock durations. The ambiguity in these values creates uncertainty across multiple protocol functionalities, rendering critical processes unreliable.

Furthermore, the flawed locking mechanism undermines key aspects of the protocol, including the rewards distribution mechanism (gauge system), the governance voting system, and historical data tracking. The inability to maintain a consistent lock state leads to an inaccurate representation of voting power and token supply, distorting governance participation and reward allocation. Over time, these inconsistencies erode trust in the protocol and may create opportunities for malicious exploitation.

Vulnerability Details

veRAACToken::lock:

On deeper inspection, it was discovered that a struct exists with a member intended to indicate whether a lock exists. However, this Lock struct is not actually used to determine the presence of a lock in the system.

Furthermore, this struct is incorporated as a member of the _lockState struct (or library). Under the hood, the LockManager library does not check for the existence of a lock during lock creation; it simply creates a new lock and overwrites any existing lock without performing any validation.

LockManager::createLock: (Out of Scope)

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 were successful to overwrite their old locks and this vulnerability creates severe ambiguities in the porotocol functionalities.

As demonstrated, the test confirms that the veRAACToken::lock function hasn't any existence check for already existing locks and this flaw severely disrupts the intended functionality of the protocol.

Impact

• Inaccurate Lock State Determination:
  The inability to correctly determine whether a lock exists leads to unreliable tracking of users' locked tokens, resulting in erroneous data regarding locked amounts and durations.

• Disrupted Voting Power Calculations:
  Inaccurate lock states directly affect the computation of voting power, potentially causing users to lose their rightful influence in governance decisions.

• Compromised Rewards Distribution:
  Since rewards and boost mechanisms rely on accurate lock information, overwritten locks can lead to improper reward allocation, undermining the fairness of the incentive system.

• Increased Vulnerability to Malicious Exploitation:
  The lack of validation in the LockManager library allows adversaries to deliberately overwrite existing locks, manipulating voting power and reward distribution for malicious gain.

• Erosion of Trust in the Protocol:
  These inconsistencies and vulnerabilities undermine the integrity of core protocol functionalities, potentially leading to reputational damage and reduced user confidence in the platform.

Tools Used

• Manual Review

• Foundry

• Console Log (foundry)

• a bit of pinch of mutational testing.

Recommendations

• Implement Existence Checks: (Out of scope)
  Modify the LockManager library to utilize the lock existence indicator in the Lock struct. Before creating a new lock, the contract should check whether an active lock already exists for the user.

• Prevent Overwriting of Existing Locks:
  Update the lock creation logic in the veRAACToken contract to either disallow the creation of a new lock if one already exists or enforce that users can only update (increase or extend) their existing lock.

• Improve Error Handling:
  Introduce clear and informative error messages when a user attempts to create a new lock while an active lock already exists, guiding them to use the appropriate functions (e.g., increase or extend).

One Possible solution is as follows:

veRAACToken::lock: