Summary

The protocol fails to properly validate the total locked RAAC tokens against MAX_TOTAL_LOCKED_AMOUNT while using incorrect checks for veRAAC supply limits. This allows attackers to bypass intended caps, potentially overflowing the veRAAC total supply and exceeding RAAC lock limits.

Vulnerability Details

Affected Code:

1. Lock Creation (veRAACToken.sol):

   function lock(uint256 amount, uint256 duration) external ... {

   // Flawed check: Compares RAAC "amount" to veRAAC "totalSupply"

   if (totalSupply() + amount > MAX_TOTAL_SUPPLY) revert TotalSupplyLimitExceeded();

   ...

   }

2. Increase Lock (LockManager.sol):

   function increaseLock(...) internal {

   // Missing check: No validation for "maxTotalLocked"

   // if (state.totalLocked + additionalAmount > state.maxTotalLocked) revert ...;

   lock.amount += additionalAmount;

   state.totalLocked += additionalAmount;

   }

Root Cause:

• The lock() function incorrectly compares the RAAC token amount to the veRAAC total supply cap (MAX_TOTAL_SUPPLY), creating a unit mismatch.

• The increaseLock() function lacks validation for maxTotalLocked, allowing the total locked RAAC to exceed MAX_TOTAL_LOCKED_AMOUNT.

Impact

1. veRAAC Supply Overflow:

   • Attackers can mint more veRAAC tokens than allowed by MAX_TOTAL_SUPPLY through carefully timed short-duration locks.

2. RAAC Lock Limit Bypass:

   • The missing maxTotalLocked check in increaseLock() allows a single user to bypass per-lock limits by repeatedly increasing their lock amount.

Proof of Concept
Steps to Exploit:

1. Setup:

   • MAX_TOTAL_SUPPLY = 100M veRAAC

   • MAX_TOTAL_LOCKED_AMOUNT = 1B RAAC

2. Attack:

   • Attacker locks 400M RAAC for 1 year via lock():

     • veRAAC minted: 400M * 1/4 = 100M.

     • RAAC locked: 400M (40% of MAX_TOTAL_LOCKED_AMOUNT).

   • Attacker creates 3 new accounts and repeats:

     • Total RAAC locked: 400M * 4 = 1.6B (exceeds 1B).

     • Total veRAAC supply: 100M * 4 = 400M (exceeds 100M).

Result:

• RAAC Lock Overflow: 1.6B RAAC locked (160% of limit).

• veRAAC Supply Overflow: 400M veRAAC minted (400% of limit).

Tools Used

• Manual code analysis.

Recommendations

1. Correct veRAAC Supply Check:
   Replace the flawed RAAC-based check with a veRAAC-based check in lock():

   // Calculate veRAAC to mint first

   uint256 newPower = (amount * duration) / MAX_LOCK_DURATION;

   if (totalSupply() + newPower > MAX_TOTAL_SUPPLY) revert TotalSupplyLimitExceeded();

2. Enforce RAAC Lock Limits:

   • Uncomment and enforce maxTotalLocked in LockManager.increaseLock():

     if (state.totalLocked + additionalAmount > state.maxTotalLocked) revert AmountExceedsLimit();

   • Add a similar check in veRAACToken.lock():

     if (_lockState.totalLocked + amount > MAX_TOTAL_LOCKED_AMOUNT) revert TotalLockedExceeded();

3. Mitigation Example:
   After fixes:

   • Locking 400M RAAC for 1 year would mint 100M veRAAC but check totalLocked + 400M ≤ 1B (allowed).

   • A second lock of 600M RAAC for 1 year would fail the totalLocked check (400M + 600M > 1B).

Conclusion

The mismatch between RAAC lock limits and veRAAC supply checks creates systemic risk. Immediate fixes are required to align validation logic with protocol intent.