OFTCoreUpgradeable Code Style Findings

OFC-01C: Redundant Representation of Literal Constant

Type	Severity	Location
Code Style		OFTCoreUpgradeable.sol:L42

Description:

The OFTCoreStorageLocation variable is declared as a bytes32 literal instead of utilizing its commented-out representation.

Example:

Copy
41// keccak256(abi.encode(uint256(keccak256("layerzero.storage.OFTCore")) - 1)) & ~bytes32(uint256(0xff))
42bytes32 private constant OFTCoreStorageLocation = 0x822492242235517548c4a8cf040400e3c0daf5b82af652ed16dce4fa3ae72800;

Recommendation:

We advise the commented-out representation to replace the value literal, ensuring that the value can be easily maintained while ensuring that no external verification of equivalence must be performed.

To note, it is possible to perform literal-based calculations in constant declarations and keccak256 evaluations of string values are correctly evaluated during compile-time.

Alleviation (47fbf62bbbf2409ff0baf9a18a2945466cb2a576):

The Tangible team has specified that the representation they currently utilize is aligned with best-practices as established by the likes of OpenZeppelin.

The OpenZeppelin standard adheres to the EIP-7201 specification and as such, we advised the codebase of the Tangible team to also align with the standard by introducing the relevant custom annotations described within it to the struct entries of the codebase.

The Tangible team evaluated our recommendation and opted to not introduce the notation as they wish to utilize external toolkits to evaluate each storage slot's validity.

To this end, we consider this exhibit safely acknowledged as the Tangible team has been informed of the relevant standards and has made an informed decision to retain the codebase as is.