You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The idea here is that using EIP-7201 should be the recommended best-practice way of managing contract storage of upgradeable contracts. We can push best practice by flagging a finding on upgradeable contracts that store variables in the storage slots at the beginning of the contract (ex: variables listed in slither --print variable-order)
Upgradeable contracts can be vaguely identified by the presence of an initialize() function. This would limit false positives to factory-deployed contracts, confidence medium.
We can get better results by checking for inheritance of OZ's UUPSUpgradeable or similar contracts, confidence high.
Severity medium imo, but open to thoughts
The text was updated successfully, but these errors were encountered:
Describe the desired feature
The idea here is that using EIP-7201 should be the recommended best-practice way of managing contract storage of upgradeable contracts. We can push best practice by flagging a finding on upgradeable contracts that store variables in the storage slots at the beginning of the contract (ex: variables listed in
slither --print variable-order
)Upgradeable contracts can be vaguely identified by the presence of an initialize() function. This would limit false positives to factory-deployed contracts, confidence medium.
We can get better results by checking for inheritance of OZ's UUPSUpgradeable or similar contracts, confidence high.
Severity medium imo, but open to thoughts
The text was updated successfully, but these errors were encountered: