QuantAMM
QuantAMM
49,600 OP
View results
Previous Next
Submission Details
Severity: high
Valid

Inconsistent Storage Array Indexing in QuantAMMGradientBasedRule Contract

akay

Summary

The _calculateQuantAMMGradient function in QuantAMMGradientBasedRule.sol is inconsistent in its array indexing between its scalar and per-constituent lambda cases when storing packed gradient values

Vulnerability Details

In the _calculateQuantAMMGradient function, there are two main code paths:

The Scalar lambda case when _poolParameters.lambda.length == 1:

intermediateGradientStates[_poolParameters.pool][locals.storageArrayIndex] = _quantAMMPackTwo128(
locals.intermediateGradientState[i],
locals.secondIntermediateValue
);

and the per-constituent lambda case:

intermediateGradientStates[_poolParameters.pool][i] = _quantAMMPackTwo128(
locals.intermediateGradientState[i],
locals.secondIntermediateValue
);

The scalar case correctly uses locals.storageArrayIndex which increments by 1 but the per-constituent case incorrectly uses i which increments by 2. Both cases increment locals.storageArrayIndex in their unchecked blocks, but only one case uses it

Impact

Using i as the storage index results in non-continuous storage slots (0, 2, 4, etc.) and it also wastes storage slots and increases gas costs.

Tools Used

  • Manual code review

Recommendations

// Change in the per-constituent lambda case:
intermediateGradientStates[_poolParameters.pool][locals.storageArrayIndex] = _quantAMMPackTwo128(
locals.intermediateGradientState[i],
locals.secondIntermediateValue
);
Updates

Lead Judging Commences

n0kto Lead Judge 11 months ago
Submission Judgement Published
Validated
Assigned finding tags:

finding_gradient_rules_more_than_3_assets_and_1_lambda_will_DoS_the_update

Likelihood: Medium/High, assets>4, lambdas > 1. Impact: Medium/High, DoS update but pool works fine. Pool with 5 assets will use incorrect weights.

Support

FAQs

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

Give us feedback!