Core Contracts

Summary

The emission rate update functions in both RAACGauge and RWAGauge lack validation against their defined maximum emission constants, allowing emissions to be set higher than intended limits.

Vulnerability Details

In RAACGauge:

In RWAGauge:

The functions allow setting arbitrary emission values without checking against:

• MAX_WEEKLY_EMISSION (500,000e18) for RAACGauge

• MAX_MONTHLY_EMISSION (2,500,000e18) for RWAGauge

This is confirmed by:

1. Constants are explicitly defined RAACGauge.sol line 17, RWAGauge.sol line 17

   uint256 public constant MONTH = 30 days;

   uint256 public constant MAX_MONTHLY_EMISSION = 2500000e18; // 2.5M tokens
   uint256 public constant WEEK = 7 days;

   uint256 public constant MAX_WEEKLY_EMISSION = 500000e18; // Maximum weekly emission

2. Documentation explicitly states "Emission caps enforced" RAACGauge.md line 101

3. BaseGauge's notifyReward checks emission caps but setWeeklyEmission/setMonthlyEmission bypass these checks

Impact

• Emissions can exceed maximum intended limits

• Potential economic damage through excessive token distribution

• Disruption of tokenomics model

• Bypass of emission cap checks in BaseGauge's notifyReward function

The lack of validation could lead to:

1. Inflation of token supply beyond intended rates

2. Economic imbalances in the protocol

3. Manipulation of reward distributions

4. Breaking of carefully designed tokenomics parameters

Tools Used

• Manual Review

• Static Analysis

Recommendations

Add maximum emission validation:

Similarly for monthly emissions:

Additional considerations:

1. Consider adding a timelock for emission rate changes

2. Implement gradual adjustment mechanisms for large changes

3. Add events for emission cap violations

4. Consider implementing emergency pause for excessive emissions