Home

Verify Smart Contracts using Dijets Utility Chain Explorer

Once verified, a smart contract or token contract's source code becomes publicly available and verifiable. This creates transparency and trust between the developer of the smart contract or a DApp and users who interact with the said contract/DApp.

After deploying a smart contract one can verify it easily on Dijets Explorer in three steps:

  1. Flatten the Smart Contract
  2. Clean up the flattened contract
  3. Verify using the Dijets Explorer GUI

Flatten a Smart Contract using Hardhat#

info

Flattening a smart contract refers to combining all Solidity code in one file instead of multiple source files such that, instead of having imports, the imported code is all embedded in the same file.

To flatten the smart contract code run the command: npx hardhat flatten <path-to-contract> >> <flat-contract-name>.sol

Clean up the flattened Smart Contract#

Some clean-up may be necessary to get the code to compile properly in the Dijets Explorer Contract Verifier

  • Remove all but the top SPDX license.

    • If the contract uses multiple SPDX licenses, use both licenses by adding AND for example: SPDX-License-Identifier: MIT AND BSD-3-Clause

Verify the Smart Contract using Dijets Explorer#

  1. Search for the contract in Dijets Explorer
  2. Click on the contract address. Your contract details should come up.
  3. Select the Code tab to view the bytecode, click the Verify & Publish button. You will see several options for verification.
  • Via flattened source code (Solidity)
  • Via standard JSON input
  • Via Sourcify: Sources and metadata JSON file
  • Vyper Contract

Via Flattened Source Code#

Below is the list of all the options and their inputs for the information query form you will see on your screen if you choose to verify your contract via Flattened source code.

  1. Contract Address: The 0x address supplied on contract creation.
  2. Contract Name: Name of the class whose constructor was called in the .sol file. For example, in contract MyContract {.. MyContract is the contract name.
  3. Include Nightly Builds: Yes if you want to show nightly builds.
  4. Compiler: derived from the first line in the contract pragma solidity X.X.X. Use the corresponding compiler version rather than the nightly build.
  5. EVM Version: See EVM version information
  6. Optimization: If you enabled optimization during compilation, check yes.
  7. Optimization Runs: 200 is the Solidity Compiler default value. Only change if you changed this value while compiling.
  8. Enter the Solidity Contract Code: Enter the flattened & cleaned up smart contract code we generated earlier with hardhat.
  9. Try to fetch constructor arguments automatically: If similar contracts exist these may be available.
  10. ABI-encoded Constructor Arguments: See this page for more info.
  11. Add Contract Libraries: Enter the name and 0x address for any required libraries called in the called in the .sol file.
  12. Click the Verify and Publish button.
  13. If all goes well, you will see a checkmark :white_check_mark: next to Code in the code tab, and an additional tab called Read Contract. The contract name will now appear in BlockScout with any transactions related to your contract.

Via standard JSON input#

Below is the list of all the options and their inputs for the information query form you will see on your screen if you choose to verify your contract via Standard Json Input.

  1. Contract Name. There are several options:
    1. Leave blank.
    2. Enter contract name: MyContract.
    3. Enter path to the contract and it's name: path/to/file.sol:MyContract (path should match what is written in your JSON file).
  2. Include nightly builds. You can choose Yes or No depending on your compiler.
  3. Compiler. Choose the compiler version used to compile your smart contract.
  4. Standard Input JSON. Attach your Standard Input JSON file. File should follows solidity format and all the sources must be in Liternal Content format, not an URL.
  5. Try to fetch constructor arguments automatically. Select No if you want to provide ABI-encoded Constructor Arguments or the contract does not have any.
  6. ABI-encoded Constructor Arguments. Fill it with ABI-encoded Constructor Arguments or leave blank.

After filling the form click the Verify & publish button and wait for the response.

Via Sourcify: Sources and metadata JSON file#

See the Contract Verification via Sourcify page for details.

Vyper Contract#

Below is the list of all the options and their inputs for the information query form you will see on your screen if you choose to verify your contract via Vyper.

  1. Contract Address: The 0x address supplied on contract creation. Should autopopulate
  2. Contract Name: Should autopopulate
  3. Compiler: Select the compiler version used in the source code.
  4. Enter the Vyper Contract Code: Copy and paste the contract code
  5. ABI-encoded Constructor Arguments (if required): See this page for more info.
  6. Click the Verify and Publish button.
  7. If all goes well, you will see a checkmark :white_check_mark: next to Code in the code tab, and an additional tab called Read Contract. The contract name will now appear in BlockScout with any transactions related to your contract.

Troubleshooting#

If you receive the dreaded There was an error compiling your contract message this means the bytecode doesn't match the supplied sourcecode. Unfortunately, there are many reasons this may be the case. Here are a few things to try:

  1. Double check the compiler version is correct.

  2. Check that an extra space has not been added to the end of the contract. When pasting in, an extra space may be added. Delete this and attempt to recompile.

  3. Copy, paste and verify your source code in Remix. You may find some exceptions here.

Need some help?

You can join Dijets Support Space for a live chat with one of the team members. Join us on Qowalts.