BalancerV3 pools rely on nonnegative weights to determine proportional ownership of liquidity. In BalancerV3, each token is assigned a weight that must be >= 0. Negative weights would represent a “negative allocation” of an asset, which does not make sense in typical AMM math.
Problem is the current logic allow a negative weight to be set.
The code in AntiMomentumUpdateRule.sol’s _getWeights() method:
In the single-κ branch above, there is no require(res >= 0). If _prevWeights[locals.i] or locals.newWeights[locals.i] are large enough in opposite directions, res can become negative. Balancer pools cannot handle negative weights, so this can lead to invalid pool states or reverts down the line.
The pool’s formula for token prices and invariant depends on positive weights. Negative weights cause reverts or incorrect spot prices. This disrupts trading and can freeze the pool.
Misallocation of assets can lead to loss of funds.
Manual Review & BalancerV3 docs
Require nonnegative final weights when the locals.kappa.length == 1:
_clampWeights will check that these weights are positive and in the boundaries before writing them in storage.
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.