Core Contracts

BaseGauge.sol

Overview

The code snippet shows:

But in the actual reward distribution flow:

• notifyRewardAmount(uint256 amount) calls:

  if (amount > periodState.emission) revert RewardCapExceeded();

  ...

  rewardRate = notifyReward(periodState, amount, periodState.emission, getPeriodDuration());

  ​

  to set rewardRate based on the period’s emission.

• No check references distributionCap or compares amount against distributionCap.

Hence, a user or admin can pass an amount to notifyRewardAmount(...) that exceeds distributionCap, and the contract never reverts. The only check is if (amount > periodState.emission) revert RewardCapExceeded();.

Impact

1. Misleading Admin Setting
   The distributionCap variable is presumably intended to impose a final limit on how many reward tokens can be distributed from this gauge. But because the code never references it, an admin who sets distributionCap is not truly limiting anything.

2. Incomplete or Contradictory Behavior
   If the protocol’s design calls for a maximum distribution cap across an entire gauge’s lifetime, ignoring it in notifyRewardAmount or _updateReward means the gauge can exceed that cap with no revert.

3. Potential Overdistribution
   The contract checks only periodState.emission, but if distributionCap is supposed to be an additional or global distribution limit beyond the per-period emission, it’s never enforced.

Proof / PoC Example

A minimal test:

If distributionCap was intended as a global or per-call limit, the call should revert but does not.

Recommendation

1. Enforce distributionCap
   In notifyRewardAmount(...), add:

   if (distributionCap > 0 && amount > distributionCap) {

   revert("Amount exceeds distributionCap");

   }

   ​

   or a similar check ensuring the newly requested distribution does not surpass distributionCap. Possibly also track total distributed to ensure cumulative distributions cannot exceed the cap.

2. Remove distributionCap
   If the protocol logic only uses periodState.emission to limit distributions, remove distributionCap altogether to reduce confusion.

3. Document Distinct Purposes
   If the contract intends to have both a “per‐period limit” (via periodState.emission) and an overall distribution limit (distributionCap), each must be clearly checked, documented, and enforced. Right now, only periodState.emission is used.