Core Contracts

Summary

The veRAAcToken contract defines two separate mappings for lock positions: one as a public mapping called locks and another within the LockManager library stored in _lockState.locks. The contract’s public locks mapping is never updated when locks are created or modified.

Vulnerability Details

The root cause is that the implementation uses the LockManager library to manage locks but also declares a separate locks mapping in the contract storage. The two sources are not synchronized, and the public mapping is effectively ignored.

For example, suppose User A locks 1,000 RAAC tokens for one year. The LockManager updates _lockState.locks[A] correctly, but the public locks[A] remains uninitialized (defaulting to zero). When User A or external services call getLockedBalance(A), they receive 0 instead of 1,000, causing confusion and potential transaction rejections where lock information is required.

Impact

Functions such as getLockedBalance and getLockEndTime that rely on the public locks mapping will return incorrect or zero values, even though valid locks exist in _lockState.locks. This inconsistency can lead to failed transactions and misleading information being reported to users.

Recommendations

Eliminate the redundant public locks mapping. Instead, expose lock information directly from the LockManager’s data (e.g., by creating getter functions that return _lockState.getLock(account)). This ensures that all lock-related functions use the same, correct source of truth.