2

I am unable to verify the contract in etherscan.io. I was able to deploy the same solidity code in (Geth, Mist). But the same code I am unable to verify in etherscan.io. What mistake am I doing here?

While deploying the code on mist I used the compiler version:

pragma solidity ^0.4.16;

I selected the same compiler version in etherscan.io : 0.4.16+commit.d7661dd9

Here is the transaction :

Contract was created during Txn# 0x9832deb04d2900f97c0434588038f573ee066c0a095c1c0a0af07225d0068a9d

Result: Does not match the input creation bytecode found at this address. Sorry! The Compiled Contract ByteCode for 'Purchase' does NOT match the Contract Creation Code for [0x89d236a8387e6fE94e27D674D856e09f4dEE1302].

  • Does the contract use any library? Did you compile it with optimization enabled? – pabloruiz55 Dec 3 '17 at 2:40
  • @pabloruiz55: Thank you. I tried to compile with the optimization enabled and removed the carrot symbol. Then my contract got verified – rupali Dec 7 '17 at 22:23
  • By the way: why do people use 0.4.16 in 2018, September in production? – Rick Park Sep 25 '18 at 7:26
4

Try changing your pragmastatement to

pragma solidity 0.4.16

(without the ^).

There may be issues due to the pragma... statement, since with the ^, you allow version 0.4.16

or anything newer that does not break functionality (up to, but not including, version 0.5.0)

(from solidity.readthedocs.io). This may lead to different byte code, resulting in a failed verification.

  • Thank you. Removing the ^ symbol helped me solve the problem – rupali Dec 7 '17 at 22:25
3

I agree with @gisdev_p, to a point. The carrot ^ symbol creates just the sort of ambiguity we don't want at this stage. Your contract is already deployed and, based on the source code, it may have been compiled with any Solidity compiler >= 0.4.16.

Now, you need to discover the version of the compiler that was actually used to make the bytecode that's on the chain.

Everything lower than 0.4.16 is ruled out.

You should think about the tool you used to do the compilation and interrogate it for version number, e.g. solc --version or truffle version). Then, if you're not sure about the optimization option, try it both ways.

When you find the magic combination (Contract name + Compiler Version + Optimization option), Etherscan will note a perfect match between the bytecode on the chain and the result of compiling your contract with your parameters. This is how they confirm the source code they have is a true representation of the compiled contract on the chain.

Hope it helps.

  • Thank you so much for helping me understand the concept. I tried to compile with the optimization enabled and removed the carrot symbol. Then my contract got verified. Thanks a lot! – rupali Dec 7 '17 at 22:24
  • 1
    Glad it helped. Upvotes are always appreciated ;-) – Rob Hitchens - B9lab Dec 7 '17 at 23:22
  • Checking solidity version with solc --version helps me. – Geeroz Apr 18 '18 at 12:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.