Core Contracts

BaseGauge.sol

Overview

Inside BaseGauge, we see:

But no function performs a check or revert referencing MAX_SLIPPAGE. For example:

• Staking/Withdrawing: The code doesn’t check slippage when transferring stakingToken.

• Reward Claim: The logic in getReward() also never references MAX_SLIPPAGE.

• Boost Calculation: The _applyBoost function, or any other, doesn’t mention slippage.

Hence, the constant is never read or enforced, effectively leftover or incomplete logic.

Impact

1. Misleading for Maintainers
   Developers or auditors might assume the gauge enforces a 1% maximum slippage in some step—e.g., cross-contract calls or reward conversions. But the code performs no such checks, meaning an admin or user might incorrectly rely on the existence of “slippage limit” logic.

2. Incomplete or Abandoned Feature
   If the design intended to guard against extreme price changes or cross-swap slippage in an external call, it was never implemented. The presence of an unused MAX_SLIPPAGE is a sign the feature is incomplete or removed.

3. Cluttered Code
   Unused constants add confusion and can hamper clarity in a large codebase, making it harder to distinguish real checks from unimplemented placeholders.

Demonstration

A quick search or inspection of “slippage” in the code snippet shows no usage besides the definition:

One might expect lines like if (someSlippage > MAX_SLIPPAGE) revert SlippageTooHigh(); or a function param relating to slippage—none exist.

Recommended Fix

1. Implement Slippage Validation
   If the gauge must limit slippage in a swap or bridging call, add logic:

   if (actualSlippagePercentage > MAX_SLIPPAGE) {

   revert SlippageExceeded();

   }

   //or something similar where relevant.