In BoostController contract where the maximum boost multiplier is improperly constrained by a hardcoded constant (MAX_BOOST = 25000) instead of utilizing the configurable boostState.maxBoost parameter. This flaw renders the protocol's boost adjustment mechanism ineffective, permanently capping user boosts at 2.5× even when administrators attempt to raise the limit via governance actions.
The BoostController implements a Curve-style boost system where:
MAX_BOOST is defined as 25,000 basis points (2.5× multiplier)
Administrators can configure boost parameters via setBoostParameters()
Boost calculations occur in _calculateBoost() and getBoostMultiplier()
Two key functions incorrectly reference the constant MAX_BOOST rather than the dynamic boostState.maxBoost:
1. Boost Calculation Capping (_calculateBoost):
The setBoostParameters() function updates boostState.maxBoost but these changes never propagate to critical calculations
Protocol remains bound to 25,000 basis points (2.5×) despite configuration changes
Creates inconsistency between configured parameters and actual system behavior
Users receive incorrect boost rewards relative to protocol configuration
Manual Code Review
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.