QuantAMM

Summary

The vulnerability lies in the initialisePoolRuleIntermediateValues function of the UpdateRule contract, which implements the IUpdateRule interface. The parameter order in the function signature of the interface does not match the implementation. Specifically, the second and third parameters (_newIntermediateValues and _newParameters in the interface) are swapped compared to the implementation (_newMovingAverages and _newInitialValues).

Vulnerability Details

IUpdateRule::initialisePoolRuleIntermediateValues:

UpdateRule::initialisePoolRuleIntermediateValues:

Impact

This mismatch creates potential for serious issues:

• Interface Compliance Error: The implementation cannot correctly inherit from the interface due to the parameter order mismatch.

• Runtime Errors or Misbehavior: If the function is called using the interface, swapped arguments can cause incorrect initialization of pool variables, leading to logic inconsistencies.

• State Initialization Issues: Improper initialization of moving averages or intermediate values may destabilize pool calculations and behavior.

Protocol impact:

_newMovingAverages and _newInitialValues are swapped in interface. If the interface is used to call initialisePoolRuleIntermediateValues function then new initial intermediate values will take the place of the new moving averages and/or vice-versa. In that case, protocol could face...

1. Market manipulation

2. Impermanent loss

3. LPs losses their funds

4. Protocol losses its reputation

5. Denial of Service (DoS)

6. Attacker could trick arbitrage opportunities, etc.

Tools Used

Manual review

Recommendations

To resolve the parameter mismatch and prevent issues with interface compliance and incorrect initialization logic, follow these steps:

1. Align the Parameter Order:
   Ensure that the parameter order in the initialisePoolRuleIntermediateValues function in the UpdateRule contract matches the order defined in the IUpdateRule interface. Specifically:

   • _newIntermediateValues should map to the second parameter in both the interface and implementation.

   • _newParameters should map to the third parameter in both the interface and implementation.

2. Update the Interface:
   If the current parameter naming and order in the implementation are correct, update the IUpdateRule interface to reflect the actual intended order and parameter names. For example:

   function initialisePoolRuleIntermediateValues(

   address _poolAddress,

   int256[] memory _newMovingAverages,

   int256[] memory _newInitialValues,

   uint256 _numberOfAssets

   ) external;

3. Update Function Calls:
   Check all locations where initialisePoolRuleIntermediateValues is called. Ensure that the arguments are passed in the correct order, according to the updated interface and implementation.

4. Document Changes:
   Update the documentation to reflect the corrected function signature and its intended use. Clearly define the expected order and purpose of each parameter to prevent confusion in future updates.

Please update the interface as updated below...

By implementing these recommendations, you can eliminate the risk of initialization errors, ensure proper interface compliance, and maintain the stability and reliability of the protocol.