QuantAMM

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

Lambda Parameter Validation Missing in `UpdateRule::CalculateNewWeights` Function

Summary

In the UpdateRule::CalculateNewWeights function, the lambda parameter, which serves as the decay factor for the exponentially-weighted moving average, is passed in as part of the _lambdaStore array. The function currently lacks a validation check to ensure that the values passed for lambda are strictly within the expected range of 0<λ<10 < \lambda < 10<λ<1. This oversight can result in invalid values being used in the weight calculation, potentially causing incorrect computations or leading to unintended contract behaviour.

Vulnerability Details

  • Problem: The lambda parameter is supposed to represent a decay factor for an exponentially weighted moving average and must fall within the range 0<λ<10 < \lambda < 10<λ<1. This is clearly specified in the contract's NatSpec documentation. However, the CalculateNewWeights function does not enforce any checks on the values passed for lambda in the _lambdaStore array.

  • In particular, values greater than or equal to 1 (e.g., λ=1.5\lambda = 1.5λ=1.5 or λ=2\lambda = 2λ=2) or less than or equal to 0 (e.g., λ=0\lambda = 0λ=0) are allowed to be passed without triggering a revert or error.

  • Why is this a Problem?

    • The absence of range validation for lambda exposes the contract to several potential issues:

      • Incorrect Calculations: If lambda values outside the valid range are used, the exponentially weighted moving average calculation may produce incorrect results, leading to incorrect weights or volatility in the system.

      • Malicious Exploitation: An attacker could deliberately pass invalid lambda values, such as values greater than 1 or negative values, to disrupt the weight adjustment process or exploit vulnerabilities in the system.

    • Example Values That Are Invalid:

      • λ=1.5

      • λ=2

      • λ=0

    • Impact of Invalid Values:

      • Financial Impact: Inaccurate weight adjustments could lead to improper price discovery or manipulation of the AMM.

      • Contract Integrity: Incorrect lambda values could destabilize the moving average calculation or the weight updates, affecting the liquidity pool and users interacting with the contract.

Impact

If users or malicious actors provide invalid values for lambda in _lambdaStore, the system may behave unpredictably. This could lead to incorrect weight updates, which in turn could affect the liquidity of assets in the pool, cause potential financial losses, or disrupt the overall functioning of the AMM. This could be a significant risk, especially in a system where the weights determine the distribution of assets and control the pricing model.

Tools Used

Manual Review

Recommendations

To mitigate the issue, validation checks should be added to ensure that the values for lambda fall within the expected range of 0<λ<10 < \lambda < 10<λ<1.

  • Suggested Fix: Add the following line within the loop that iterates over the lambda values in the CalculateNewWeights function to enforce the valid range check:

    require(_lambdaStore[locals.i] > 0 && _lambdaStore[locals.i] < 1 * 10**18, "Invalid lambda value");

Here, we ensure that:

  • lambda is strictly greater than 0.

  • lambda is strictly less than 1 (with 1 * 10**18 used for fixed-point arithmetic precision).

This will immediately revert any transaction that passes an invalid lambda value and ensure the contract functions according to its design specification.

The missing validation for the lambda values poses a significant risk to the QuantAMM contract, as it allows invalid values to be passed, potentially leading to incorrect behavior and security vulnerabilities. By implementing the above check, the contract can be secured against invalid input values and function as expected, maintaining the integrity of the AMM.

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.

Support

FAQs

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