Verifying TransparentUpgradeableProxy v 4.5 on Ethereum mainnet

I have deployed new contract using TransparentUpgradeableProxy to mainnet
and here is the address of proxy
implementation address (verified on etherscan)

the issue is the proxy was not verified
I know it is verified in all networks but I tried to verify it using truffle plugin and it told it is already verified but it is not

openzeppelin contracts versions
"@openzeppelin/contracts": "^4.5.0",
"@openzeppelin/contracts-upgradeable": "^4.5.2",

Can you double check that the network mainnet is configure with the right address?

@JulissaDantes thanks for your reply,
I don't get your question, the contracts have been deployed to mainnet and I posted the addresses above 0x6f2bF9922079F07c18Dc6184dA0A1780f047575c, I successfully verified the implementation contract but the proxy contract is not verified however I deployed the proxy contract again (TransparentUpgradeableProxy ) using Openzeppelin version 3 and it is verified as usual , so seems the newest ones not verified yet in etherscan?
this is the new deploy I did for proxy and it is verified

@amr_shaban Are you using OpenZeppelin Upgrades Plugins to deploy the proxy? If so, can you please provide the exact versions of the plugins that you used? (For example, you can run npm list)

@ericglau no I deployed the TransparentUpgradeableProxy by truffle using this version
"@openzeppelin/contracts": "^3.4.1", for contract version

await deployer.deploy(TransparentUpgradeableProxy ,implementation address, proxyAdmin, []);

The problem in your original post sounds like it could be an issue with the truffle verify plugin or with Etherscan.

For further deployments, I'd suggest using OpenZeppelin's truffle upgrades plugin to deploy your upgradeable contracts instead of deploying the proxy directly. The upgrades plugin does a number of checks to ensure that your implementation is upgrade safe, and helps to deploy all relevant contracts (implementation, admin, proxy).

Since you already have some deployments, you can import them using forceImport, and then use the truffle upgrades plugin to upgrade your implementations later on.

Another benefit of using the truffle upgrades plugin is that the proxy contract bytecode will look the same as other verified proxy contracts on the same network, so Etherscan can give a Similar Match Source Code similar to what you see for 0x30dab5e3D27f28b2619374E96215548c760ad0E7

thank you for your answer , I will do that next time but I have a question regarding truffle upgrades plugin
how can I pass the proxy admin to it as I have already proxy admin deployed in mainnet
and as I see here , don't know how to pass it

const { deployProxy } = require('@openzeppelin/truffle-upgrades');

const Box = artifacts.require('Box');

module.exports = async function (deployer) {
  const instance = await deployProxy(Box, [42], { deployer });
  console.log('Deployed', instance.address);

You should use the forceImport command to import a proxy that you have previously deployed. That will import the proxy along with its existing admin and implementation.

@ericglau thanks ,
understand but I asked if I deploy a new proxy with this plugin and I have already proxy admin contract deployed in mainnet before , and I want to use that proxy admin for the new proxy , so how I set the proxy admin here when deploy a new proxy , I didn't see any thing in common option related
const instance = await deployProxy(Box, [42], { deployer });

@amr_shaban, there are two points to consider here:

  1. The plugin only keeps track of one proxy admin contract.
    • If it does not have a record of any proxy admin contract, it will deploy a new one when you deploy a transparent proxy.
    • If it does have a record of a proxy admin contract (that was previously deployed or previously imported), it will reuse that proxy admin contract for any new deployments of transparent proxies.
  2. The plugin currently does not support specifying an existing proxy admin address when deploying a proxy.

Therefore, I suggest to import an existing proxy first, which will cause its admin to be imported as well. Then for new proxy deployments, it will reuse that existing admin.

1 Like