QuantAMM

Summary

The _quantAMMUnpack128Matrix function in the VectorRuleQuantAMMStorage contract contains redundant memory reallocations within its nested loops. Specifically, the code lines targetArray[targetRow] = new int256[](); at lines 465 and 480 reallocate memory that has already been allocated during the initial setup of the targetArray at lines 437-443. This results in unnecessary gas consumption during the unpacking process. While not a security vulnerability, this redundancy represents a gas optimization issue that should be addressed.

Vulnerability Details

The vulnerability lies within the _quantAMMUnpack128Matrix function of the VectorRuleQuantAMMStorage contract. The function's purpose is to unpack a compressed representation of a matrix stored in _sourceArray into a 2D array targetArray.The initial setup of targetArray correctly allocates the necessary memory using nested loops to create a matrix of dimensions _numberOfAssets x _numberOfAssets, as to QuantAMMStorage.sol#L437-443:

However, during the subsequent unpacking process, where the code iterates through the _sourceArray to populate targetArray, redundant memory reallocations occur. Specifically, within the nested if conditions, the lines targetArray[targetRow] = new int256[](); in QuantAMMStorage.sol#L465:

and QuantAMMStorage.sol#L480:

are executed. These lines reallocate memory for targetArray[targetRow] in each iteration, even though the memory for these rows was already allocated during the initial setup. Since the loop structure and the conditional checks ensure that targetRow and targetIndex always stay within the bounds of the initially allocated targetArray, these reallocations are unnecessary and serve no functional purpose. They represent redundant operations that waste gas each time they are executed. The rest of the unpacking logic within the function is correct, properly extracting values from _sourceArray and placing them into the appropriate positions in targetArray. However, the redundant reallocations diminish the overall efficiency of the unpacking process.

Impact

The impact of this vulnerability is low in terms of security but represents a tangible gas optimization issue. The redundant memory reallocations do not introduce any security flaws, such as out-of-bounds memory access or data corruption. The functionality of the _quantAMMUnpack128Matrix function remains correct, and the unpacked matrix is accurately reconstructed.

However, each execution of the new int256[](_numberOfAssets) statement consumes gas. While the previously allocated memory is likely subject to garbage collection, the immediate cost of these unnecessary allocations remains. This leads to higher gas consumption for any operation that utilizes the _quantAMMUnpack128Matrix function.

The overall impact can be summarized as follows:

• No direct security implications. The vulnerability does not compromise the integrity or confidentiality of the data.

• Increased gas costs. The unnecessary reallocations lead to higher gas consumption for transactions involving the affected function.

• Reduced efficiency. The redundant operations slightly reduce the overall efficiency of the contract.

This issue should be classified as a gas optimization finding, as it primarily affects the cost of interacting with the contract rather than its security.

Tools Used

Manual Review

Recommendations

The recommended mitigation for this issue is straightforward: remove the redundant memory allocation statements within the _quantAMMUnpack128Matrix function. Specifically, the lines targetArray[targetRow] = new int256[](); at lines 465 and 480 of QuantAMMStorage.sol should be deleted.

The corrected code snippets should look like this:

Corrected code at line 465:

Corrected code at line 480:

By removing these lines, the function will rely on the initial allocation of targetArray, which is sufficient and correctly sized. This eliminates the unnecessary gas consumption associated with the repeated reallocations. This change does not affect the logic or functionality of the unpacking process, as the loop structure and bounds checking ensure that memory access remains within the originally allocated bounds.