How to Verify Smart Contracts on Etherscan

You have your smart contract written, tested, and deployed. However, customers aren’t willing to do business with you unless they know the contract’s source code. After all, it could be set up in a way that’s not in their interest.

Thankfully, Etherscan offers a neat tool that allows you to verify smart contracts so interested parties can see the source code and verify for themselves that everything is as it should be.

While the process is simple, there are intricacies that might cause problems, especially to people not very familiar with Ethereum and the Solidity programming language.

What you’ll learn

• How to correctly fill the smart contract verification form.
• What options you have and how to use them.
• How to provide smart contract parameters provided at the time of deployment.

Verifying smart contracts – step by step

The first thing to do is head over to Etherscan and open the Smart Contract Verification tool:

As it is currently set up, the process is split into two steps:

1. Provide address and info about the environment the smart contract was created in.
2. Provide details about the smart contract itself.

1. Providing info about the environment of the smart contract

In this step, you need to fill-in three fields (as shown in the image above). The first one and the last one are self-explanatory. The Compiler Type is the type of project you had prior to deploying the contracts on the Ethereum network.

Previously, Etherscan offered only one option – pasting the source code of the contract you want to verify. This posed problems for big contracts – the ones that cannot be deployed all as one due to the block size limit.

In its current version, the Etherscan Smart Contract Verification tool offers 4 options for a Compiler Type:

• Solidity – single file
• Solidity – multiple files
• Solidity – standard JSON input
• Vyper – currently marked as experimental

Once you select a Compiler Type, the Compiler Version field will appear. You need to get this one absolutely right or Etherscan won’t be able to verify your smart contracts. So make sure you know exactly which compiler version you used when building the contracts, and select it from the dropdown options.

After selecting the Compiler Type and Compiler Version and providing the contract address, you need to select an Open Source License Type. The current options are:

• No license
• Unlicense
• MIT License
• GNU General Public License v2.0
• GNU General Public License v3.0
• GNU Lesser General Public License v2.1
• GNU Lesser General Public License v3.0
• BSD 2-clause “Simplified” license
• BSD 3-clause “New” or “Revised” license
• Mozilla Public License 2.0
• Open Software License 3.0
• Apache 2.0

When you are done with that, you can accept the terms and move onto the next and final step of the verification process.

2. Providing smart contract details

For this guide, I will use the single file Compiler Type, but the process is similar for the rest of the options:

The first row of fields includes details provided in the first step, as well as the option to specify whether you used optimization when compiling the contract. For those unaware, the optimization option of the compiler tries to remove unneeded instructions in order to lower gas expenditure.

Next comes the source code of your smart contract. In our case, we have a textarea where we need to paste the code, but, for example, in the case of selecting the multiple files Compiler Type in step one, we would have a file upload input to upload all files used for the deployment of the contract.

Constructor arguments

Now, in this section is where it can get somewhat tricky. If you didn’t provide any parameters when deploying your contract, you can skip this section, but if you did, you need to provide their ABI-encoded values.

For this you can use the ABI encoding tool of HashEx. Scroll down to the “Or enter your parameters manually” section and enter your parameters, making sure that you select the correct types from the dropdown.

The ABI-encoded version of your contract parameters will appear in the textarea at the bottom:

Copy the contents of the textarea and paste that into Etherscan. Again, this only applies if you provided parameters to your smart contract at the time of deployment.

Libraries

The section below the Constructor Arguments section is the Contract Library Address. It allows you to add the names and addresses of contracts that your contract utilizes.

For example, if your contract becomes too big, you can split it into two contracts. You can then deploy one of the contracts (the one that has some utility functions used by the second contract) and then deploy the second one, specifying in the verification process that it uses the first contract as a library.

This section is optional and only required if your contract uses functions of another contract that is already deployed on the Ethereum network.

Misc settings

Lastly, there are misc settings you can optionally modify (they have default settings):

• Runs – the number of code runs you want the optimizer to make.
• EVM version – the particular Ethereum Virtual Machine version you want to compile for.
• License type – this is the same input as the one we covered in the first step of the verification process.

In most cases, you won’t need to edit any of these settings.

Once you have provided all details correctly, prove you are not a robot and then click the Verify and Publish button. If all is well, the contract will get verified and you will be able to see its code on the Contract tab of the contract’s Etherscan page.

Summary

Verified smart contracts, especially in the case of an initial coin offering (ICO), are an absolute must. Without a verified contract, there will be no trust in your enterprise. Thankfully, you now know how you can verify your smart contracts using Etherscan, and as you can see, it’s really easy.