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

Inconsistent Fixed-Point Decimal Handling in UpdateRule.sol

efccweb3

Summary

The UpdateRule.sol contract fails to properly convert input parameters to 18 decimal point precision before calculations, despite the codebase's documentation and other components explicitly requiring 18dp precision. This inconsistency can lead to significant calculation errors in weight updates and pool behavior.

Vulnerability Details

The QuantAMM protocol documentation states that "The int256s used are converted to 18dp using the PRBMath lib". However, in UpdateRule.sol, particularly in the CalculateNewWeights function, several parameters are used without proper 18dp conversion.

function CalculateNewWeights(
int256[] calldata _prevWeights,
int256[] calldata _data,
address _pool,
int256[][] calldata _parameters,
uint64[] calldata _lambdaStore,
uint64 _epsilonMax,
uint64 _absoluteWeightGuardRail
) external returns (int256[] memory updatedWeights) {
// ...
for (locals.i; locals.i < locals.lambda.length; ) {
locals.lambda[locals.i] = int128(uint128(_lambdaStore[locals.i]));
unchecked {
++locals.i;
}
}
}

Other contracts in the codebase properly handle 18dp precision:
// In QuantammMathGuard.sol

using PRBMathSD59x18 for int256;
int256 private constant ONE = 1 * 1e18;
// In QuantammMathMovingAverage.sol
newMovingAverage[i] = movingAverageI + oneMinusLambda.mul(_newData[i] - movingAverageI);
POC

// Current implementation

lambda = int128(uint128(0.5)) // Results in 0

// Should be

lambda = int128(uint128(PRBMathSD59x18.fromInt(0.5))) // Should be 0.5e18

Impact

Weight calculations may be off by several orders of magnitude

Tools Used

Manual review

Recommendations

Add proper 18dp conversion in CalculateNewWeights

Updates

Lead Judging Commences

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

Support

FAQs

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