Smart Contract Verification
Learn about Verification: how it works, difference between private and public verification and how to do it in Tenderly. Use the UI or code-based approaches, from zero-code to full-code solutions.
Contract verification allows web3 tools to decode the information about transactions and show it in a humanly-readable form. It's the cornerstone for building more sophisticated tools and and services around those smart contracts.
In Tenderly, verification is an essential step in enabling Debugger, Simulator, Web3 Actions, and other Tenderly features and ensuring they work seamlessly with your Smart Contracts.
Tenderly offers several methods of verification, bringing different levels of control, visibility, and flexibility. You can verify your contracts using the Dashboard or go for a code-based approach using hardhat-tenderly library or the CLI.
In the building phase, your Smart Contract can undergo private verification, so it’s visible only within your Tenderly project. When you’re ready to share your work, you can do a public verification, which makes the verified contract available to anybody who might interact or integrate with your Smart Contract.
When you deploy a Smart Contract on a network, you’re essentially deploying the bytecode produced by the Solidity compiler. No information about the originating Solidity code is preserved.
To verify a contract means to check if the Smart Contract source code compiles into the on-chain bytecode. If it does, we can say we verified that the bytecode comes from the provided source code, hence the name – verification.
After verifying Smart Contracts, it’s possible to link information about the execution back to the instructions in the original source code, enabling step-by-step debugging, decoding of Events and State Changes, Simulations and other Tenderly features.
In the verification process, Tenderly compares the deployed bytecode to the Solidity source code of a Smart Contract. The algorithm compiles the provided source code again and compares the generated bytecode to the deployed one. If the two sides match in every way, the contract is verified.
Verification requires the following arguments:
- The source code, including the source of all imports
- The version of the compiler used to produce the deployed bytecode
- Information about the number of compiler optimizations (if any)
- EVM version
If any of these pieces of information is wrong, the process of verification fails.
How Smart Contract verification works
When verifying Smart Contracts, you have to choose between two modes: private and public verification:
- Private verification shares your contract only with the team members in your project. This mode of verification is suitable during contract development.
- Public: access to your contract to all Tenderly users. This enables projects and developers who rely on your contract to understand fully how their transactions are executed. Choose the public mode once you're comfortable with sharing your contract with users outside your project.
- On a Tenderly Fork: The contract is verified and thus valid within the Fork you deployed it to.
When doing verification with Hardhat, contracts are verified as public by default. To verify a contract privately, you have to configure this explicitly.
Tenderly offers different ways to verify Smart Contracts, with each one bringing different levels of configuration flexibility and control.
The first way entails verifying Smart Contracts using the Tenderly Dashboard.
The second approach is code-oriented and entails verifying Smart Contracts using the Hardhat plugin. This approach offers automatic (no-code) verification, as well as manual verification through code.
The third approach is relying on Tenderly CLI, independent of the way you deployed your contracts.