CrossChainRebaseTokenUpgradeable Code Style Findings

CCR-01C: Redundant Representation of Literal Constant

Type	Severity	Location
Code Style		CrossChainRebaseTokenUpgradeable.sol:L32

Description:

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

Example:

Copy
30// keccak256(abi.encode(uint256(keccak256("tangible.storage.CrossChainRebaseToken")) - 1)) & ~bytes32(uint256(0xff))
31bytes32 private constant CrossChainRebaseTokenStorageLocation =
32    0xdc2fee72b887a559c0d0f7379919bb4c097013a85e230aa333d867a22945b500;

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.