Why verification matters
Unverified bytecode is a black box. Users cannot confirm you deployed audited OpenZeppelin patterns, cannot interact via the Read/Write Contract UI, and aggregators may flag your token. Verification publishes your Solidity source and compiler settings so anyone can reproduce the exact bytecode on-chain. Ethereum Toolset automates this immediately after a successful deploy.
- Transparency — users read inheritances and confirm no hidden mint or backdoor
- Interactability — Read/Write tabs for approve, delegate, stake, and vote
- Indexer compatibility — The Graph and block explorers decode events correctly
- Trust — verified contracts convert better in token launches and DAO onboarding
How auto-verification works on Ethereum Toolset
When you deploy through the Token Creator, NFT Creator, or contract templates, the platform submits a Standard JSON Input bundle to Etherscan's verification API. This bundle includes every source file (your contract plus all @openzeppelin imports resolved), compiler version, optimizer runs, and EVM target. Constructor arguments are ABI-encoded from the values you entered in the deploy form.
- Compiler version must match exactly — 0.8.24 ≠ 0.8.20
- Optimizer enabled/disabled and run count must match deploy settings
- Constructor args are appended to creation bytecode — Etherscan decodes and checks them
- Verification is per-network — Sepolia verification does not carry to mainnet
Constructor arguments
Constructor arguments are the most common verification failure. They are ABI-encoded and concatenated to the deployment bytecode. A wrong address, wrong order, or missing parameter produces bytecode that does not match even when source is correct.
- Copy constructor args from the deploy receipt in Ethereum Toolset — do not retype addresses
- Use the ABI Encoder to re-encode if you need to verify a manual deploy
- Addresses are left-padded to 32 bytes in the encoding
- Strings and arrays encode with offset headers — use tools, not hand encoding
// Example: Ownable ERC20 constructor args
// (address initialOwner)
// ABI-encoded (no 0x prefix when pasting manually):
// 000000000000000000000000<initialOwner without 0x>Standard JSON Input vs flattened source
Ethereum Toolset uses Standard JSON Input — the same format solc expects with all sources and remappings. Flattened single-file upload is a fallback for manual deploys but breaks when multiple files define the same name. Prefer the JSON path the platform generates automatically.
- Standard JSON includes remappings like @openzeppelin/=node_modules/@openzeppelin/
- Every imported file must be present — missing OpenZeppelin file causes partial match
- viaIR and evmVersion settings must match if you customized them
- Libraries linked at deploy time need separate library address entries on Etherscan
Verifying library-linked contracts
If your deploy linked external libraries (uncommon in Ethereum Toolset templates but common in advanced setups), Etherscan needs the library name and deployed address for each linked reference. Without them, the bytecode hash will not reconcile.
- Record library addresses from the deploy transaction's contract creation sub-traces
- Enter each library in the 'Contract Library Address' section on Etherscan verify form
- Library names must match the Solidity file contract name exactly
- Re-verify the main contract after libraries are verified
Manual re-verification steps
If auto-verification fails, open the contract on Etherscan, click 'Verify and Publish', and choose 'Solidity (Standard-Json-Input)'. Download the compiler input JSON from your Ethereum Toolset deploy log or rebuild from the same template version. Paste constructor arguments from the deploy receipt.
- Confirm the network — verifying on wrong chain always fails
- Match compiler patch version exactly (0.8.20 vs 0.8.20+commit.x)
- Paste constructor args without 0x prefix in the Etherscan form
- Wait 30–60 seconds after deploy — indexing lag can cause temporary failures
- If still failing, compare deployed bytecode length against local compile output
After verification
Verification unlocks the contract UI and enables token metadata updates. Complete these steps while your deploy is fresh.
- Confirm 'Read Contract' shows expected OpenZeppelin functions (owner, decimals, etc.)
- For tokens — submit logo and social links via Etherscan token update (requires verification)
- Pin the verified source link in your docs and GitHub README
- Share the Etherscan link, not just the address — users click through to source
- If you upgrade via proxy, verify both proxy and implementation separately