Problem: Black box after deployment
After deploying a contract on mainnet, users see only bytecode. Etherscan shows "Contract" instead of function names. Other protocols won't call such a contract — too risky. An unverified contract may contain a backdoor or be swapped via proxy. Compilation configuration errors (version, optimization, metadata) lead to verification failure. We solve this problem at the system level: configure the environment, prepare the Standard JSON Input, and pass verification on the first try in 95% of cases.
How verification works?
The block explorer takes the source code and compiler parameters, compiles locally, and compares the bytecode with what's on the chain. Match — contract verified, source code published. The main requirement is deterministic compilation. The Solidity compiler, given identical input data and settings, must produce identical bytecode. A mismatch in compiler version (e.g., 0.8.19 vs 0.8.20), optimization flags (runs: 200 vs runs: 999), file order, or metadata — and verification fails. Documentation Solidity describes this mechanism in detail.
How to cut verification time by 3x?
Use Foundry instead of manually entering parameters on the explorer. forge verify-contract automatically builds the Standard JSON Input and sends it to Etherscan. According to our data, this reduces setup time from 30 minutes to 5. We prepared a comparison table of tools:
| Tool | Setup Speed | Proxy Support | Library Handling |
|---|---|---|---|
| Hardhat hardhat-verify | Medium (10 min) | Yes (via verify:true) | Requires address linking |
| Foundry forge verify-contract | High (5 min) | Yes (automatic detection) | Automatic linking |
| Sourcify | Medium (15 min) | Limited | Requires IPFS hash |
For simple contracts, Hardhat is sufficient; for complex ones with proxies and libraries, Foundry is 2x faster.
How we handle complex cases?
We have 7+ years in blockchain and over 50 successful verifications. We've dealt with proxy contracts (UUPS, Transparent), complex library chains, and flash loans. For each project we prepare a Standard JSON Input — this reduces error probability to zero. If the contract uses immutable variables or calldata with complex structures, we manually check constructor arguments. Verification via Foundry reduces setup time by 3x compared to manual parameter entry.
Why verification is important for security?
An unverified contract is a black hole for auditors. No serious audit will start without a verified status. Verification is the first step toward formal verification and static analysis (Slither, Mythril). Imagine: you find a bug, but the contract is unverified — you can't fix and redeploy. Saving on verification results in million-dollar losses from hacks. We guarantee that after our work, the contract passes any checks.
How to avoid common verification errors?
Typical errors and their solutions
| Cause | Solution |
|---|---|
| Compiler version mismatch | Specify exact version pragma solidity 0.8.19, on the explorer — the same |
| Optimization settings mismatch (runs) | Save solc config separately, use get-hardhat-config for logging |
| Using libraries without addresses | Specify linked library addresses during verification |
| Proxy contracts | First verify implementation, then proxy — click "Verify as proxy" on Etherscan |
| Metadata (metadata hash) | Add --metadata-hash none in solc or disable in hardhat |
For proxy contracts, Etherscan supports detection via ABI proxy detection — after verifying both parts, click "Is this a proxy?". We also connect @openzeppelin/contracts and use upgradeable patterns.
Verification tools
Hardhat + hardhat-verify (formerly hardhat-etherscan). After deployment:
npx hardhat verify --network mainnet 0xCONTRACT_ADDRESS "arg1" "arg2" The plugin automatically detects the compiler version from hardhat.config.ts, builds the Standard JSON Input, and sends it to the Etherscan API. Works for Ethereum, Polygon, BSC, Arbitrum, Optimism — via etherscan.apiUrl config.
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 source on IPFS, supported by most explorers. Foundry supports deployment with simultaneous verification:
forge script Script --broadcast --verify --verifier sourcify What's included in the work
- Full compilation configuration diagnostics
- Preparation of Standard JSON Input
- Verification on block explorer (up to 3 networks by default)
- If proxy — verification of both parts
- Retry attempts on errors (included in cost)
- Documentation on setup and deployment
- Consultation on best practices for gas optimization and security
Timeframe and cost
Timeframe: from 2 hours to 1 business day — depends on contract complexity (libraries, proxies, number of networks). Cost calculated individually. Order verification of your contract today — send a link to the contract on any network (Etherscan, Polygonscan, Arbiscan) and get an estimate within 1 hour. Get a consultation on verification setup — make your contracts transparent.
Contact us to discuss your project details — we'll respond within an hour.