Smart Contract Verification on Block Explorers
A deployed contract without verification is a black box. Users see bytecode but not source code. Etherscan shows "Contract" instead of function names. No one can check that the contract does what's written in the documentation. For any public protocol, this is a reputation problem and a barrier to integrations — other protocols won't call a contract they can't verify.
How Verification Works
A block explorer accepts source code and compiler parameters, compiles locally and compares bytecode with what's on the chain. Match — contract is considered verified, source code is published.
The main issue: deterministic compilation. The Solidity compiler with the same input data and the same settings should produce identical bytecode. A mismatch in compiler version (0.8.19 vs 0.8.20), optimizer flags (runs: 200 vs runs: 999), file order, or metadata — and verification fails.
Verification Tools
Hardhat + hardhat-verify (formerly hardhat-etherscan). After deployment:
npx hardhat verify --network mainnet 0xCONTRACT_ADDRESS "arg1" "arg2"
The plugin automatically determines compiler version from hardhat.config.ts, collects Standard JSON Input and sends to Etherscan API. Works for Ethereum, Polygon, BSC, Arbitrum, Optimism and dozens of other networks — via etherscan.apiUrl configuration.
Foundry forge verify-contract — works similarly but via Standard JSON Input directly:
forge verify-contract 0xCONTRACT_ADDRESS src/MyContract.sol:MyContract \
--chain-id 1 \
--etherscan-api-key $ETHERSCAN_KEY \
--constructor-args $(cast abi-encode "constructor(address)" 0xADDR)
Sourcify — decentralized alternative. Stores verified source code on IPFS, supported by most modern explorers. Foundry supports deployment with simultaneous verification via Sourcify:
forge script Script --broadcast --verify --verifier sourcify
Common Verification Failure Reasons
- Compiler version mismatch: code has
pragma solidity ^0.8.0, deployed with compiler 0.8.21, on explorer you specified 0.8.0 - Optimizer settings don't match those used at deployment
- Contract uses libraries — they must be either inlined or deployed with addresses specified during verification
- Proxy pattern: the implementation is verified, but the explorer sees the proxy — additional verification of the proxy via "Is this a proxy?" on Etherscan
For proxy contracts (Transparent, UUPS), Etherscan supports verification via ABI proxy detection — click "Verify as proxy" after verifying both parts (proxy + implementation).
Timelines: 2-3 hours for standard contract verification, including diagnosing failure reasons and retry attempts.