To avoid storage conflicts or unreadable code after future upgrades of upgradeable contracts, the safest solution is to add storage gaps.
Quoting OpenZeppelin: "It isn’t safe to simply add a state variable because it "shifts down" all of the state variables below in the inheritance chain. This makes the storage layouts incompatible, as explained in Writing Upgradeable Contracts. The size of the __gap array is calculated so that the amount of storage used by a contract always adds up to the same number (in this case 50 storage slots)."
This holds for wfCashLogic, wfCashBase, wfCashERC4626.
[Low - 01] - Use storage gaps for future upgrades
To avoid storage conflicts or unreadable code after future upgrades of upgradeable contracts, the safest solution is to add storage gaps.
Quoting OpenZeppelin: "It isn’t safe to simply add a state variable because it "shifts down" all of the state variables below in the inheritance chain. This makes the storage layouts incompatible, as explained in Writing Upgradeable Contracts. The size of the __gap array is calculated so that the amount of storage used by a contract always adds up to the same number (in this case 50 storage slots)."
This holds for
wfCashLogic
,wfCashBase
,wfCashERC4626
.For reference: https://docs.openzeppelin.com/contracts/3.x/upgradeable