QuantAMM

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

Incorrect gradient update logic in QuantAMMGradientBasedRule::_setGradient function

Summary

The condition for updating the intermediateGradientStates mapping in the QuantAMMGradientBasedRule::_setGradient function is incorrect, leading to unintended behavior in subsequent calls.

Vulnerability Details

In the QuantAMMGradientBasedRule::_setGradient function, the logic to update the intermediateGradientStates[poolAddress] array relies on the condition:

QuantAMMGradientBasedRule::_setGradient function:

function _setGradient(address poolAddress, int256[] memory _initialValues, uint _numberOfAssets) internal {
uint storeLength = intermediateGradientStates[poolAddress].length;
=> // @audit Condition `_initialValues.length == storeLength` is incorrect
=> if ((storeLength == 0 && _initialValues.length == _numberOfAssets) || _initialValues.length == storeLength) {
intermediateGradientStates[poolAddress] = _quantAMMPack128Array(_initialValues);
} else {
revert("Invalid set gradient");
}
}

This condition is problematic because the length of the intermediateGradientStates[poolAddress] array after updating is calculated as .
For example:

  • If _initialValues.length == 8, the resulting intermediateGradientStates[poolAddress].length will be 4.

  • When _setGradient is called again, the condition _initialValues.length == storeLength (i.e., _initialValues.length == 4) is expected to pass. However, this condition fails because _initialValues.length should remain consistent with the original number of assets (_numberOfAssets) rather than shrinking after each update.

Impact

This incorrect condition results in the inability to correctly set new gradient values in subsequent calls.

Recommendations

Update the condition to ensure that it verifies the relationship between _initialValues.length and storeLength correctly.

Updates

Lead Judging Commences

n0kto Lead Judge 10 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Informational or Gas / Admin is trusted / Pool creation is trusted / User mistake / Suppositions

Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelyhood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.

Appeal created

ragnarok Submitter
10 months ago
n0kto Lead Judge
10 months ago
n0kto Lead Judge 10 months ago
Submission Judgement Published
Validated
Assigned finding tags:

finding_setGradient_unusable_length_stored_new_values_are_different

Impact: Medium/High, the breakglass function is unusable. Likelihood: Low/Medium, when `setIntermediateValuesManually` is called by the admin to correct the intermediate values in case of any problem.

Support

FAQs

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

Give us feedback!