Core Contracts

Relevant GitHub Links

https://github.com/Cyfrin/2025-02-raac/blob/89ccb062e2b175374d40d824263a4c0b601bcb7f/contracts/core/governance/gauges/BaseGauge.sol#L154

https://github.com/Cyfrin/2025-02-raac/blob/89ccb062e2b175374d40d824263a4c0b601bcb7f/contracts/core/governance/gauges/BaseGauge.sol#L610-L612

Summary

The _periodDuration constructor parameter and getPeriodDuration() function do not reliably track the same value, creating a risk of protocol inconsistency. While intended to represent the same period duration, they are decoupled in implementation.

Vulnerability Details

Key Problem:

1. Constructor Parameter (_periodDuration):
   Used during initialization to:

   • Set periodState.periodStartTime

   • Create the initial votingPeriod via TimeWeightedAverage.createPeriod()

2. Function (getPeriodDuration()):
   Used at runtime for:

   • Reward rate calculations (notifyRewardAmount())

   • Weight updates (_updateWeights())

   • Period management (updatePeriod())

Critical Discrepancy:

• Child contracts (like RWAGauge/RAACGauge) must override getPeriodDuration() to return the same value as their constructor's _periodDuration.

• No Compile-Time Enforcement: A new gauge inheriting BaseGauge could pass _periodDuration=30 days in the constructor but fail to override getPeriodDuration(), causing it to default to 7 days.

Example:

This would initialize periods with 30-day logic but use 7-day math at runtime.

Impact

• Reward Distribution Errors: rewardRate would be calculated using the wrong duration (7 days instead of 30 days).

• Voting Weight Corruption: Time-weighted averages become inaccurate due to mismatched period tracking.

• Silent Failure Mode: No revert occurs - protocol operates with incorrect assumptions.

Tools Used

• Manual code analysis

Recommendations

Enforce Value Consistency:
Add a constructor check to ensure getPeriodDuration() matches _periodDuration: