PermissionHash Manual Review Findings

PHH-01M: Unsupported Pragma Version Specification

Type	Severity	Location
Language Specific		PermissionHash.sol:L2

Description:

The overall codebase of the NFTPermissions system makes use of user-defined value types that were introduced in Solidity 0.8.8, however, the pragma statements of the code indicate support for versions of 0.8.0 and up which is incorrect.

Example:

Copy
2pragma solidity >=0.8.0;

Recommendation:

We advise the pragma versions to be corrected, either locked to the actual version in use by the codebase (=0.8.20) or updated to a more accurate range (>=0.8.8).

Alleviation:

All pragma versions throughout the codebase including the referenced one have been updated to mandate a Solidity version of 0.8.8 and higher, addressing this exhibit.

PHH-02M: Non-Compliant EIP-712 Typehash Definition

Type	Severity	Location
Standard Conformity		PermissionHash.sol:L15

Description:

Based on the EIP-712 definition and in particular the way an encodeType should be structured, the PERMISSION_PERMIT_TYPEHASH value is non-compliant with the standard.

In detail, the PERMISSION_PERMIT_TYPEHASH value should define the PermissionPermit, PositionPermissions, and PermissionSet in that exact sequence as each references the next and should be appended in order.

Impact:

This exhibit would normally be of higher severity, however, the non-compliant EIP-712 typehash is utilized internally within the project and as such construction of it can be performed "incorrectly" by the Mean Finance team.

Example:

Copy
13bytes32 public constant PERMISSION_PERMIT_TYPEHASH = keccak256(
14  // solhint-disable-next-line max-line-length
15  "PermissionPermit(PositionPermissions[] positions,uint256 nonce,uint256 deadline)PermissionSet(address operator,uint8[] permissions)PositionPermissions(uint256 positionId,PermissionSet[] permissionSets)"
16);

Recommendation:

We advise the type-hash to be corrected in order to ensure full compliancy with the EIP-712 standard.

Alleviation:

After extensive discussions with the Mean Finance team, we have deduced that this particular exhibit pertains to a slightly ambiguous case of the EIP-712 standard.

In detail, the standard does not clearly specify what the order of declaration should be when multiple types inherit from others and additionally, online information in relation to it tends to indicate that the types should be in alphabetical order beyond the first.

We attempted to contact the original EIP authors but have not garnered a response and as such will consider this exhibit as nullified given that the type-hashes current representation appears to align with what the "correct" representation is.