What is the alternative for `upgradeTo()` function in Transparent Upgradeable Proxy?

Support Upgrades
, , ,
1

I've been using the transparent upgradeable proxy for a long time. The version before 5.0 contained
two function called upgradeTo and upgradeToAndCall which was was easy to use as I don't wanna initialize the proxy everytime I upgrade.

The new version doesn't seem to have the upgradeTo function, it only contains upgradeToAndCall , what is the work around? If I send empty data e.g. 0x00, will it work like upgradeTo?

Old version with upgradeTo - TransparentUpgradeableProxy.sol 4.9

New version without upgradeTo - TransparentUpgradeableProxy.sol 5.0

2

Yes, as described in v5.0.0-rc.0 release notes:

  • UUPSUpgradeable, TransparentUpgradeableProxy and ProxyAdmin: Removed upgradeTo and upgrade functions, and made upgradeToAndCall and upgradeAndCall ignore the data argument if it is empty. It is no longer possible to invoke the receive function (or send value with empty data) along with an upgrade. (#4382)
1 Like
3

Hey, thanks for the reply.

The transaction is still not going through. Attaching the ss below.

image
image990×442 10.2 KB

I have matched the owner and caller address, no problem seems to be there.
I might be doing something wrong.

4

Try replacing 0x0 with "".

And regardless, keep in mind that only the proxy-admin account can execute this transaction.

5

That's not the correct format:

image
image701×120 2.54 KB

Yes, I am calling with the owner account itself.

I also tried to run a simulation, seems like it is calling the given data in the implementation. because 0x577a342e99b0064ea759ca22e5630a6da20c6c5c is the current implementation contract.

image
image1440×542 78.5 KB

Any help is appreciated @frangio (˘･_･˘)

6

Note: Please post addresses and error message text instead of just screenshots.

From your transaction here, the data parameter does not look like zeroes. Try 0x

1 Like
7

Hey, thanks for the reply.

Here is a tx I tried with 0x - 0xf9c6f5400453b80fae425b9b8505167e061414148ab98f0c325f959fa252c7c3

Also I can't seem to find any exact error, even in tenderly the error is not clear, it just seems that the current implementation contract got called and it failed.

8

Finally found the problem.

In the previous versions, we had to deploy the proxyAdmin and pass it's address in the proxy constructor, but in V5 the proxy deploys it's own admin. It also makes the passed admin address the owner of new admin contract.

So basically when I used the old method with the new contract, my Proxy's admin was the admin contract that it deployed, and the other admin contract I deployed became the owner of this admin contract. Resulting in this mess.

9

If this is accurate, then the release-note which I have pointed out earlier in this thread is incomplete.

1 Like
10

Yeah, it was only mentioned in the PR

I realised this when a dev answered my question on stack exchange - Here

11

Thanks for the feedback here, we'll plan to improve the docs to help point out these differences.

1 Like