Issue with Transparent Proxy Upgrades

Hello

I recently deployed an upgradeable contract using OpenZeppelin's TransparentUpgradeableProxy pattern, but I am encountering unexpected behavior after the upgrade. Initially, the proxy pointed to the implementation contract correctly, and all functions worked as intended. However, after deploying a new implementation and performing the upgrade, certain functions now produce inconsistent results or fail altogether. :upside_down_face:

The upgrade process was executed using the OpenZeppelin Upgrades plugin with Hardhat. The deployment and upgrade transactions were successful with no apparent errors. I double-checked the ABI, function signatures, and storage variables in both the old and new implementations to ensure no changes would cause storage slot misalignment.

Despite this, the new implementation exhibits unexpected side effects, such as corrupted state variables or reversion of specific function calls.

Could this issue stem from a subtle misalignment of storage slots, or is there a possible configuration issue in my proxy or upgrade process? :thinking: I have checked https://docs.openzeppelin.com/contracts/5.x/api/proxy MLOps guide for reference .

I would appreciate guidance on best practices for ensuring smooth upgrades, debugging storage issues, and any tools within the OpenZeppelin ecosystem that can help verify contract compatibility during upgrades. :slightly_smiling_face:

Thank you ! :slightly_smiling_face:

Sounds like the slot conflicts, but if you use the hardhat upgrade plugin, I think it has some checks for this, or maybe you can do these checks manually: validateImplementation, validateUpgrade

If possible, you can share the contract and scripts at here, so we can find more.

1 Like