How to verify proxy deployed from Remix

Hi i was able to create and deploy my implementation contract and proxy contract but was only able to verify the implementation and not the proxy. I dont see the files i need to flatten for the proxy. @ericglau

I might need an actual team member to verify this for me. Please

See the "Upgradeable Contracts and Proxies" section in How to verify a contract on Etherscan/BscScan/PolygonScan

This doesnt help please look into my contract.

Offers to pay for help must be restricted to the category #smart-contracts:developer-wanted.

We believe all of the information necessary is present in How to verify a contract on Etherscan/BscScan/PolygonScan.

If you're unable to follow those instructions please provide specifics about what you did and how it failed, otherwise we will not be able to help.

I used the openzepplin wizard and chose all functions with Upgradability UUPS. Then i used the remix to deploy the .sol file and ended up with one contract and one proxy contract when looking at the bottom left corner of deployed contracts. I then go to etherscan and look up the first contract the implementation contract and try to verify the contract. I use the remix flattener tool on the only file i had to compile with and copied the flattened code into etherscan verification and leaving the abi section blank then clicking verify and it got verified. But for the proxy i try to use the same code and it fails. Im not sure if using the same flattened code is right for the proxy. Though i dont see any proxy .sol file version of the contract in remix for me to flatten. I really would appreciate if you look into the contract for me.

So i believe i need to flatten the source code of the proxy version that i dont see in remix.

@frangio

Thank you for providing those details. This proxy contract was deployed by Remix using precompiled bytecode. I've contacted Remix to see if they can provide the compiler details that were used.

1 Like

Thank you , i look forward to your update

@ericglau if i may ask, what do you mean by pre compiled bytecode?

By precompiled bytecode, I mean Remix deploys the proxy contract from a bytecode string. This bytecode was previously compiled at some point in time, and the compiler settings that were used could be different than what you have in your Remix workspace. So we'd need these settings from the Remix team in order to verify the proxy on Etherscan.

For example, you can see that the bytecode string in the link above matches with the beginning of the Input Data field of your contract's creation at https://etherscan.io/tx/0x6c96ff2ce5deca979754699f9ac8dc76f82b71f665bfcf54d3335f353a3c6951.

Wow this is really good to know. I hope they can get back to you ASAP. @ericglau

I have a whole team of developers waiting @ericglau @frangio i really hope remix can get back to you ASAP. I wish remix would have generated the compiler details for the proxy upon deploying and saved it to my workplace.

Hi @blocky, thanks for your patience with this. We got a response from Remix that they did not have that information saved previously, but they now have it available on Remix-alpha (which is yet to go live).

Can you use remix-alpha.ethereum.org to deploy your contract and proxy?

After you deploy the new proxy, you will be able to verify it on Etherscan with the following details:

Proxy contract: ERC1967Proxy from OpenZeppelin Contracts 4.8.0 https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v4.8.0/contracts/proxy/ERC1967/ERC1967Proxy.sol

Solidity Version: 0.8.7 https://github.com/ethereum/remix-project/blob/master/libs/remix-core-plugin/src/lib/constants/uups.ts#L6

For other compiler settings see https://github.com/ethereum/remix-project/blob/8dd32709a4482efed5356e80bda9e622a15b455d/libs/remix-core-plugin/src/lib/compiler-fetch-and-compile.ts#L53

The evmVersion uses the default supported by the solidity compiler version.

The constructor arguments are everything after the UUPSBytecode's bytes in the Input Data field of the contract creation transaction on Etherscan.

You can flatten the proxy by doing this:

  1. Create a proxy.sol contract that has only this:
import "https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v4.8.0/contracts/proxy/ERC1967/ERC1967Proxy.sol";
  1. Navigate the Remix file explorer to .deps/github/OpenZeppelin/openzeppelin-contracts/contracts/proxy/ERC1967/ERC1967Proxy.sol to view the ERC1967Proxy contract
  2. In the Flattener plugin for Remix, click "Flatten .deps/github/OpenZeppelin/openzeppelin-contracts/contracts/proxy/ERC1967/ERC1967Proxy.sol"
  3. Then paste the flattened source from clipboard into Etherscan when verifying that proxy

With the above steps, I was able to verify a new proxy on a testnet to look like this.

So do i have to make a whole duplicate contract with the same info to deploy on ethereum mainnet? Or can i verify my current proxy contract? @ericglau

So i can just flatten this and verify my current proxy ? @ericglau

// SPDX-License-Identifier: MIT
Pragma solidity ^0.8.0;

import "https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v4.8.0/contracts/proxy/ERC1967/ERC1967Proxy.sol";

Or i strictly need to deploy using the alpha remix for it to work ?

I have no problem making a new one but now i have two of the same name on the blockchain.

So i can just flatten this and verify my current proxy ?

That's just a way to get the ERC1967Proxy contract to be imported into Remix's dependencies. It would be more proper to flatten the actual ERC1967Proxy.

You would need to deploy a new one using Remix alpha because its proxy bytecode is different (due to the new compilation settings that were used).

I tried and still cant do it i flattened the file and paste it to the testnet and the proxy sais cant find bytecode. I used the remix alpha to deploy to testnet. Im not sure exactly what to put in abi encoded. @ericglau

Abi encoded constructor arguments for your proxy should be

00000000000000000000000032f9e5e9573e8601539b733d7550d893e02ff68a000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000048129fc1c00000000000000000000000000000000000000000000000000000000

Let me know if you'd like me to verify it for you (as long as you are fine with the format seen in the previous example).

I was able to verify the testnet proxy with that bytecode but not the mainnet that i just deployed again using the alpha remix. Is it a different bytecode ? @ericglau

The abi encoded constructor args for your mainnet proxy is

000000000000000000000000955850b077aa8e6e7591987beb140204624da1c5000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000048129fc1c00000000000000000000000000000000000000000000000000000000

Finally worked thank you.