QuantAMM

Summary

Logic in _normalizeWeightUpdates() is flawed. In the UpdateRule.sol file CalculateNewWeights() function calculates the weights. It calls _getWeights() function which is specific to the rule to calculate the updated weights. These weights are unguarded and it will call _guardQuantAMMWeights() as a last function to guard the weights or to make it in limit. This _guardQuantAMMWeights() function contains two functions _clampWeights() to see if the weights go beyond the maximum/minimum weights and another is
_normalizeWeightUpdates() to reduce even further if the weight change is beyond the allowed "speed limit". Logic inside the _normalizeWeightUpdates allows to set the negative weights(Added PoC). These negative weights will be sent back to the CalculateNewWeights() function which sends these weights to _performUpdateAndGetData() function which again calls _calculateMultiplierAndSetWeights() which calls setWeights and set this weights to the pool.

Negative Weight is not allowed in balancer. Negative weights would imply a negative value or debt associated with a token, which is not supported in Balancer’s design. Each token must contribute positively to the pool's total value.

Proof Of Code

To test it paste this code inside MathGuard.t.sol file.

Output = -7.5e16, 1e17, 2e17, 1e17, 6.75e17

Now these negative weights will be saved in the pool. When the users calls calculateBlockNormalisedWeight() to get the current weight it converts negative int to unit without proper check

Previous audit points for multiplier and fixed but here after converting negative integer of weight to uint256 will give completely wrong value of weight which will be much more high value. Hence wrong value of weights.

Impact

1. Breaking the GuardRail

2. Wrong calculation of the weights

Tools Used

Manual Review, Foundry

Recommendations

This test works correctly. Instead of removing extra weights from first element if removed from the highest weight it works properly

Output = 5e17, 1e17, 2e17, 1e17, 1e17