QuantAMM

QuantAMM
49,600 OP
View results
Submission Details
Severity: medium
Invalid

Precision Loss in QuantAMM's Moving Average Calculation Due to Suboptimal Fixed-Point Operation Ordering

Description

The _calculateQuantAMMMovingAverage function in QuantAMMMathMovingAverage.sol implements an exponential moving average calculation with a suboptimal ordering of arithmetic operations that introduces significant precision loss and overflow risks:

https://github.com/Cyfrin/2024-12-quantamm/blob/a775db4273eb36e7b4536c5b60207c9f17541b92/pkg/pool-quantamm/contracts/rules/base/QuantammMathMovingAverage.sol#L23

newMovingAverage[i] = movingAverageI + oneMinusLambda.mul(_newData[i] - movingAverageI);

The current implementation performs operations in a sequence that introduces significant precision risks in fixed-point arithmetic. First calculating _newData[i] - movingAverageI before any scaling leads to potential precision loss in the initial subtraction. This is then compounded by the multiplication with oneMinusLambda, and finally adding back to movingAverageI. When dealing with significantly different values between _newData[i] and movingAverageI, this can lead to overflow or underflow conditions. Moreover, since this calculation is repeated over time, any precision loss compounds across multiple updates.

Impact

The precision loss in moving average calculations has severe implications for the protocol's price tracking and weight adjustment mechanisms. At a technical level, the moving average computation serves as a foundational input for the protocol's various trading strategies, making its accuracy critical for proper operation. When these moving averages become imprecise, the error propagates through the protocol's risk assessment system in multiple ways. Strategy implementations that rely on accurate price trend detection, such as momentum and anti-momentum approaches, become less reliable as the price smoothing mechanism degrades. Since these moving averages serve as denominators in gradient calculations, any precision errors are amplified when used in weight updates, directly impacting the protocol's ability to maintain mathematically optimal portfolio weights.

Recommended Mitigation Steps

The solution is to reorder operations to perform scaling before any subtraction, using the mathematically equivalent form:

// Reordered implementation: λp̅(t-1) + (1-λ)p(t)
newMovingAverage[i] = _prevMovingAverage[i].mul(convertedLambda) +
_newData[i].mul(oneMinusLambda);

This revised implementation first scales the values using multiplication before combining them. By eliminating unscaled operations on potentially large numbers, this approach maintains better precision and reduces the risk of numeric errors. The fix remains mathematically equivalent while providing significantly improved numerical stability, making it crucial for the protocol's core price tracking mechanisms.

Updates

Lead Judging Commences

n0kto Lead Judge 10 months ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.