Calls to Implementation Functions via a TransparentUpgradeableProxy

It is mentioned at this link (regarding the TransparentUpgradeableProxy), that "If the admin calls the proxy, it can access the admin functions, but its calls will never be forwarded to the implementation."

I have deployed such a TransparentUpgradeableProxy contract, however, I am able to call the withdrawfunds(), pause() and unpause() functions on my implementation smart contract using the admin account that was used to deploy the contract.

Am I not understanding something properly?

Thank you. J


If you use the TransparentUpgradeableProxy, just like the documentation explained:

This contract uses the transparent proxy pattern. This pattern implies two things that go hand in hand:

  1. If any account other than the admin calls the proxy, the call will be forwarded to the implementation, even if that call matches one of the admin functions exposed by the proxy itself.
  2. If the admin calls the proxy, it can access the admin functions, but its calls will never be forwarded to the implementation. If the admin tries to call a function on the implementation it will fail with an error that says "admin cannot fallback to proxy target".

So how did you deploy your contracts?

Thank you @Skyge Yes, this is the text I was referring to. I have deployed my contracts using the procedure documented at this link, as specified in the section "Deploy the contract to a public network". Thus, creating a 2_deploy_MyContract.js file, and then running the truffle migrate command. A TransparentUpgradeableProxy was created and its address was included in my Dapp, and everything appears to be working properly. However, I am able to call some functions from my implementation contract with the account that was used for deploying the contract, and thus the admin. Also, please note that the functions I am referring to all have the "onlyOwner" modifier, which confirms that I am using the account corresponding to the onlyOwner/admin/deployer.

When you use the Upgrades Plugins to deploy transparent proxies, the plugin also deploys a ProxyAdmin contract for you that acts as the "real" admin of the proxies. Your deployer account gets the privileges to the ProxyAdmin contract that allow it to use it for upgrades and so on. This is why your deployer account can access the proxy's functionality.

Thank you @frangio However, upon deployment, I am obtaining only the following outputs:

1_initial_migration.js
2_MyContract.js
3_deploy_MyContract.js
Deploying 'TransparentUpgradeableProxy'
Total deployments: 4

But nothing regarding the ProxyAdmin. I thought I had read that the ProxyAdmin was deployed only when deploying a UUPS Proxy and not a Transparent one. Isn't this the case? If a ProxyAdmin is created, where can I obtain its address?

The information found at this link do not state that a ProxyAdmin is systematically created when creating a TransparentUpgradeableProxy. Not sure if I am missing something.

Thank you again. J

Sorry about the confusion.

It's the other way around.

Because this page is describing the proxy contracts. ProxyAdmin is not inherently a part of the transparent proxy, but it's a recommendation, and it's how our Upgrades Plugins will deploy it.

In the migration output you may not be seeing ProxyAdmin because you may already have one in this network. If you open the network file in the .openzeppelin directory, you will find at the end an "admin" section with an address. You can also obtain the address by using the admin module of the plugin.

const { admin } = require('@openzeppelin/truffle-upgrades');
admin.getInstance().then(a => console.log(a.address));

Thank you for the clarification @frangio I have found the admin address in the file you have referenced. Just to confirm, although there is now an AdminProxy that I can use for managing the Proxy contract, the address having deployed the contract should still be the owner and should be able to interact (as the owner) with the implementation contract, right? Just want to confirm that I have not done something wrong.

Thanks. J

If you mean "owner" in the sense of Ownable, yes your deployer account will be the owner of your contract.