Learn, step by step, how you can verify your smart contracts’ source code via Etherscan and enable trust in your project.
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:
- Provide address and info about the environment the smart contract was created in or direct to Smart Contract Verification tool from your contract.
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. 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.
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. for example, you can find the compiler version on remix.
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
- 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.
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. But it also can be verified when I did not provide any 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.
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.
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.
Verified smart contracts, so user can review your smart contract and view your input data of transaction.
I do this because I love it, but if you want me to buy me a cup of coffee I won’t say no ：O ）
XEM : NCWZSUF4FPXJY3L3Y7657QNVBIUZ5D54F4TNJ64S
Ether : 0xf2d15dEAf62b8c4AFC0343006579E8E662c120D9
Bitcoin : 332UiyAfSXyvhqCYgDgBkNLFSf25ccNV9i
**Do CLAP, COMMENT and SHARE! I also welcome any business opportunities that arises**