Klaytn Docs Archive
Getting StartedBuild a dAppNode OperationDeveloper Hub
  • Klaytn Docs
  • -
    • Klaytn Overview
      • Why Klaytn
      • Klaytn Design
        • Consensus Mechanism
        • Accounts
        • Transactions
          • Basic
          • Fee Delegation
          • Partial Fee Delegation
          • Ethereum
        • Computation
          • Klaytn Smart Contract
          • Execution Model
          • Computation Cost
            • Computation Cost (Previous docs)
          • Klaytn Virtual Machine
            • Klaytn Virtual Machine (Previous docs)
        • Storage
          • State Migration
          • StateDB Live Pruning
        • Transaction Fees
          • Transaction Fees (Previous docs)
        • Klaytn native coin - KLAY
        • Token Economy
        • Governance
        • Multi-Channel
        • KNI
      • Scaling Solutions
    • Getting Started
      • Deploying Smart Contract Using Foundry
      • Deploying Smart Contract Using Hardhat
      • Deploying Smart Contract Using Thirdweb
      • Deploying Smart Contract Using KEN
        • Launch an Endpoint Node
        • Top up your Account
        • Install Development Tools
        • Deploy a Smart Contract
        • Check the Deployment
        • Account Management
          • Creating Accounts
          • Managing Accounts
      • Development Environment
      • Getting KLAY
    • Smart Contract
      • Solidity - Smart Contract Language
      • Precompiled Contracts
        • Precompiled Contracts (Previous docs)
      • IDE and Tools
        • Truffle
      • Sample Contracts
        • KlaytnGreeter
        • ERC-20
          • 1. Writing ERC-20 Smart Contract
          • 2. Deploying Smart Contract
          • 3. Interacting with ERC-20 token from Klaytn Wallet
        • ERC-721
          • 1. Writing ERC-721 Smart Contract
          • 2. Deploying Smart Contract
      • Testing Guide
      • Deployment Guide
      • Klaytn Compatible Tokens
      • Porting Ethereum Contract
    • Run a Node
      • Deployment
        • Endpoint Node
          • System Requirements
          • Installation Guide
            • Download
            • Installation Guide
            • Configuration
            • Startup the EN
            • Testing the Installation
          • ken CLI commands
          • JSON-RPC APIs
        • Core Cell
          • System Requirements
          • Network Configuration
          • Installation Guide
            • Download
            • Before You Install
            • Consensus Node Setup
              • Installation Guide
              • Configuration
              • Startup the CN
            • Proxy Node Setup
              • Installation Guide
              • Configuration
              • Startup the PN
            • Testing the Core Cell
          • Monitoring Setup
          • H/A Setup
        • Service Chain
          • Getting Started
            • Setting up a 4-node Service Chain
            • Connecting to Baobab
            • Cross-Chain Value Transfer
            • HA(High Availability) for ServiceChain
            • Nested ServiceChain
            • Value Transfer between Sibling ServiceChains
          • Reference Manuals
            • System Requirements
            • Download
            • SCN User Guide
              • Installation
              • Configuration
              • Starting/Stopping SCN
              • Checking Node Status
              • kscn commands
              • homi commands
            • SPN/SEN User Guide
              • Installation
              • Configuration
              • Starting/Stopping Node
              • Checking Node Status
            • Bridge Configuration
            • Anchoring
            • KAS Anchoring
            • Value Transfer
            • Configuration Files
            • Log Files
            • Genesis JSON
            • Upgrade & Hard Fork
          • How-To Guides
        • Download Node Packages
          • v1.12.0
          • v1.11.1
          • v1.11.0
          • v1.10.2
          • v1.10.1
          • v1.10.0
          • v1.9.1
          • v1.9.0
          • v1.8.4
          • v1.8.3
          • v1.8.2
          • v1.8.1
          • v1.8.0
          • v1.7.3
          • v1.7.2
          • v1.7.1
          • v1.7.0
          • v1.6.4
          • v1.6.3
          • v1.6.2
          • v1.6.1
          • v1.6.0
          • v1.5.3
          • v1.5.2
          • v1.5.1
          • v1.5.0
          • v1.4.2
          • v1.4.1
          • v1.4.0
          • v1.3.0
          • v1.2.0
          • v1.1.1
          • v1.0.0
          • v0.9.6
          • v0.8.2
    • Operation Guide
      • Configuration
      • Node Log
      • Log operation
      • Errors & Troubleshooting
      • Klaytn Command
      • Chaindata Change
      • Chaindata Migration
    • dApp Developers
      • JSON-RPC APIs
        • API references
          • eth
            • Caution
            • Account
            • Block
            • Transaction
            • Config
            • Filter
            • Gas
            • Miscellaneous
          • klay
            • Account
            • Block
            • Transaction
              • Working with Klaytn Transaction Types
            • Configuration
            • Filter
            • Gas
            • Miscellaneous
          • net
          • debug
            • Logging
            • Profiling
            • Runtime Tracing
            • Runtime Debugging
            • VM Tracing
            • VM Standard Tracing
            • Blockchain Inspection
          • admin
          • personal
          • txpool
          • governance
        • Service Chain API references
          • mainbridge
          • subbridge
        • Transaction Error Codes
      • RPC Service Providers
        • Public Endpoints
      • SDK & Libraries for interacting with Klaytn Node
        • caver-js
          • Getting Started
          • Sending a sample transaction
          • API references
            • caver.account
            • caver.wallet
              • caver.wallet.keyring
            • caver.transaction
              • Basic
              • Fee Delegation
              • Partial Fee Delegation
            • caver.rpc
              • caver.rpc.klay
              • caver.rpc.net
              • caver.rpc.governance
            • caver.contract
            • caver.abi
            • caver.kct
              • caver.kct.kip7
              • caver.kct.kip17
              • caver.kct.kip37
            • caver.validator
            • caver.utils
            • caver.ipfs
          • caver-js ~v1.4.1
            • Getting Started (~v1.4.1)
            • API references
              • caver.klay
                • Account
                • Block
                • Transaction
                  • Legacy
                  • Value Transfer
                  • Value Transfer Memo
                  • Account Update
                  • Smart Contract Deploy
                  • Smart Contract Execution
                  • Cancel
                • Configuration
                • Filter
                • Miscellaneous
              • caver.klay.net
              • caver.klay.accounts
              • caver.klay.Contract
              • caver.klay.KIP7
              • caver.klay.KIP17
              • caver.klay.abi
              • caver.utils (~v1.4.1)
            • Porting from web3.js
        • caver-java
          • Getting Started
          • API references
          • caver-java ~v1.4.0
            • Getting Started (~v1.4.0)
            • Porting from web3j
        • ethers.js
        • web3.js
      • Tutorials
        • Klaytn Online Toolkit
        • Fee Delegation Example
        • Count DApp
          • 1. Environment Setup
          • 2. Clone Count DApp
          • 3. Directory Structure
          • 4. Write Smart Contract
          • 5. Frontend Code Overview
            • 5-1. Blocknumber Component
            • 5-2. Auth Component
            • 5-3. Count Component
          • 6. Deploy Contract
          • 7. Run App
        • Klaystagram
          • 1. Environment Setup
          • 2. Clone Klaystagram DApp
          • 3. Directory Structure
          • 4. Write Klaystagram Smart Contract
          • 5. Deploy Contract
          • 6. Frontend Code Overview
          • 7. FeedPage
            • 7-1. Connect Contract to Frontend
            • 7-2. UploadPhoto Component
            • 7-3. Feed Component
            • 7-4. TransferOwnership Component
          • 8. Run App
        • Building a Buy Me a Coffee dApp
          • 1. Project Setup
          • 2. Creating a BMC Smart Contract
          • 3. Testing the contract using scripts
          • 4. Deploying BMC Smart contract
          • 5. Building the BMC Frontend with React and Web3Onboard
          • 6. Deploying Frontend code on IPFS using Fleek
          • 7. Conclusion
        • Migrating Ethereum App to Klaytn
        • Connecting MetaMask
        • Connecting Remix
        • Verifying Smart Contracts Using Block Explorers
      • Developer Tools
        • Wallets
          • Kaikas
          • Klaytn Wallet
          • Klaytn Safe
            • Klaytn Safe Design
            • Create a Safe
            • Add assets
            • Send assets
            • Contract Interaction
            • Transaction Builder
            • Points to Note
            • Frequently Asked Questions
          • SafePal S1
          • Wallet Libraries
            • Web3Auth
            • Web3Modal
            • Web3-Onboard
            • Particle Network
        • Oracles
          • Orakl Network
          • Witnet
          • SupraOracles
        • Indexers
          • SubQuery
        • Cross-chain
          • LayerZero
        • Block Explorers
          • Klaytnscope
          • Klaytnfinder
        • Klaytn Contracts Wizard
    • Glossary
  • ---
    • Klaytn Hard Fork History
    • Klaytn 2.0
      • Metaverse Package
      • Finality and Improvements
      • Ethereum Compatibility
      • Decentralizing Governance
      • Massive Eco Fund
    • FAQ
    • Open Source
    • Terms of Use
    • Languages
  • ℹ️Latest Klaytn Docs
Powered by GitBook
On this page
  • Introduction
  • Prerequisites
  • Getting Started
  • Deploying a single Contract
  • Parameters for single contract verification
  • Deploying a multi-part contract
  • Parameters for multi-part contract verification
  • Verifying the Contract
  • 1. Klaytnscope
  • 2. Klaytnfinder
  • 2.2 Verifying multiple-part contract
  • Conclusion
  1. -
  2. dApp Developers
  3. Tutorials

Verifying Smart Contracts Using Block Explorers

PreviousConnecting RemixNextDeveloper Tools

Last updated 1 year ago

Introduction

Usually, the deployer of a smart contract is the only party with access to the code that was actually deployed, and the public cannot read the source code of a contract until the deployer has verified it. However, this is where contract verification comes in as an important step in the smart-contract development cycle, as it helps improve the transparency (for users), convenience (for developers), and security of deployed contracts.

Having said that, once a smart contract is validated, block explorers like Klaytnscope and Klaytnfinder also make it possible for the public to interact with the contract's public methods using the block explorer's user interface. This is in addition to the public having direct access to the verified contract source code.

In this guide, we'll take a look at how to use block explorers to verify deployed smart contracts on the Klaytn Network.

Prerequisites

  • and

  • Enough test KLAY from

Getting Started

In this guide, we will be going over verifying both single contracts and multi-part contracts on the block explorers that exist in the Klaytn ecosystem, viz.:

Without further ado, let's get started!

Deploying a single Contract

To verify a smart contract, you need to deploy the contract first on the target network. Hence, for the sake of this guide, we will be deploying the contract to Klaytn Baobab Testnet. Also, in this tutorial, we will be deploying a simple counter contract named Counter.sol on Remix IDE. The code is shown below:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract Counter {
    uint256 public count;
    constructor(uint256 _initialCount) {
        count = _initialCount;
    }
    function incrementCounter() public {
        count++;
    }
    function decrementCounter() public {
        count--;
    }
    function resetCounter() public {
        count = 0;
    }
}

Parameters for single contract verification

Verifying a contract on the block explorers requires some parameters, and these must be considered while deploying the smart contract. The following are some details related to the contract's compiler and deployment in order to verify a contract successfully:

Remix IDE :

  • On Remix IDE, navigate to the Solidity compiler tab.

    • Observe the compiler version used to compile and deploy the contract.

    • Observe the Open Source License Type used in the contract. This means the SPDX license identifier used at the beginning of the Solidity source file. In the Counter.sol file we used // SPDX-License-Identifier: MIT

    • Observe the EVM version used for deploying contracts.

    • (Optional) If optimization is enabled during compilation, take note of the value of the optimization runs parameter

  • On Remix IDE, navigate to Klaytn tab.

    • Take note of the contract address of the smart contract on the Deployed Contracts tab after successful deployment.

Deploying a multi-part contract

It is important to note that deploying a multi-part contract involves the same steps as deploying a single contract. For the sake of this guide, we will be deploying a simple KIP7 airdrop contract named airdropToken.sol. The code is shown below:

//SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;
import "@klaytn/contracts/KIP/token/KIP7/KIP7.sol";
import "@klaytn/contracts/access/Ownable.sol";
// the creator of the project mints certian amount of fungible tokens directly to a certain selection of wallets.
contract TokenAirdrop is KIP7, Ownable {
    constructor() KIP7("Token Aidrop Demo", "TAD") {
    }
    // Airdrop Token
    function airdropTokens(address[] calldata wAddresses, uint[] calldata tAmount) public onlyOwner {
        require(wAddresses.length == tAmount.length, "Must be same lenght");
        for (uint256 i = 0; i < wAddresses.length; i++) {
            _mintSingleTokens(wAddresses[i], tAmount[i]);
        }
    }
    function _mintSingleTokens(address wAddress, uint amount) private {
        _mint(wAddress, amount);
    }
    function supportsInterface(bytes4 interfaceId)
        public
        view
        virtual
        override
        returns (bool)
    {
        return
            super.supportsInterface(interfaceId);
    }
}

Parameters for multi-part contract verification

The parameters for verifying a multi-part contract are the same as those for a single contract. However, because they are made up of multiple dependent contracts, we need to pre-process all dependencies of the contract into a single solidity file. This preprocessing is usually referred to as smart contract flattening.

For this reason, we will have to flatten the contract so it can be verified using the new flattened Solidity file on the block explorer.

Remix IDE:

  • On Remix IDE, navigate to the File explorer tab.

    • Select the newly created contract under the contracts folder

    • Click or tap with two fingers to see all commands available on the contract.

    • Select flatten

    • Once code is flattened, you will see a new contract named airdropTokens_flattened.sol.

Verifying the Contract

Having obtained all of our verification parameters, we will go over the steps for verifying a single smart contract (Counter.sol) and a multi-part smart contract (airdropTokens.sol) on the block explorer in this section.

1. Klaytnscope

To verify a single contract and multi-part contracts on Klaytnscope, follow the steps below:

1.1 Verifying a single contract

  1. Navigate to the contract tab on that page.

  2. Click on the Match Contract Source Code link to submit contract code for verification.

  1. On the contract verification page, make sure your account is connected to either Kaikas or Metamask. For this guide, we will be using Kaikas.

  2. Fill in the contract address in the contract address field. Note: This field is usually filled with the contract address automatically.

  3. Select the compiler version used for the Counter.sol example.

  4. Select the Open Source License Type used for the Counter.sol example. For Counter.sol example, select the option, MIT License (MIT). If there was none used, select No License (None).

  5. In the Source Code field, select Source Text and paste the source code for Counter.sol in the text-field.

  6. Select True for Optimization if it was enabled during compilation, and fill in the number of runs under Optimization Runs to be 200.

  7. Select the EVM version for the contract. For Counter.sol example, select the option Istanbul.

  8. Click on the CAPTCHA at the bottom and the Sign and Submit button to confirm and begin verification.

  1. After signing the verification request, you will get a verification status notification

  1. Once verification is done, the result of the verification will be displayed in the browser, and a success result page with the contract address. Click on the contract address to view the Contract Source Code, Contract ABI, and Bytecode.

1.2 Verifying multi-part contract

Verifying a multi-part contract on Klaytnscope is as straightforward as verifying a single contract, except that it requires some additional steps. In this section, we will be verifying the airdropToken.sol contract with the following additional steps:

  • You can either Select Source Text under Source Code (step 3 of the Counter.sol example) or Solidity File(s) under the Source Code field. In the case of Source Text, copy the code in the airdropToken_flattened.sol and paste in the text field. If Solidity File(s), you can download the airdropToken_flattened.sol file on Remix IDE and upload to the field.

a. Source Text

b. Solidity File(s)

After this, every other step remains the same as verifying a single contract. Having filled the verification parameter, click on the Sign and Submit button to confirm and begin verification.

Once verification is done, the result of the verification will be displayed in the browser, and a success result page with the contract address. Click on the contract address to view the Contract Source Code, Contract ABI, and Bytecode.

2. Klaytnfinder

2.1 Verifying single contract

  1. Observe the Is this contract for a token field? This field is needed when trying to verify a token contract with its official website URL, official email address, and token logo image. For the sake of this guide, select No as we are not verifying a commercial token contract.

  2. Fill in the contract address for the deployed contract (Counter.sol)

  3. Make sure to download Counter.sol from Remix IDE and upload in the Source Code (Solidity File) field

  4. Select the compiler version used for the Counter.sol example

  5. Select the Open Source License Type used for the Counter.sol example. For Counter.sol example, select the option, MIT License (MIT). If there was none used, select No License (None)

  6. Select the EVM version for the contract. For Counter.sol example, select the option Istanbul.

  7. Select True for Optimization if it was enabled during compilation, and fill in the number of runs under Optimization Runs to be 200.

  1. Click on the Sign and Submit button to confirm and begin verification.

  1. Once verification is done, you will get a Submission Successful message. Now you can paste the contract address in the explorer search bar to view the Contract Source Code, Contract ABI, Creation Code and ABI-encoded Value.

2.2 Verifying multiple-part contract

Verifying a multi-part contract on Klaytnfinder follows the same step as verifying a single contract. However, it is important to note we will be uploading the airdropToken_flattened.sol file in the Source Code(Solidity File) field.

After filling the verification parameters, click on the Sign and Submit button to confirm and begin verification. Once verification is done, you will get a Submission Successful message. Now you can paste the contract address in the explorer search bar to view the Contract Source Code, Contract ABI, and Creation Code.

Conclusion

Note: You can check this page for a tutorial on deploying smart contracts using on Klaytn Baobab Testnet. You may also use a developer tool such as , , or another tool if preferred, to deploy the smart contract to Klaytn Baobab Testnet.

(Optional) If the contract constructor method accepts arguments, take note of the of the constructor arguments

Note: There are different tools for flattening a multi-part smart contract into a single Solidity file, such as . Kindly refer to the respective smart contract flattening tool's documentation for more detailed instructions on its usage.

Goto the search bar of and paste the deployed contract address.

To verify a single contract and multi-part contracts on Klaytnfinder, navigate to the . However, make sure your account is connected to either Kaikas or MetaMask and follow the steps below:

(optional) To get the ABI-encoded constructor arguments for this field, navigate to to get the encoded data following the image below:

Congratulations on following this guide! In this tutorial, you learnt how to verify contracts (both single and multi-part) using Klaytnscope and Klaytnfinder solely to enhance the transparency (for users), convenience (for developers), and security of deployed contracts. Visit for more information and if you have any questions.

Remix IDE
Kaikas Wallet
faucet
Klaytnscope
Klaytnfinder
libraries
Hardhat
Foundry
Remix
ABI-encoded form
Hardhat Flattener
Klaytnscope
contract submission request page
abi.hashex.org
Klaytn Docs
Klaytn Forum