How to Verify Smart Contracts on Ethereum



How to Verify Smart Contracts on Ethereum

Welcome to our tutorial on verifying smart contracts on Ethereum! In this guide, we’ll cover the basics of what a smart contract is and the process of verifying its code on the Ethereum blockchain. Whether you’re a seasoned developer or new to the world of smart contracts and Ethereum, this tutorial will provide you with the knowledge and resources you need to ensure the security and integrity of your contracts.

Verifying Smart Contracts on Ethereum

A smart contract is a self-executing contract with the terms of the agreement written directly into lines of code. It facilitates, verifies, and enforces the negotiation or performance of a contract. These contracts are stored and replicated on a blockchain network.

Ethereum is a popular blockchain platform that supports the creation and execution of smart contracts. To verify a smart contract on Ethereum, you can use a variety of tools and techniques to analyze the contract code and ensure that it is secure, accurate, and free of errors.

In this tutorial, we will cover the different tools and methods for verifying smart contracts on Ethereum, including manual code review, automated testing, and third-party verification services. By the end of this tutorial, you will have the skills and knowledge to verify your own smart contracts and ensure their security and integrity on the Ethereum blockchain.



Before deploying a smart contract in the Ethereum Virtual Machine (EVM), developers compile the contract’s source code—instructions written in Solidity or another high-level programming language—to bytecode. As the EVM cannot interpret high-level instructions, compiling source code to bytecode (i.e., low-level, machine instructions) is necessary for executing contract logic in the EVM.

Source code verification is comparing a smart contract’s source code and the compiled bytecode used during the contract creation to detect any differences. Verifying smart contracts matters because the advertised contract code may be different from what runs on the blockchain.

Smart contract verification enables investigating what a contract does through the higher-level language it is written in, without having to read machine code. Functions, values, and usually the variable names and comments remain the same with the original source code that is compiled and deployed. This makes reading code much easier. Source verification also makes provision for code documentation, so that end-users know what a smart contract is designed to do.




Trustlessness is arguably the biggest premise for smart contracts and decentralized applications (dapps). Smart contracts are “immutable” and cannot be altered; a contract will only execute the business logic defined in the code at the time of deployment. This means developers and enterprises cannot tamper with a contract’s code after deploying on Ethereum.

For a smart contract to be trustless, the contract code should be available for independent verification. While the compiled bytecode for every smart contract is publicly available on the blockchain, low-level language is difficult to understand—for both developers and users.

Projects reduce trust assumptions by publishing the source code of their contracts. But this leads to another problem: it is difficult to verify that the published source code matches the contract bytecode. In this scenario, the value of trustlessness is lost because users have to trust developers not to change a contract’s business logic (i.e., by changing the bytecode) before deploying it on the blockchain.

Source code verification tools provide guarantees that a smart contract’s source code files match the assembly code. The result is a trustless ecosystem, where users don’t blindly trust third parties and instead verify code before depositing funds into a contract.



Deploying a smart contract on Ethereum requires sending a transaction with a data payload (compiled bytecode) to a special address. The data payload is generated by compiling the source code, plus the constructor arguments of the contract instance appended to the data payload in the transaction. The compilation is deterministic, meaning it always produces the same output (i.e., contract bytecode) if the same source files and compilation settings (e.g. compiler version, optimizer) is used.


Verifying a smart contract basically involves the following steps:

  1. Input the source files and compilation settings to a compiler.

  2. The compiler outputs the bytecode of the contract

  3. Get the bytecode of the deployed contract at a given address

  4. Compare the deployed bytecode with the recompiled bytecode. If the codes match, the contract gets verified with the given source code and compilation settings.

  5. Additionally, if the metadata hashes at the end of the bytecode match, it will be a full match.



The traditional process of verifying contracts can be complex. This is why we have tools for verifying source code for smart contracts deployed on Ethereum. These tools automate large parts of the source code verification and also curate verified contracts for the benefit of users.


Although mostly known as an Ethereum blockchain explorer, Etherscan also offers a source code verification service for smart contract developers and users.

Etherscan allows you to recompile contract bytecode from the original data payload (source code, library address, compiler settings, contract address, etc.) If the recompiled bytecode is associated with the bytecode (and constructor parameters) of the on-chain contract, then the contract is verified.

Once verified, your contract’s source code receives a “Verified” label and is published on Etherscan for others to audit. It also gets added to the Verified Contracts section—a repository of smart contracts with verified source codes.

Etherscan is the most used tool for verifying contracts. However, Etherscan’s contract verification has a drawback: it fails to compare the metadata hash of the on-chain bytecode and recompiled bytecode. Therefore the matches in Etherscan are partial matches.

More on verifying contracts on Etherscan.


Sourcify is another tool for verifying contracts that are open-sourced and decentralized. It is not a block explorer and only verifies contracts on different EVM-based networks. It acts as a public infrastructure for other tools to build on top of it and aims to enable more human-friendly contract interactions using the ABI and NatSpec comments found in the metadata file.

Unlike Etherscan, Sourcify supports full matches with the metadata hash. The verified contracts are served in its public repository on HTTP and IPFS, which is a decentralized, content-addressed storage. This allows fetching the metadata file of a contract over IPFS since the appended metadata hash is an IPFS hash.

Additionally, one can also retrieve the source code files over IPFS, as IPFS hashes of these files are also found in the metadata. A contract can be verified by providing the metadata file and source files over its API or the UI or using the plugins. Sourcify monitoring tool also listens to contract creations on new blocks and tries to verify the contracts if their metadata and source files are published on IPFS.

More on verifying contracts on Sourcify.


Tenderly is a platform aimed at accelerating workflow for Ethereum smart contract developers. It also offers source code verification as a service for developers.

You can choose to verify your contract with Tenderly by importing the source file or the metadata file generated by the Solidity compiler. Like other verification tools, Tenderly requires details like the contract address/network, compiler settings, and optimization features to verify any smart contract.

It is possible to verify a contract privately, making it visible only to you (and other members of your team). Verifying a contract publicly makes it visible to everyone using the Tenderly platform.

While useful for verifying contracts, Tenderly doesn’t have useful features available with other tools on the list. For example, it doesn’t allow end-users to check if a contract is verified (except the developers opt for public verification) and doesn’t check for a match between metadata hashes.

By this, you complete this workshop successfully!!