Pre-auditThree days of senior audit time for $1,500, credited in full toward your Zealynx audit.3 audit days, credited toward your auditSee how →
L-29·

Incorrect `EIP-712` data hashing implementation

Not reportedoptionsleverageblack-scholes
TL;DR

The IvSignerRecovery.sol contract aims to use EIP-712 for verifying signatures related to option parameters (iv, strategy, maturityDate, relativeStrike) needed in the OperationalTreasury.buy() function.

Severity
LOW
Method
MManual review
CAT.

The IvSignerRecovery.sol contract aims to use EIP-712 for verifying signatures related to option parameters (iv, strategy, maturityDate, relativeStrike) needed in the OperationalTreasury.buy() function. However, the implementation of the structured data hashing within the _hash function deviates significantly from the EIP-712 standard.

The EIP-712 standard specifies that the hash of a structure (structHash) should be calculated as: hashStruct(s : 𝕊) = keccak256(typeHash ‖ encodeData(s)) Where:

  • typeHash is the keccak256 hash of the structure's type definition string.
  • encodeData(s) ABI-encodes the struct members, crucially encoding dynamic types like string and bytes as the keccak256 hash of their content.

The current _hash function calculates the hash as follows:

solidity
function _hash(uint256 iv, IStrategy strategy, uint256 maturityDate, uint256 relativeStrike)
internal
view
returns (bytes32)
{
(string memory uAsset, string memory oType) = _getAssetAndType(strategy);
// Incorrect hashing: Missing typeHash and incorrect string encoding
return keccak256(abi.encode(iv, uAsset, oType, maturityDate, relativeStrike));
}

This implementation has two critical flaws regarding the EIP-712 standard:

  1. Missing typeHash: It completely omits the typeHash component. The typeHash prevents signature collisions between different data structures.
  2. Incorrect Encoding of Dynamic Types: It uses abi.encode for the string variables uAsset and oType. EIP-712 requires dynamic types (string, bytes) within encodeData to be represented by the keccak256 hash of their byte content (i.e., keccak256(bytes(uAsset)) and keccak256(bytes(oType))).
  • High Risk of Signature Mismatch (DoS): If the off-chain signing service correctly implements the EIP-712 standard (calculating typeHash and hashing strings properly), the signatures generated off-chain will never match the hash calculated by the non-standard _hash function on-chain. This will cause all buy() transactions to fail signature verification, resulting in a Denial of Service for the core functionality of purchasing options.

Recommendations:

Refactor the _hash function to strictly adhere to the EIP-712 hashStruct specification.

  1. Define the TYPEHASH: Define the type string for the signed data structure and compute its keccak256 hash. This can be stored as a constant.

  2. Implement Correct encodeData: Modify the hashing logic to prepend the SIGNED_DATA_TYPEHASH and correctly encode the members according to EIP-712 rules (hashing dynamic types like string).

02Section · Report provenance

Report provenance

Published by Pashov Audit Group, with Carlos (Bloqarl) participating as a contractor. The source report states that its fixes review was not fully completed; no final remediation disposition is recorded for this finding. Read the full report.

L-29