unable to verify the contract on etherscan.io. How to resolve this issue?

Question

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].

Answer 1

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.

Answer 2

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.