Core Contracts

RAACGauge and RWAGauge each declare specialized time frames and functionalities (“weekly” or “monthly,” “time-weighted voting power,” “yield direction,” etc.), yet the actual code is mostly a direct pass-through to BaseGauge with minimal overrides for period length and emission limit. No advanced logic or unique weighting is implemented. The documentation (and possibly developer expectations) misrepresents the actual code, which remains quite minimal. Updating either the doc (to remove overstated features) or the code (to truly implement specialized logic) is advisable to align with best practices and user expectations.

Overview

1. RAACGauge states:

   /**

   * @title RAACGauge

   * @notice Implements weekly gauge for RAAC emission direction with time-weighted voting

   * ...

   */

   ​

   But the contract primarily overrides getPeriodDuration() => WEEK and sets a MAX_WEEKLY_EMISSION:

   function getPeriodDuration() public pure override returns (uint256) {

   return WEEK; // 7 days

   }

   ...

   function setWeeklyEmission(uint256 _weeklyEmission) external onlyController {

   periodState.emission = _weeklyEmission;

   emit EmissionUpdated(_weeklyEmission);

   }

   ​

   Beyond that, it calls the same “voteDirection” from BaseGauge, using the same _applyBoost(...), ignoring staked tokens for weighting, etc. The doc suggests a “weekly gauge for RAAC emission with time-weighted voting,” but the code introduces no unique weekly logic beyond a 7-day period.

2. RWAGauge states:

   /**

   * @title RWAGauge

   * @notice Monthly gauge for RWA yield direction with time-weighted voting

   * @dev Experimental and incomplete implementation - do not use in production

   */

   ​

   The doc references “time-weighted voting power decay” specifically for RWA. In reality, it just sets getPeriodDuration() => 30 days and calls voteYieldDirection(...) which is effectively a rename of the base gauge’s voteDirection(...). There’s no special monthly logic for yield direction or separate “time decay” beyond what BaseGauge already does.

Consequences

1. Unimplemented or Incomplete Features
   Users or developers reading “time-weighted voting” for RWA or “weekly gauge for RAAC” might expect advanced logic or distinct distribution mechanics. Instead, these child contracts are nearly identical to BaseGauge, only changing a constant period and an emission limit.

2. Misleading Documentation
   Comments about “monthly gauge with time-weighted voting power decay” are not realized in code. The user’s staked balances are still not considered for weighting (as found in BaseGauge), nor is any special monthly yield logic introduced. RAACGauge similarly lacks advanced RAAC emission nuance beyond the 7-day period.

3. Potential Production Risk
   The doc warns that RWAGauge is “experimental and incomplete,” but RAACGauge also appears incomplete if the user expected unique RAAC emission direction logic. If teams rely on doc statements about advanced logic, they risk confusion or code mismatch.

Recommendation

1. Implement Distinct Logic

   • If RAACGauge is truly “weekly gauge for RAAC,” add specialized distribution or time weighting beyond the standard BaseGauge. Perhaps factor in user staked amounts or a special weekly cycle for emission updates.

   • If RWAGauge needs “time-weighted voting power decay,” actually override or expand _applyBoost(...) or add new logic to handle monthly yield direction beyond the base gauge’s approach.

2. Clarify or Remove Overstated Comments

   • If the contracts are intentionally minimal, remove or rewrite doc comments claiming advanced monthly/weekly logic or “time-weighted decay.”

   • For the “Experimental and incomplete” RWAGauge, highlight which features are missing and how it differs from production readiness.