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

Hardcoded Version String in Pool Creation Breaks Cross-System Compatibility and Version Management

cheatc0d33

Summary

The QuantAMMWeightedPool factory implements IPoolVersion, which specifies that pool version information should contain "name, version number and task ID" in JSON format. However, the current implementation fails to fulfill this interface contract by passing a hardcoded "version" string during pool creation:

https://github.com/Cyfrin/2024-12-quantamm/blob/main/pkg/pool-quantamm/contracts/QuantAMMWeightedPoolFactory.sol#L96

QuantAMMWeightedPool.NewPoolParams({
// ...
version: "version", // Violates IPoolVersion specification
// ...
})

This implementation not only ignores the _poolVersion state variable but also violates the interface's explicit requirement for structured version information. According to the interface, _poolVersion should contain JSON-formatted data with specific fields, but pools are being created with a non-conformant simple string.

The impact is more severe than just version mismatch - it breaks interoperability with subsystems that expect valid JSON version data as specified in the interface documentation. The interface comment explicitly states this is "useful in complex Pool deployment schemes, where multiple subsystems need to know about each other", indicating this version information is critical for cross-system coordination.

Recommended Mitigation Steps

First, ensure _poolVersion contains properly formatted JSON data during factory construction:

constructor(
IVault vault,
uint32 pauseWindowDuration,
string memory factoryVersion,
string memory poolVersion,
address updateWeightRunner
) {
require(
isValidJsonVersion(poolVersion),
"Pool version must be valid JSON with name, version number and task ID"
);
_poolVersion = poolVersion;
// ... rest of constructor
}

Then use this validated version data during pool creation:

QuantAMMWeightedPool.NewPoolParams({
name: params.name,
symbol: params.symbol,
numTokens: params.normalizedWeights.length,
version: _poolVersion, // Now contains proper JSON version data
updateWeightRunner: _updateWeightRunner,
poolRegistry: params.poolRegistry,
poolDetails: params.poolDetails
})

Consider adding a helper function to validate JSON version format:

function isValidJsonVersion(string memory version) internal pure returns (bool) {
bytes memory versionBytes = bytes(version);
// Check minimum length for a valid JSON with required fields
// {"name":"","version":"","taskId":""} = minimum 32 chars
if (versionBytes.length < 32) return false;
// Check JSON object brackets
if (versionBytes[0] != '{' || versionBytes[versionBytes.length - 1] != '}')
return false;
// Required fields to check
bool hasName = false;
bool hasVersion = false;
bool hasTaskId = false;
// Convert to memory for cheaper access
string memory versionStr = string(versionBytes);
// Check for required fields
// Note: This is a basic check that could be bypassed with malformed JSON,
// but provides reasonable validation for proper JSON input
hasName = _containsField(versionStr, "name");
hasVersion = _containsField(versionStr, "version");
hasTaskId = _containsField(versionStr, "taskId");
return hasName && hasVersion && hasTaskId;
}
​
function _containsField(string memory json, string memory field) internal pure returns (bool) {
// Look for "field": pattern
bytes memory pattern = abi.encodePacked('"', field, '"');
bytes memory jsonBytes = bytes(json);
bytes memory searchBytes = pattern;
// Basic substring search
if (jsonBytes.length < searchBytes.length) return false;
for (uint i = 0; i <= jsonBytes.length - searchBytes.length; i++) {
bool found = true;
for (uint j = 0; j < searchBytes.length; j++) {
if (jsonBytes[i + j] != searchBytes[j]) {
found = false;
break;
}
}
if (found) return true;
}
return false;
}

This ensures compliance with the IPoolVersion interface specification and maintains proper version information flow through the protocol's subsystems.

Updates

Lead Judging Commences

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

invalid_hardcoded_version

Version is immutable as specified in Version.sol and can be what the developer wants. It is hardcoded and will be changed by the admin for every deployment. No real impact here.

Support

FAQs

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