Core Contracts

Summary

The BoostController contract incorrectly uses a hardcoded constant (MAX_BOOST) instead of the dynamically adjustable boostState.maxBoost parameter when capping boosted amounts. This breaks the intended configurability of the protocol and enforces an artificial boost limit.

Vulnerability Details

In _calculateBoost(), the maximum boosted amount is calculated as:

However:

• MAX_BOOST is a constant fixed at 25000 (2.5x).

• The setBoostParameters() function allows boostState.maxBoost to be set up to 50000 (5x).

This creates a contradiction: while the protocol claims to support configurable boosts via boostState.maxBoost, the actual enforcement uses an immutable constant. As a result, even if boostState.maxBoost is increased, the effective maximum boost remains capped at 25000.

Code Path:

1. Admin calls setBoostParameters(50000, ...) to raise the max boost to 5x.

2. User attempts to claim a boosted amount exceeding 2.5x.

3. _calculateBoost() caps the result at 2.5x due to MAX_BOOST, ignoring the configured 5x limit.

Impact

• Broken Protocol Functionality: The core feature of adjustable boosts is non-functional.

• User Impact: Users cannot receive boosts beyond 2.5x, even when protocol parameters allow it.

• Trust Degradation: Admins may unknowingly deploy a system with non-functional configurations.

Severity: High (directly undermines a key protocol mechanism).

Argument for High Severity:

This vulnerability warrants a High severity rating due to the following factors:

1. Direct Impact on Core Protocol Functionality

• What’s Broken: The ability to adjust the maximum boost multiplier (maxBoost) is a core governance feature explicitly exposed via setBoostParameters(). This parameter is critical for protocol adaptability (e.g., incentivizing users during liquidity shortages by raising boosts).

• Consequence: By hardcoding MAX_BOOST, the protocol permanently locks the maximum boost at 2.5x, rendering the setBoostParameters() function non-functional for its primary purpose. This is not a "nice-to-have" feature but a fundamental failure of a governance mechanism.

2. Violation of Trust in Governance

• Admin Expectations: When admins call setBoostParameters(), they rightfully expect the protocol to enforce the new limits. This vulnerability silently ignores their input, creating a disconnect between intended and actual behavior.

• User Impact: Users relying on the protocol’s advertised boost mechanics (e.g., staking based on the expectation of a 5x boost) will receive lower rewards than promised, leading to financial losses and loss of trust.

3. Irreversible Damage Without Fix

• No Workaround: Once deployed, the hardcoded MAX_BOOST cannot be altered (as it is an immutable constant). This forces a protocol upgrade to resolve, which is costly and risks user funds during migration.

• Permanent Constraint: Even if boostState.maxBoost is adjusted to 50000 (5x), all boosted amounts will still be capped at 2.5x. This directly violates the protocol’s economic design.

4. Comparison to Industry Standards

• OWASP Classification: This falls under A06:2021 – Vulnerable and Outdated Components, where misconfigured or immutable parameters lead to unintended behavior.

• CWE Reference: CWE-665: Improper Initialization – Failure to correctly initialize dynamic parameters results in a static, non-adjustable system.

Tools Used

• Manual code review to identify mismatches between constants and state variables.

• Control flow analysis to trace parameter usage.

Recommendations

1. Replace MAX_BOOST with boostState.maxBoost:

   uint256 maxBoostAmount = amount * boostState.maxBoost / 10000;

2. Deprecate Redundant Constants: Remove the MAX_BOOST constant or ensure it aligns with boostState.maxBoost during initialization.

3. Add Validation to setBoostParameters:

   function setBoostParameters(...) external ... {

   require(maxBoost <= 50000, "Absolute max exceeded"); // Enforce global ceiling

   // ...

   }

4. Testing:

   • Verify that increasing boostState.maxBoost via setBoostParameters() correctly raises the boost cap.

   • Add edge-case tests for the 5x boundary.

This ensures the protocol’s boost mechanics behave as documented and remain dynamically adjustable.