Core Contracts

Summary

The GaugeController::addGauge function is responsible for adding new gauges to the system, initializing gauge-specific parameters, and creating an associated time period using the TimeWeightedAverage library. In this process, a non-zero minimum weight is enforced for period tracking by using the expression:

However, while periodWeight is correctly computed and used for period creation, the gauge's own stored weight is mistakenly set to initialWeight instead of periodWeight. As a result, if initialWeight is zero, the gauge’s stored weight becomes zero. Later, when the updatePeriod function is called, it passes g.weight (which is zero) to the TimeWeightedAverage.createPeriod function. Since that function checks that weight is not zero (reverting with ZeroWeight if it is), every attempt to update the gauge period results in a revert. Consequently, the gauge’s period state cannot be updated, effectively causing a permanent denial of service (DoS) for that gauge.

Vulnerability Details

Incorrect Weight Storage in addGauge

In the addGauge function, the minimum period weight is determined to ensure that period creation does not fail due to a zero weight:

This ensures that if the admin passes initialWeight == 0, the period used for time-weighted calculations will have a weight of 1.

However, when the gauge is stored in the contract’s mapping, the code incorrectly assigns the gauge’s weight using initialWeight rather than periodWeight:

Impact on updatePeriod Function

Later, the updatePeriod function attempts to update the gauge’s time period state. It retrieves the gauge’s stored weight (which may be zero) and passes it to the TimeWeightedAverage period creation call:

The TimeWeightedAverage library’s createPeriod function includes a check that prevents period creation if weight is zero:

Thus, if initialWeight was zero at the time of gauge creation, g.weight remains zero, and every subsequent call to updatePeriod will revert with a ZeroWeight error. This failure to update the gauge’s period state causes a permanent denial of service (DoS) for that gauge, disrupting time-weighted average calculations, reward distributions, and governance mechanisms that depend on up-to-date gauge data.

Visual Code Highlights

• In addGauge:

  // Calculate minimum period weight for tracking (non-zero)

  uint256 periodWeight = initialWeight == 0 ? 1 : initialWeight;

  ...

  gauges[gauge] = Gauge({

  weight: initialWeight, // <-- BUG: Should be periodWeight!

  typeWeight: 0,

  lastUpdateTime: block.timestamp,

  gaugeType: gaugeType,

  isActive: true,

  lastRewardTime: block.timestamp

  });

• In updatePeriod:

  // In updatePeriod, gauge weight is used for period creation:

  TimeWeightedAverage.createPeriod(

  period,

  block.timestamp + 1,

  duration,

  average, // or 0 if first period

  g.weight // <-- If g.weight is 0, this call reverts with ZeroWeight()

  );

• In TimeWeightedAverage::createPeriod:

  if (weight == 0) revert ZeroWeight();

Proof of Concept

The following Foundry test suite demonstrates the vulnerability. The test creates a gauge with an initialWeight of zero, causing the gauge’s stored weight to be zero. Later, when attempting to update the period, the call reverts with ZeroWeight, confirming the DoS condition.

How to Run the Test

1. Create a Foundry Project:

   forge init my-foundry-project

2. Remove Unnecessary Files:
   Delete extraneous files to keep the project clean.

3. Convert or Import Contracts:
   Place your contract files in the src directory.

4. Create Test and Mocks Folders:
   Create a test directory adjacent to src and include any necessary mock contracts.

5. Add the Test Suite:
   Create a file named GaugeTest.t.sol in the test directory and paste the above test suite.

6. Run the Test:

   forge test --mt testGaugeControllerUpdatePeriodFailsDueToZeroGaugeWeight -vv

7. Expected Output:
   The test should revert with ZeroWeight(), confirming that the gauge period update fails due to the stored gauge weight being zero.

Impact

• Immediate Denial of Service (DoS):
  Gauges added with an initial weight of zero will never have their period state updated, effectively locking the gauge in a stale state.

• Disrupted Reward Distribution:
  Since gauge periods are used to calculate time-weighted averages for reward distribution, failing to update these periods leads to incorrect reward allocations.

• Governance and System Instability:
  Inaccurate gauge information affects governance decisions and user incentives, undermining the trust and stability of the entire protocol.

• Potential Exploitation:
  Malicious admins or attackers might deliberately set gauges with zero weight to disrupt the system or manipulate reward and governance outcomes.

Tools Used

• Manual Review

• Foundry

Recommendations

To resolve this vulnerability, the gauge’s stored weight must be initialized with the non-zero periodWeight value rather than the raw initialWeight. This ensures that subsequent calls to updatePeriod use a valid weight and do not revert.

Diff Recommendations for GaugeController::addGauge