Is this a valid case for "unsafeSkipStorageCheck"?


We've been running some upgrades to contracts on Mainnet using the OZ plugin successfully, and the storage gap validations have always worked so far.

But based on an audit we had, they suggested standardizing our contracts (the child contracts which are not inherited) to 50 slots total. This means we had to adjust the __gap size for some of these contracts manually, which causes the validations now to fail.

My question is, considering these are "child" contracts only, they do not have anything underneath, I would assume decreasing the _gap variable at the end is safe like the auditors suggest.

Is this a good case for using the unsafeSkipStorageCheck flag for the NEXT deployment to be able to bypass the plugin? Then my idea is to remove the flag again and keep back validation storage in future upgrades.

Let me know if this is OK. Thanks!

1 Like

This sounds reasonable to me, as long as:

  • the gap size errors were the only errors
  • you are sure there is no storage being used after the gaps
  • you are sure nothing is inheriting those child contracts

The last part is relevant for the future as well, because in a way it is a "breaking change". For example (and this really depends on use case), if you changed the gap sizes from V1 to V2, then if you later add other contracts that inherit them, layouts would be different depending on whether they inherit from V1 or V2 code.

1 Like