How to Verify Your Smart Contract on Etherscan: A Complete Guide

You've deployed your smart contract. Maybe you used Remix, Hardhat, or a no-code tool — either way, the contract is on-chain and you're looking at its address on Etherscan. But there's a problem: the Code tab shows nothing but raw bytecode. A wall of hexadecimal that means absolutely nothing to anyone trying to trust your project.

That's what an unverified contract looks like. And for most investors and users, that's a red flag that stops them in their tracks.

This guide covers everything you need to know about verifying your smart contract on Etherscan — why it matters, exactly how verification works under the hood, three different methods to do it, and how to diagnose every common error. Whether you're working with OpenZeppelin or writing raw Solidity, by the end of this you'll know exactly what to do.

Why Contract Verification Matters

Let's be blunt about this: an unverified contract is a serious liability for any legitimate project. It doesn't mean your contract is malicious — but it means no one can prove it isn't. That's a distinction that matters enormously to investors, traders, and anyone thinking about interacting with your token.

When a contract is unverified on Etherscan, visitors see a "Contract Source Code Not Verified" warning and a blob of bytecode. That's it. There's no way to read the logic, no way to confirm the token has the properties you claimed, no way to check whether there's a hidden mint function or an owner backdoor. You're essentially asking people to trust you blindly — and in DeFi, blind trust has burned a lot of people.

The history of rug pulls and exit scams is littered with unverified contracts. Developers who never intended to stick around had no reason to verify — verification is a commitment to transparency. Projects like Squid Game token (before it rugged) deployed contracts that were either unverified or minimally audited. The pattern is consistent enough that experienced traders treat unverified contracts as a default negative signal. Many won't even look at a token that hasn't been verified.

On the flip side, that green checkmark on Etherscan does real psychological work. It signals that the developer is willing to be scrutinized. It means tools like Uniswap's interface, DEXTools, and trading bots can properly read your contract's functions. It means investors can interact directly with your contract through Etherscan's Read and Write tabs without needing to trust a third-party frontend.

For anyone who's gone through the trouble of creating a proper ERC-20 token, skipping verification is leaving the most important trust signal on the table. Don't do it.

How Etherscan Verification Works

The mechanics of verification are worth understanding because they explain why certain things go wrong during the process.

When you deploy a smart contract, the Solidity compiler takes your source code and produces bytecode — machine-readable instructions that the Ethereum Virtual Machine can execute. This bytecode is what gets stored on-chain. When Etherscan verifies your contract, it's doing something elegant: it takes your submitted source code, compiles it using the exact same compiler version and settings you used originally, and then compares the resulting bytecode to what's already on-chain. If they match, verification succeeds.

This is called deterministic compilation. Given the same inputs — same source code, same compiler version, same optimization settings — the Solidity compiler always produces the same bytecode output. That's the mathematical guarantee that makes verification trustworthy. Etherscan isn't just taking your word for it; it's independently reproducing your compilation and confirming the result matches.

The key implication is that any deviation from your original compilation parameters will cause verification to fail. Used compiler version 0.8.19 but submitted 0.8.20? Fail. Had optimizer runs set to 200 but submitted with 0? Fail. Even minor differences in how imports are resolved can break the match. This is why getting the parameters right matters so much — we'll dig into specific errors later.

Etherscan also stores the verified source code in a way that's publicly auditable. Once verified, your source code is indexed, searchable, and permanently associated with that contract address. Anyone can read it, and it can never be changed (the contract itself is immutable — no one can swap out the code after deployment).

What You Need Before Verifying

Before you start the verification process, gather these pieces of information. Having them ready will save you from a frustrating back-and-forth.

The contract address. The Ethereum address where your contract was deployed. This is what you'll look up on Etherscan to begin verification.

Exact Solidity compiler version. Not approximately — exactly. If you compiled with 0.8.19, you need 0.8.19. Check your Remix settings, your hardhat.config.js, or your foundry.toml. This is the single most common source of verification failures.

Optimization settings. Did you compile with the optimizer enabled? If so, how many runs? The default in Hardhat is 200 runs. In Remix, optimization is off by default. You need to match exactly what you used when deploying.

Constructor arguments, ABI-encoded. If your contract's constructor takes any parameters (like a token name, symbol, or initial supply), these need to be submitted in ABI-encoded hex format. We'll cover how to generate these in the constructor arguments section below.

Contract name. If your source file contains multiple contracts, you need to specify which one is the deployed contract. This is the contract name as it appears in your Solidity code — not the file name.

Complete source code. Either a flattened single-file version of your contract, or all files in the correct structure for standard JSON input. If you're using OpenZeppelin imports, you'll need to handle those carefully.

Method 1: One-Click Verification with ERC Token Creator

If you're looking for the simplest possible path to a verified contract, this is it. When you create an ERC-20 token using ERC Token Creator, verification is handled automatically as part of the deployment process. You don't need to touch the Etherscan UI or fiddle with compiler settings — it just happens.

Here's how the flow works: the tool generates your Solidity source code based on your chosen parameters — name, symbol, supply, decimals, and any features like mintability or burnability. It compiles the contract with known, consistent settings. When it deploys to the network you've selected, it simultaneously submits the source code, compiler version, and optimization settings to Etherscan's verification API. Within a minute or two, your contract shows as verified.

This matters because one of the most frustrating parts of manual verification is reconstruction — figuring out after the fact exactly which compiler version and settings were used. When the deployment and verification happen together from the same system, there's no reconstruction needed. The tool knows exactly what it used because it just used it.

For anyone who's ever spent an hour debugging a verification failure only to realize they used compiler 0.8.18 instead of 0.8.19, automatic verification is genuinely valuable. The ERC-20 token creator handles all of this in the background so you can focus on actually launching your project rather than debugging hex strings.

The resulting contract will show the green verified checkmark on Etherscan, with full source code visible, and the Read/Write Contract tabs enabled. Everything a legitimate project needs.

Method 2: Manual Verification via Etherscan UI

If you deployed your contract yourself and need to verify it manually, the Etherscan UI is the most accessible option. Here's the step-by-step process.

Step 1: Go to your contract page on Etherscan. Search for your contract address at etherscan.io. You should land on a page showing transaction history for that address. Click the "Contract" tab.

Step 2: Click "Verify and Publish". If the contract is unverified, you'll see a prompt that says "Are you the contract creator?" with a "Verify and Publish" link. Click it.

Step 3: Select your verification method. Etherscan offers three options: Single File, Standard JSON Input, and Solidity Multi-Part files. For most cases, Single File (using a flattened contract) is the simplest. Standard JSON Input is more reliable when you have complex import structures.

Step 4: Fill in compiler details. Select the exact compiler version you used. Toggle the optimization setting — if you used it, set the runs count to match. If you used EVM version specification in your config, set that too. These need to be pixel-perfect matches to what produced your deployed bytecode.

Step 5: Paste your source code. If you're using the Single File method, paste your entire flattened contract into the text area. This means all imports need to be inlined into one file — more on how to do that in the flattening section.

Step 6: Add constructor arguments if needed. If your constructor takes parameters, paste the ABI-encoded hex string in the Constructor Arguments field. Don't include the "0x" prefix — just the hex data itself.

Step 7: Submit and wait. Click "Verify and Publish". Etherscan will compile your code and compare the result to the deployed bytecode. This usually takes 30-60 seconds. If successful, you'll see a confirmation page. If it fails, you'll get an error message — see the common errors section for how to diagnose them.

One thing worth noting: Etherscan has a reCAPTCHA on the verification form, so this process can't be easily automated without using the API. For one-off verifications it's fine, but if you're deploying frequently you'll want Method 3.

Method 3: Etherscan API Verification

For developers who deploy contracts programmatically — through Hardhat scripts, Foundry, or custom deployment pipelines — the Etherscan API approach is far more practical than the UI. You can integrate verification directly into your deployment workflow so it happens automatically every time.

You'll need an Etherscan API key, which you can get for free by creating an account at etherscan.io and navigating to your API settings. The free tier allows up to 5 calls per second, which is more than enough for contract verification.

With Hardhat: Install the hardhat-etherscan plugin (now merged into hardhat-verify). Add your API key to your hardhat.config.js under the etherscan object. After deploying, run npx hardhat verify --network mainnet DEPLOYED_ADDRESS "constructor_arg1" "constructor_arg2". The plugin handles source code collection, flattening (or using standard JSON), and API submission automatically.

With Foundry: Foundry has built-in Etherscan verification via the forge verify-contract command. Pass your contract address, contract name, API key, and constructor arguments. Foundry also supports the --watch flag to poll for verification status. Many developers use forge script with the --verify flag to deploy and verify in a single command.

The API approach is especially useful for testnet deployments where you're iterating quickly. You can bake verification into your CI/CD pipeline so every deployed version is automatically verifiable. This is standard practice for any serious development team working on ERC-20 tokens with complex logic — especially when you're following security best practices that include transparent, auditable code.

How to Flatten Your Solidity Contract

Most non-trivial Solidity contracts use imports. If you're creating an ERC-20 token using OpenZeppelin, your contract probably has lines like import "@openzeppelin/contracts/token/ERC20/ERC20.sol"; at the top. When you submit for manual verification using the Single File method, Etherscan needs all of that code in one file — it can't fetch imports from npm or GitHub.

Flattening is the process of taking your multi-file project and combining everything into a single self-contained Solidity file. Here's how to do it with the main tools.

With Hardhat: Run npx hardhat flatten contracts/YourToken.sol > YourToken_flat.sol. This recursively resolves all imports and outputs a single file. Open the flattened file and check for duplicate SPDX license identifier comments — this is the most common issue. Each imported file might have its own // SPDX-License-Identifier: MIT line, and the Solidity compiler complains about duplicates. Keep the first one and remove all subsequent occurrences.

With Truffle: Use the truffle-flattener package. Run npx truffle-flattener contracts/YourToken.sol > YourToken_flat.sol. Same SPDX warning applies.

In Remix: Remix has a built-in flattener plugin. Install it from the Plugin Manager, then right-click your contract file and select "Flatten". Remix handles SPDX deduplication automatically.

An alternative to flattening is using Standard JSON Input, which is what Etherscan calls its structured multi-file verification format. Hardhat can generate this automatically. This approach is more robust for complex projects because it preserves the original file structure — no flattening required, no SPDX issues. The tradeoff is that the JSON file can be harder to generate manually.

Handling Constructor Arguments

Constructor arguments are one of the most common reasons verification fails, especially for beginners. Here's what you need to know.

When you deploy a contract that takes constructor parameters, those values get ABI-encoded and appended to the deployment bytecode. Etherscan needs you to provide those same values, also ABI-encoded, so it can reconstruct the exact deployment transaction.

ABI encoding turns your human-readable values into a specific hex format. For example, if your constructor takes a string "MyToken", a string "MTK", and a uint256 1000000, the ABI-encoded representation is a specific 192-byte hex string — not just those values concatenated.

The easiest way to get the correct ABI-encoded constructor arguments is to look at your deployment transaction. On Etherscan, go to the transaction that created your contract. Click "More Details" and look at the Input Data field. The constructor arguments are appended at the end of the bytecode — everything after the compiled contract code. Etherscan's verification form even has a helper link that can decode these from your transaction automatically.

You can also use Etherscan's online ABI encoder tool at abi.hashex.org or use the ethers.js library in a script: ethers.utils.defaultAbiCoder.encode(['string','string','uint256'], ['MyToken','MTK','1000000']). The result (minus the "0x" prefix) is what you paste into the Constructor Arguments field.

If your contract has no constructor arguments — which is common for simple ERC-20 tokens where name and symbol are hardcoded — leave this field blank.

Common Verification Errors and How to Fix Them

Verification failures can be frustrating, especially when the error messages aren't always clear. Here are the five errors that account for the vast majority of failures, and how to resolve each one.

Error 1: "Compiler version mismatch" — The bytecode on-chain was produced by a different compiler version than what you submitted. This happens more often than you'd think, especially in Remix where the active compiler version can drift. Fix: Check your original deployment transaction, look at the bytecode for the compiler metadata (it's embedded in the bytecode), or check your config files carefully. Match the version exactly — including patch version.

Error 2: "Optimization settings do not match" — You compiled with optimization enabled but submitted with it disabled (or vice versa), or the runs count is wrong. Fix: Check your Hardhat or Foundry config. In Remix, check the Solidity compiler settings panel. The optimizer runs value matters — 200 is not the same as 1000.

Error 3: "Invalid constructor arguments" — The ABI-encoded constructor arguments don't match what was used in deployment. Fix: Pull the correct values from your deployment transaction's input data as described above. Make sure you're not including the "0x" prefix. Also check that the types match exactly — a uint256 and a uint are different in ABI encoding.

Error 4: "Wrong contract name" — If your source file contains multiple contract definitions, you need to specify the right one. Fix: Look at your Solidity file and use the exact name of the contract that was deployed — case-sensitive. For example, if your contract is contract MyERC20Token, enter exactly "MyERC20Token".

Error 5: "Import path resolution failed" or "File not found" — This happens when using the multi-file method and Etherscan can't find an imported file, or when the import paths in your flattened file are still present. Fix: Use the flattened single-file approach and make sure all imports are resolved. Alternatively, use Standard JSON Input which handles the file mapping explicitly. If you're verifying a contract created using OpenZeppelin, make sure all OZ files are included in your flattened output.

What Happens After Verification

Once verification succeeds, things change pretty noticeably on your contract's Etherscan page. That "Contract Source Code Not Verified" warning disappears. The Code tab now shows your complete Solidity source code, formatted and syntax-highlighted. Two new tabs appear: Read Contract and Write Contract.

The Read Contract tab lets anyone call your contract's view and pure functions directly from Etherscan without any wallet required. They can check the token name, symbol, total supply, balances, allowances — everything that's publicly readable. This is important for investor confidence. People can verify the token details without needing to interact with any frontend you control.

The Write Contract tab lets wallet-connected users call state-changing functions directly on Etherscan. For ERC-20 tokens, this means transfers, approvals, minting, burning — any function your contract exposes. This is useful for power users and for situations where your frontend might be down.

Beyond Etherscan itself, verification unlocks a cascade of benefits. When you go to list your token on Uniswap, the interface can read your contract's ABI to properly display the token. DEXTools, DexScreener, and similar charting platforms can fully index your token's functions. Security audit tools like TokenSniffer get much better signal from verified contracts. And most importantly, wallet providers like MetaMask can show proper transaction details when users interact with your contract — instead of just showing a raw hex data field.

The green checkmark is more than cosmetic. It's a genuine infrastructure upgrade for your project.

FAQ

Getting your contract verified on Etherscan is one of the most important steps you can take for your token's credibility. If you haven't deployed yet and want the simplest possible path to a verified, production-ready token, create ERC-20 token online with automatic verification through our tool — you'll get a verified contract without touching any of this complexity yourself.