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

Inconsistency between interface and implementation of `initialisePoolRuleIntermediateValues` creates confusion about parameter usage

goran

Summary

There is a mismatch between the interface definition and implementation of initialisePoolRuleIntermediateValues function. The interface and implementation use different parameter names and descriptions, which could lead to confusion and potential misuse in external integrations.

Vulnerability Details

Even though all function parameters use same type in interface and in implementation (otherwise it wouldn't compile), there is a mismatch in the semantics of 2nd and 3rd parameter.

Function definition in IUpdateRule.sol interface:

/// @notice Called on pool creation to preset all the neccessary rule state
/// @param _poolAddress address of pool being initialised
/// @param _newIntermediateValues array of initial intermediate values values
/// @param _newParameters array of initial parameters, dynamic to allow flexibility for future rules
/// @param _numberOfAssets number of assets in the pool
function initialisePoolRuleIntermediateValues(
address _poolAddress,
int256[] memory _newIntermediateValues,
int256[] memory _newParameters,
uint _numberOfAssets
) external;

In UpdateRule.sol implementation:

/// @param _poolAddress address of pool being initialised
/// @param _newMovingAverages the initial moving averages to be saved
/// @param _newInitialValues the initial intermediate values to be saved
/// @param _numberOfAssets the number of assets in the pool
/// @notice top level initialisation function to be called during pool registration
function initialisePoolRuleIntermediateValues(
address _poolAddress,
int256[] memory _newMovingAverages,
int256[] memory _newInitialValues,
uint256 _numberOfAssets
) external {
...
}

Name and description, thus the semantics, of 2nd and 3rd parameter are completely different. Looking at body of initialisePoolRuleIntermediateValues implementation it's clear that implemenation's semantics are correct and it is the interface that is out-of-date.

Impact

Low severity because:

  1. Creates confusion about correct parameter usage

  2. Could lead to incorrect values being passed by callers causing failures in integration

  3. Makes code harder to maintain and audit

  4. However, actual functionality still works correctly if used properly

Tools Used

Manual review

Recommendations

Update the interface to match the implementation and provide clearer documentation.

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.