I followed other answers but could not succeed.
I was so kind to verify the contract source for you.
This is a very common problem I also experienced. (It's extremely frustrating)
Compiler Version: 0.4.24
Contract-Code: Copy the Coin.sol file
Optimization: YES !!!!!!! (most likely you were missing that)
Here is the link of your verified contract: https://etherscan.io/address/0xa0005edc8897fe1f9e2705a1682431497a504657#code
This question has other answers.
Your contract has
^ in the
pragma, so no one can be sure what compiler was used. Its presence is a sign that the code hasn't received an appropriate critical review. An audit would likely flag that practice since it casts doubt about other possible problems. The compiler itself can be the source of trouble so there should never be doubt about which version was used.
If you can inspect the machine that compiled it, and the method (was it solc, truffle, remix?) you might be able to piece together what version was used.
Source code verification works by compiling the code you claim is the source code and comparing the resulting bytecode (bitwise) to what is deployed. If it matches, success.
In practice, you need to know or guess the compiler version and set the optimization flags to exactly match. A determined search can succeed.
Hope it helps.
Contract Source Code is published and publicably verifiable by anyone. Immediately after deploying your Smart Contract, as we did for GreatestShow in the ComeOneComeAll project, you could go to Etherscan and view the contract at its deployed address. As you can see, the Code tab showed a bunch of random looking hex digits starting with 0x60806… which is the actual byteCode for the deployed GreatestShow as well as the constructor arguments that went into the creation of the contract. Once again, that’s fine for the EVM, but we need to help out humans that want to see the code. Click the Verify And Publish link. Tip: Check out the new Beta Source Code Contract Verifier which supports the ‘run’ option for verifying Truffle deployed contracts. If your contract uses libraries and fails to verify, you can also try using the beta source code verifier. https://ropsten.etherscan.io/verifyContract2?a=0xContractAddressGoesHere You should be on the Verify Contract Code (version 2.0) *New screen. Type in the Contract Name , and in our case GreatestShow as well as the version of the compiler that was used when we deployed. Leave Optimization to ‘No’. If you don’t remember what version you used, type truffle version at the command line in your project. Output looks like: Truffle v4.1.7 (core: 4.1.7) Solidity v0.4.23 (solc-js)
So we would choose the v0.4.23+commit version for the Compiler Contract Name, Compiler version and flattened Solidity Contract code are required. We’re going to install a tool that will help us generate flattened Solidity code. This tool helps you to verify contracts developed with Truffle on Etherscan, or debugging them on Remix, by merging your files and their dependencies in the right order. npm install --save-dev truffle-flattener Next, we’ll use the truffle-flattener tool to build a single file of text. truffle-flattener ./contracts/GreatestShow.sol > ./GreatestShowFlattened.sol On a mac you can use the pbcopy tool to copy the text to clipboard. pbcopy < GreatestShowFlattened.sol Then, go back to the Etherscan verification window and paste it. Click the “I’m not a robot.” reCaptcha. Next you will see an animated gif of a gear spinning. Etherscan Verification of Solidity Source Code is considered a Smart Contract Best Practice. Tada! After a successful verification, you’re done. You’ll know that your Contract Source Code Verified (Exact Match) as long as the byteCode compiled and tested in this verifcation step matceh the byteCode that was previously uploaded. If it doesn’t match, it will not verify. Changing even one line of the code to try to trick a user would be easily detected. Now you can proudly send users and potential new customers over to your Published & Verified code and Github project for their perusal.