Last updated
Last updated
Smart contract verification is the process of verifying that the smart contract bytecode uploaded to the network matches the expected smart contract source files. Verification is not required for contracts deployed on the Hedera network, but it is best practice and essential to maintaining the contract's security and integrity by identifying vulnerabilities that could be exploited, as smart contracts are immutable once deployed. It also enables transparency and builds trust within the user community by proving that the deployed bytecode matches the contract's original source code.
To initiate verification, you can use a community-hosted Hedera Mirror Node Explorer, like ( and do not currently support this feature), that integrates with : A Solidity source code and metadata verification tool. Once you upload your files to the verification tool, Sourcify recompiles the submitted source code and metadata files to check them against the deployed bytecode. If a match is found, the contract's verification status is updated to either a or a .
The verification status is publicly available across all community-hosted Hedera Mirror Node Explorers. To learn what differentiates a Full (Perfect) Match from a Partial Match, check out the Sourcify documentation .
Note: This is an initial beta release, and both the HashScan user interface and API functionalities are scheduled for enhancements in upcoming updates.
For verification, you will need the following items:
➡
➡
➡
This is the actual code for your smart contract written in Solidity. The source code includes all the contract's functions, variables, and logic. It's crucial for the verification process, where the deployed bytecode is compared to the compiled bytecode of this source code.
A simple HelloWorld
Solidity smart contract:
When you compile a Solidity smart contract, it generates a JSON metadata file. This file contains settings used when the smart contract was originally compiled. These settings can include the compiler version, optimization details, and more. The metadata file is crucial for ensuring that the bytecode generated during verification matches the deployed bytecode.
You have options for generating the metadata file. The recommended skill levels for each option are in parentheses. Choose the option that best fits your experience with smart contracts:
An example metadata file for the HelloWorld
smart contract:
Even though Hedera uses the 0.0.XXXXXXX
account ID format, it accommodates Ethereum's address format for EVM compatibility. Once your smart contract is deployed on Hedera's network, you'll receive an address like the one below. This serves as your deployed smart contract address.
An example deployed EVM smart contract address:
Note: The 0.0.XXXXXXX
smart contract address format can not be used in the verification process.
It's important to note that multiple instances of Sourcify do exist, tailored to the specific needs of different networks. Hedera runs an independent instance of Sourcify, distinct from the public-facing Sourcify.dev instances like Etherscan and other Etherscan clones.
Running an independent instance of Sourcify allows Hedera to have more control over the verification process, tailoring it to the custom needs of the Hedera ecosystem. For instance, after a testnet reset, Hedera requires the ability to reset testnet smart contract verifications - something Sourcify.dev cannot accommodate.
Verified Smart Contracts Testnet Reset: When the Hedera Testnet is reset, the contract must be redeployed and verified. The contract will receive a new contract EVM address and contract ID. The smart contract will need to be verified using the new addresses.
An essential detail to remember is that smart contracts verified on Hedera's Sourcify instance won't automatically appear as verified on Sourcify.dev or vice versa. Users interested in having their smart contract recognized across multiple platforms should consider verifying on both instances.
Learn how to verify your smart contract:
Metadata is not part of the EVM spec because it's handled externally by compilers and tools like Sourcify. See Sourcify's Metadata documentation .
See the Remix IDE docs for more detailed documentation .
To create the .json
metadata file with Hardhat, compile the contract using the npx hardhat compile
command. The compiled artifacts will be saved in the artifacts/
directory and the <dynamic_hash>.json
metadata file will be under artifacts/build-info
and used for verification. See Sourcify Hardhat metadata documentation .
To create the metadata file with Foundry, compile the contract using the forge build
command. The compilation outputs to out/CONTRACT_NAME
folder. The .json
file contains the metadata of the contract under "rawMetadata"
and "metadata"
fields. However, you don't need to extract the metadata manually for verification. See Sourcify Foundry metadata documentation .
➡
➡
➡
➡
➡
➡