Smart Contract Verification Failing
SauravKanchan opened this issue · comments
System information
Network: mainnet
Expected behaviour
I am using hardhat-verify plugin to verify my contracts on opbnb chain. All my contracts are on solidity 0.8.20 and it was successfully verified on other chains.
Actual behaviour
On opbnb hardhat-verify throws an error saying contract was compiled using 0.8.9
Steps to reproduce the behaviour
- Smart contract repo: https://github.com/arcana-network/sendit-sc
- RPC URL: Nodreal RPC and API is used
Backtrace
[0] % npx hardhat verify --network opBnb 0x8afB9D249bCc1E153109F36D2A1DC4570431F065
Error in plugin @nomiclabs/hardhat-etherscan: The contract you want to verify was compiled with solidity 0.8.9, but your configured compiler version is: 0.8.20.
Possible causes are:
- You are not in the same commit that was used to deploy the contract.
- Wrong compiler version selected in hardhat config.
- The given address is wrong.
- The selected network (opBnb) is wrong.
For more info run Hardhat with --show-stack-traces
The team is looking into it
Hello @SauravKanchan, it seems you are verifying a contract behind a proxy contract, is that correct? If you are interested, here are some related posts:
@SauravKanchan would you please provide the proxy address and the implementation address? That would be very helpful to locate the root cause.
address given above is the proxy contract address, I am using hardhart/upgrades to deploy the proxy contract.
Deployed a new contract now and tried to verify it, so proxy contract throws the above error and implementation contract throws different error(which may be solved by using a different plugin), but I want to verify proxy contract also
Sendit deployed to: 0x5e563D066162cB99A5c3237521aF82993EAd7FA6
Logic contract 0xc0F2A27f605a379D165046C1ABbd4e624E7d056d
(base)
saurav@Sauravs-MacBook-Pro ‹ main ●● › : ~/projects/sendit-sc
[0] % npx hardhat verify --network opBnb 0x5e563D066162cB99A5c3237521aF82993EAd7FA6
Error in plugin @nomiclabs/hardhat-etherscan: The contract you want to verify was compiled with solidity 0.8.9, but your configured compiler version is: 0.8.20.
Possible causes are:
- You are not in the same commit that was used to deploy the contract.
- Wrong compiler version selected in hardhat config.
- The given address is wrong.
- The selected network (opBnb) is wrong.
For more info run Hardhat with --show-stack-traces
(base)
saurav@Sauravs-MacBook-Pro ‹ main ●● › : ~/projects/sendit-sc
[1] % npx hardhat verify --network opBnb 0xc0F2A27f605a379D165046C1ABbd4e624E7d056d
Nothing to compile
No need to generate any newer typings.
Successfully submitted source code for contract
contracts/Sendit.sol:Sendit at 0xc0F2A27f605a379D165046C1ABbd4e624E7d056d
for verification on the block explorer. Waiting for verification result...
We tried verifying your contract Sendit without including any unrelated one, but it failed.
Trying again with the full solc input used to compile and deploy it.
This means that unrelated contracts may be displayed on Etherscan...
Successfully submitted source code for contract
contracts/Sendit.sol:Sendit at 0xc0F2A27f605a379D165046C1ABbd4e624E7d056d
for verification on the block explorer. Waiting for verification result...
Error in plugin @nomiclabs/hardhat-etherscan: The contract verification failed.
Reason: Fail - Unable to verify
For more info run Hardhat with --show-stack-traces
In the above logs 0x5e563D066162cB99A5c3237521aF82993EAd7FA6 is the proxy contract and 0xc0F2A27f605a379D165046C1ABbd4e624E7d056d is the implementation contract.
I fetch the contract bytecode via eth_getCode(0x8afB9D249bCc1E153109F36D2A1DC4570431F065), here is the result:
0x60806040523661001357610011610017565b005b6100115b61001f6101b7565b6001600160a01b0316336001600160a01b0316141561016f5760606001600160e01b031960003516631b2ce7f360e11b8114156100655761005e6101ea565b9150610167565b6001600160e01b0319811663278f794360e11b14156100865761005e610241565b6001600160e01b031981166308f2839760e41b14156100a75761005e610287565b6001600160e01b031981166303e1469160e61b14156100c85761005e6102b8565b6001600160e01b03198116635c60da1b60e01b14156100e95761005e6102f8565b60405162461bcd60e51b815260206004820152604260248201527f5472616e73706172656e745570677261646561626c6550726f78793a2061646d60448201527f696e2063616e6e6f742066616c6c6261636b20746f2070726f78792074617267606482015261195d60f21b608482015260a4015b60405180910390fd5b815160208301f35b61017761030c565b565b606061019e83836040518060600160405280602781526020016108576027913961031c565b9392505050565b90565b6001600160a01b03163b151590565b60007fb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d61035b546001600160a01b0316919050565b60606101f4610394565b600061020336600481846106a2565b81019061021091906106e8565b905061022d8160405180602001604052806000815250600061039f565b505060408051602081019091526000815290565b606060008061025336600481846106a2565b8101906102609190610719565b915091506102708282600161039f565b604051806020016040528060008152509250505090565b6060610291610394565b60006102a036600481846106a2565b8101906102ad91906106e8565b905061022d816103cb565b60606102c2610394565b60006102cc6101b7565b604080516001600160a01b03831660208201529192500160405160208183030381529060405291505090565b6060610302610394565b60006102cc610422565b610177610317610422565b610431565b6060600080856001600160a01b0316856040516103399190610807565b600060405180830381855af49150503d8060008114610374576040519150601f19603f3d011682016040523d82523d6000602084013e610379565b606091505b509150915061038a86838387610455565b9695505050505050565b341561017757600080fd5b6103a8836104d3565b6000825111806103b55750805b156103c6576103c48383610179565b505b505050565b7f7e644d79422f17c01e4894b5f4f588d331ebfa28653d42ae832dc59e38c9798f6103f46101b7565b604080516001600160a01b03928316815291841660208301520160405180910390a161041f81610513565b50565b600061042c6105bc565b905090565b3660008037600080366000845af43d6000803e808015610450573d6000f35b3d6000fd5b606083156104c15782516104ba576001600160a01b0385163b6104ba5760405162461bcd60e51b815260206004820152601d60248201527f416464726573733a2063616c6c20746f206e6f6e2d636f6e7472616374000000604482015260640161015e565b50816104cb565b6104cb83836105e4565b949350505050565b6104dc8161060e565b6040516001600160a01b038216907fbc7cd75a20ee27fd9adebab32041f755214dbc6bffa90cc0225b39da2e5c2d3b90600090a250565b6001600160a01b0381166105785760405162461bcd60e51b815260206004820152602660248201527f455243313936373a206e65772061646d696e20697320746865207a65726f206160448201526564647265737360d01b606482015260840161015e565b807fb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d61035b80546001600160a01b0319166001600160a01b039290921691909117905550565b60007f360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc6101db565b8151156105f45781518083602001fd5b8060405162461bcd60e51b815260040161015e9190610823565b6001600160a01b0381163b61067b5760405162461bcd60e51b815260206004820152602d60248201527f455243313936373a206e657720696d706c656d656e746174696f6e206973206e60448201526c1bdd08184818dbdb9d1c9858dd609a1b606482015260840161015e565b807f360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc61059b565b600080858511156106b257600080fd5b838611156106bf57600080fd5b5050820193919092039150565b80356001600160a01b03811681146106e357600080fd5b919050565b6000602082840312156106fa57600080fd5b61019e826106cc565b634e487b7160e01b600052604160045260246000fd5b6000806040838503121561072c57600080fd5b610735836106cc565b9150602083013567ffffffffffffffff8082111561075257600080fd5b818501915085601f83011261076657600080fd5b81358181111561077857610778610703565b604051601f8201601f19908116603f011681019083821181831017156107a0576107a0610703565b816040528281528860208487010111156107b957600080fd5b8260208601602083013760006020848301015280955050505050509250929050565b60005b838110156107f65781810151838201526020016107de565b838111156103c45750506000910152565b600082516108198184602087016107db565b9190910192915050565b60208152600082518060208401526108428160408501602087016107db565b601f01601f1916919091016040019291505056fe416464726573733a206c6f772d6c6576656c2064656c65676174652063616c6c206661696c6564a264697066735822122012bb4f564f73959a03513dc74fc3c6e40e8386e6f02c16b78d6db00ce0aa16af64736f6c63430008090033
And then decode the metadata of the contract at https://playground.sourcify.dev/ :
{
"compiler": {
"version": "0.8.9+commit.e5eed63a"
},
"language": "Solidity",
"output": {
"abi": [
{
"inputs": [
{
"internalType": "address",
"name": "_logic",
"type": "address"
},
{
"internalType": "address",
"name": "admin_",
"type": "address"
},
{
"internalType": "bytes",
"name": "_data",
"type": "bytes"
}
],
"stateMutability": "payable",
"type": "constructor"
},
{
"anonymous": false,
"inputs": [
{
"indexed": false,
"internalType": "address",
"name": "previousAdmin",
"type": "address"
},
{
"indexed": false,
"internalType": "address",
"name": "newAdmin",
"type": "address"
}
],
"name": "AdminChanged",
"type": "event"
},
{
"anonymous": false,
"inputs": [
{
"indexed": true,
"internalType": "address",
"name": "beacon",
"type": "address"
}
],
"name": "BeaconUpgraded",
"type": "event"
},
{
"anonymous": false,
"inputs": [
{
"indexed": true,
"internalType": "address",
"name": "implementation",
"type": "address"
}
],
"name": "Upgraded",
"type": "event"
},
{
"stateMutability": "payable",
"type": "fallback"
},
{
"stateMutability": "payable",
"type": "receive"
}
],
"devdoc": {
"details": "This contract implements a proxy that is upgradeable by an admin. To avoid https://medium.com/nomic-labs-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357[proxy selector clashing], which can potentially be used in an attack, this contract uses the https://blog.openzeppelin.com/the-transparent-proxy-pattern/[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\". These properties mean that the admin account can only be used for admin actions like upgrading the proxy or changing the admin, so it's best if it's a dedicated account that is not used for anything else. This will avoid headaches due to sudden errors when trying to call a function from the proxy implementation. Our recommendation is for the dedicated account to be an instance of the {ProxyAdmin} contract. If set up this way, you should think of the `ProxyAdmin` instance as the real administrative interface of your proxy. NOTE: The real interface of this proxy is that defined in `ITransparentUpgradeableProxy`. This contract does not inherit from that interface, and instead the admin functions are implicitly implemented using a custom dispatch mechanism in `_fallback`. Consequently, the compiler will not produce an ABI for this contract. This is necessary to fully implement transparency without decoding reverts caused by selector clashes between the proxy and the implementation. WARNING: It is not recommended to extend this contract to add additional external functions. If you do so, the compiler will not check that there are no selector conflicts, due to the note above. A selector clash between any new function and the functions declared in {ITransparentUpgradeableProxy} will be resolved in favor of the new one. This could render the admin operations inaccessible, which could prevent upgradeability. Transparency may also be compromised.",
"kind": "dev",
"methods": {
"constructor": {
"details": "Initializes an upgradeable proxy managed by `_admin`, backed by the implementation at `_logic`, and optionally initialized with `_data` as explained in {ERC1967Proxy-constructor}."
}
},
"version": 1
},
"userdoc": {
"kind": "user",
"methods": {},
"version": 1
}
},
"settings": {
"compilationTarget": {
"@openzeppelin/contracts/proxy/transparent/TransparentUpgradeableProxy.sol": "TransparentUpgradeableProxy"
},
"evmVersion": "london",
"libraries": {},
"metadata": {
"bytecodeHash": "ipfs"
},
"optimizer": {
"enabled": true,
"runs": 200
},
"remappings": []
},
"sources": {
"@openzeppelin/contracts/interfaces/IERC1967.sol": {
"keccak256": "0x84cbc33838326f8a92fb9db5e27176f8eda5de8797cd6c838c11ef99c724accc",
"license": "MIT",
"urls": [
"bzz-raw://94f93d36b8355575c884fb938ad43763207cc67f4abd791e528294ec603cbfbb",
"dweb:/ipfs/QmTGVR5LR8BAtUMnAQ89DdyMaRv2A7kS4WoBuFEXaW5Lfw"
]
},
"@openzeppelin/contracts/interfaces/draft-IERC1822.sol": {
"keccak256": "0x1d4afe6cb24200cc4545eed814ecf5847277dfe5d613a1707aad5fceecebcfff",
"license": "MIT",
"urls": [
"bzz-raw://383fb7b8181016ac5ccf07bc9cdb7c1b5045ea36e2cc4df52bcbf20396fc7688",
"dweb:/ipfs/QmYJ7Cg4WmE3rR8KGQxjUCXFfTH6TcwZ2Z1f6tPrq7jHFr"
]
},
"@openzeppelin/contracts/proxy/ERC1967/ERC1967Proxy.sol": {
"keccak256": "0xa2b22da3032e50b55f95ec1d13336102d675f341167aa76db571ef7f8bb7975d",
"license": "MIT",
"urls": [
"bzz-raw://96b6d77a20bebd4eb06b801d3d020c7e82be13bd535cb0d0a6b7181c51dab5d5",
"dweb:/ipfs/QmPUR9Cv9jNFdQX6PtBfaBW1ZCnKwiu65R2VD5kbdanDyn"
]
},
"@openzeppelin/contracts/proxy/ERC1967/ERC1967Upgrade.sol": {
"keccak256": "0x480bc688d336e5d8b30f6705af3c73468dc7a8c4e7edcfcacce955939b0786fa",
"license": "MIT",
"urls": [
"bzz-raw://d71598df93feea24df0fc19ef2f0280382ace3adf5a5fb62bd62a9ec458c47c8",
"dweb:/ipfs/QmbyY8TXQoRZ1GmNN2c9JVStMmkiJMfmMJ3wwEPLQcT3Hq"
]
},
"@openzeppelin/contracts/proxy/Proxy.sol": {
"keccak256": "0xc130fe33f1b2132158531a87734153293f6d07bc263ff4ac90e85da9c82c0e27",
"license": "MIT",
"urls": [
"bzz-raw://8831721b6f4cc26534d190f9f1631c3f59c9ff38efdd911f85e0882b8e360472",
"dweb:/ipfs/QmQZnLErZNStirSQ13ZNWQgvEYUtGE5tXYwn4QUPaVUfPN"
]
},
"@openzeppelin/contracts/proxy/beacon/IBeacon.sol": {
"keccak256": "0xd50a3421ac379ccb1be435fa646d66a65c986b4924f0849839f08692f39dde61",
"license": "MIT",
"urls": [
"bzz-raw://ada1e030c0231db8d143b44ce92b4d1158eedb087880cad6d8cc7bd7ebe7b354",
"dweb:/ipfs/QmWZ2NHZweRpz1U9GF6R1h65ri76dnX7fNxLBeM2t5N5Ce"
]
},
"@openzeppelin/contracts/proxy/transparent/TransparentUpgradeableProxy.sol": {
"keccak256": "0x846e9f9d27fdf5efe8a1b68c8b45c07ca5b7f8c2fa574491c2ccb9decc695232",
"license": "MIT",
"urls": [
"bzz-raw://92e3fcdb192547c23f9ab0847c757a200e2cad33e848b4633747e57296ca0d46",
"dweb:/ipfs/Qmed72iEFMbVbjDHqV5PZ5myRtTNWv8HZrbhhukM4vhZst"
]
},
"@openzeppelin/contracts/utils/Address.sol": {
"keccak256": "0xf96f969e24029d43d0df89e59d365f277021dac62b48e1c1e3ebe0acdd7f1ca1",
"license": "MIT",
"urls": [
"bzz-raw://ec772b45a624be516f1c81970caa8a2e144301e9d0921cbc1a2789fef39a1269",
"dweb:/ipfs/QmNyjwxCrGhQMyzLD93oUobJXVe9ceJvRvfXwbEtuxPiEj"
]
},
"@openzeppelin/contracts/utils/StorageSlot.sol": {
"keccak256": "0xd5c50c54bf02740ebd122ff06832546cb5fa84486d52695a9ccfd11666e0c81d",
"license": "MIT",
"urls": [
"bzz-raw://39e096c60a6eb1c6a257122d515496bd92d0c6a693a8f07acb6aa4b1263e95d4",
"dweb:/ipfs/QmPs5trJBacCiSkezP6tpevapuRYWNY6mqSFzsMCJj7e6B"
]
}
},
"version": 1
}The solc version of metadata is 0.8.9+commit.e5eed63a. Could you confirm that the deployed contract uses version 0.8.9?
The solc version of proxy contract 0x5e563D066162cB99A5c3237521aF82993EAd7FA6 is "0.8.9+commit.e5eed63a".
It can decode the metadata of the contract at https://playground.sourcify.dev/
Will take a look at the proxy contract, just wanted to know your opinion on other chains/explorer I am not facing any issue. Most of them automatically verifies the proxy the contract.
Will take a look at the proxy contract, just wanted to know your opinion on other chains/explorer I am not facing any issue. Most of them automatically verifies the proxy the contract.
This phenomenon is truly strange. Would you like to provide the proxy contract addresses on the other chains (verified on etherscan)? I would like to compare their differences.
Hi,
Recent update on the above
I am able to verify implementation address
0x0e2c4DBfd5179Bc913e24AECfaB4156f48942A31 of proxy contract 0xd4Fe839cD9C665d8d383335bE6b9CAF2943e5373
Are you sure 0.8.20 works on opbnb chain? If I remember correctly then there are some breaking changes in 0.8.20 that will only work on mainnet.
Are you sure 0.8.20 works on opbnb chain? If I remember correctly then there are some breaking changes in 0.8.20 that will only work on mainnet.
According to my tests, contracts in version 0.8.20 work fine on the opBNB testnet at the moment.
@SauravKanchan 's issue is about the mismatch between deployed and configured solc versions.
If you encounter any issues with Solc 0.8.20, please contact me or report an issue, thank you.
I am going to close this issue as I think it has been resolved.