DeFiFoundry
60,000 USDC
View results
Submission Details
Severity: low
Valid

Domains Storage Location Doesn't Follow ERC7201

[L-01] Domains Storage Location Doesn't Follow ERC7201

Vulnerability Details

As stated in the documentation, the tree-proxy pattern is meant to be ERC7201 compatible. However, when assigning storage keys for domains in the CustomReferralConfiguration, Referral, Points, and ReferralTestnet contracts, the defined key doesn't follow the ERC7201 formula.

Example formula for EIP-7201:
keccak256(abi.encode(uint256(keccak256("example.main")) - 1)) & ~bytes32(uint256(0xff));

The formula used by the four mentioned contracts:

library CustomReferralConfiguration {
@> string internal constant CUSTOM_REFERRAL_CONFIGURATION_DOMAIN = "fi.zaros.CustomReferralConfiguration";
struct Data {
address referrer;
}
function load(string memory customReferralCode)
internal
pure
returns (Data storage customReferralConfigurationTestnet)
{
@> bytes32 slot = keccak256(abi.encode(CUSTOM_REFERRAL_CONFIGURATION_DOMAIN, customReferralCode));
assembly {
customReferralConfigurationTestnet.slot := slot
}
}
}

Impact

Though it may not cause immediate problems, since the two important characteristics of the ERC7201 formula are not used (keccak256(id) - 1) to ensure the location is not used by Solidity and performing AND NOT with ~0xff ensures that the storage slot's rightmost byte is 00, it may cause storage collision in later updates.

Tools Used

Manual Review

Recommendations

Use the proposed formula by EIP-7201. For example:

keccak256(abi.encode(uint256(keccak256("fi.zaros.perpetuals.Referral")) - 1)) & ~bytes32(uint256(0xff));
Updates

Lead Judging Commences

inallhonesty Lead Judge over 1 year ago
Submission Judgement Published
Validated
Assigned finding tags:

Storage computation formula of ERC7201 is not followed. ERC7201 non compliance.

Support

FAQs

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

Give us feedback!