How to Verify a Smart Contract on Etherscan (2026 Guide)

Why Smart Contract Verification Matters

When you deploy a smart contract to Ethereum, the blockchain stores only the compiled bytecode -- a series of low-level instructions that the Ethereum Virtual Machine (EVM) can execute. This bytecode is public and anyone can see it, but it is virtually impossible for a human to read or audit.

Smart contract verification is the process of submitting your original Solidity source code to a block explorer like Etherscan, which then compiles it and confirms that the resulting bytecode matches what is deployed on-chain. Once verified, anyone can read the human-readable source code directly on Etherscan.

This matters for several important reasons:

Trust and Transparency

A verified contract tells your community, investors, and partners exactly what the code does. There are no hidden mint functions, no backdoor admin privileges, and no surprise fee mechanisms. In an ecosystem where scams and rug pulls remain a real concern, contract verification is one of the strongest signals of legitimacy.

DeFi Integration

Many DeFi protocols and aggregators prioritize or require verified contracts. If your token contract is unverified, some platforms may refuse to list it, display warning labels, or exclude it from routing algorithms. Verification removes friction from every integration your token might need.

Community Auditing

Once your contract is verified, any developer in the world can review the source code. This crowdsourced auditing is a powerful security benefit. Community members can flag potential issues, verify that the contract matches its documentation, and confirm that the project team's claims about token mechanics are accurate.

Etherscan Read/Write Interface

Verification unlocks Etherscan's interactive "Read Contract" and "Write Contract" tabs. These tabs let users interact with your contract directly from the Etherscan interface -- checking balances, reading configuration values, or executing functions -- without needing a custom frontend. This is especially useful during the early stages of a project before a full dApp is built.

Verified vs Unverified: What Users See

The difference between a verified and unverified contract on Etherscan is immediately visible:

Unverified Contract

• The "Contract" tab shows only raw bytecode
• No source code is visible
• No "Read Contract" or "Write Contract" interface
• A warning message states that the contract source code is not verified
• Users and investors often interpret this as a red flag

Verified Contract

• A green checkmark appears next to the "Contract" tab
• Full Solidity source code is displayed with syntax highlighting
• "Read Contract" tab shows all public view functions with interactive inputs
• "Write Contract" tab shows all public state-changing functions
• The compiler version, optimization settings, and license are all displayed
• Users can independently confirm the contract does what it claims

Method 1: Manual Verification on Etherscan

If you deployed your contract using Remix, Hardhat, Foundry, or another development tool, you can verify it manually through the Etherscan web interface.

Step 1: Gather Your Information

Before starting, you need:

• The deployed contract address on Ethereum mainnet (or the relevant network)
• The exact Solidity source code used for deployment
• The compiler version used during compilation (e.g., v0.8.24+commit.e11b9ed9)
• The optimization setting (enabled/disabled and the run count)
• The EVM version targeted during compilation (e.g., paris, shanghai)
• Constructor arguments if your contract's constructor accepts parameters (ABI-encoded)
• The license type (MIT, GPL, etc.)

Getting even one of these details wrong will cause verification to fail. The most common failure points are mismatched compiler versions and incorrect constructor arguments.

Step 2: Navigate to the Verification Page

1. Go to your contract's page on Etherscan (e.g., https://etherscan.io/address/0xYourContractAddress)
2. Click the Contract tab
3. Click Verify and Publish
4. Select your compiler type:
   • Solidity (Single file) if your contract is in one file with no imports
   • Solidity (Standard-Json-Input) for projects using Hardhat or Foundry (recommended)
   • Solidity (Multi-Part Files) if your contract imports from other files

Step 3: Submit Your Source Code

For Single File verification:

1. Paste your complete Solidity source code, including all imported contracts flattened into a single file
2. Select the exact compiler version
3. Set optimization to match your compilation settings
4. Enter the license type

For Standard JSON Input verification (recommended for complex contracts):

1. Export the Standard JSON Input from your build tool:
   • Hardhat: Run npx hardhat verify --network mainnet CONTRACT_ADDRESS CONSTRUCTOR_ARGS
   • Foundry: Run forge verify-contract CONTRACT_ADDRESS ContractName --chain-id 1 --etherscan-api-key YOUR_KEY
2. Alternatively, upload the JSON input file manually through the Etherscan interface

Step 4: Enter Constructor Arguments

If your contract's constructor accepts parameters, you need to provide them in ABI-encoded format. This is often the trickiest part of manual verification.

For example, if your ERC-20 constructor accepts a uint256 initialSupply parameter and you deployed with 1000000, the ABI-encoded argument would be:

00000000000000000000000000000000000000000000000000000000000f4240

You can use tools like HashEx ABI Encoder or Etherscan's own encoding tool to generate these values.

Step 5: Submit and Wait

Click Verify and Publish. Etherscan will compile your source code with the settings you provided and compare the resulting bytecode against what is deployed on-chain. If everything matches, your contract will be marked as verified within seconds.

If verification fails, Etherscan will display an error message indicating what went wrong. Common issues include:

• Compiler version mismatch: Make sure you selected the exact same version, including the commit hash
• Optimization mismatch: If you compiled with optimization enabled, verification must also use optimization (and the same run count)
• Incorrect constructor arguments: Double-check the ABI encoding of your constructor parameters
• Missing imports: For single-file verification, all imported code must be flattened into one file

Method 2: Programmatic Verification with Hardhat

If you use Hardhat for development, the @nomicfoundation/hardhat-verify plugin automates the entire verification process.

Setup

Install the plugin and add your Etherscan API key:

pnpm add -D @nomicfoundation/hardhat-verify

Add to your hardhat.config.ts:

import "@nomicfoundation/hardhat-verify";

const config: HardhatUserConfig = {
  // ... other config
  etherscan: {
    apiKey: {
      mainnet: process.env.ETHERSCAN_API_KEY!,
      base: process.env.BASESCAN_API_KEY!,
      arbitrumOne: process.env.ARBISCAN_API_KEY!,
    },
  },
};

Verify

After deployment, run:

npx hardhat verify --network mainnet 0xYourContractAddress "ConstructorArg1" "ConstructorArg2"

Hardhat automatically handles compiler version matching, optimization settings, and ABI encoding of constructor arguments. It submits the Standard JSON Input to Etherscan's API and waits for confirmation.

Method 3: Programmatic Verification with Foundry

Foundry's forge verify-contract command provides a similar automated experience:

forge verify-contract \
  0xYourContractAddress \
  src/MyToken.sol:MyToken \
  --chain-id 1 \
  --etherscan-api-key $ETHERSCAN_API_KEY \
  --constructor-args $(cast abi-encode "constructor(uint256)" 1000000)

Foundry reads your project's compiler settings and submits them along with the source code. You can also use forge create --verify to deploy and verify in a single command:

forge create src/MyToken.sol:MyToken \
  --rpc-url $RPC_URL \
  --private-key $PRIVATE_KEY \
  --constructor-args 1000000 \
  --verify \
  --etherscan-api-key $ETHERSCAN_API_KEY

Method 4: Automatic Verification with PresaleHub

If you deploy your token through PresaleHub, verification is handled entirely for you. There is nothing to configure, no API keys to manage, and no commands to run.

Here is how it works:

1. You configure and deploy your token through the PresaleHub interface
2. Once the deployment transaction is confirmed, PresaleHub's backend automatically submits the verification request to Etherscan
3. The system matches all compiler settings, optimization flags, and constructor arguments exactly because it controls the entire compilation and deployment pipeline
4. Your contract is verified on Etherscan within minutes of deployment
5. You receive a direct link to your verified contract page

This automatic verification covers all supported block explorers, not just Etherscan. If you deploy on Base, your contract is verified on Basescan. On Arbitrum, it is verified on Arbiscan. The process is the same regardless of which chain you choose.

Automatic verification eliminates the single most common pain point in token deployment. No more debugging compiler version mismatches, no more ABI-encoding constructor arguments by hand, and no more waiting hours for manual verification submissions to be processed.

Learn more about PresaleHub's automated deployment and verification pipeline on our Features page.

Verification on Other Block Explorers

Etherscan is the most widely used block explorer for Ethereum, but other networks have their own explorers that support the same verification process:

• Basescan (base.blockscout.com or basescan.org) for Base
• Arbiscan (arbiscan.io) for Arbitrum
• Optimistic Etherscan (optimistic.etherscan.io) for Optimism
• PolygonScan (polygonscan.com) for Polygon

The verification process is essentially identical across all of these explorers. They all accept the same Standard JSON Input format and use the same compilation matching logic. If you verify on one, you can use the same source code and settings to verify on others.

Some block explorers also support Sourcify verification, which stores verified source code in a decentralized manner. Sourcify verification is complementary to Etherscan verification and provides an additional layer of transparency.

Common Verification Issues and Solutions

"Bytecode does not match"

This is the most common verification error. It means the compiled bytecode from your submitted source code does not match what is on-chain. Possible causes:

• Wrong compiler version: Even minor version differences (e.g., 0.8.24 vs 0.8.25) will produce different bytecode. Check your build tool's lock file for the exact version used.
• Optimization mismatch: If you compiled with runs: 200 but verify with runs: 0 (or vice versa), the bytecode will differ.
• Different source code: Any change to the source code, even adding a comment or changing whitespace in some cases, can affect the compiled output.
• Different EVM target: Compiling for shanghai vs paris produces different bytecode due to different opcode availability.

"Constructor arguments encoding mismatch"

Constructor arguments are appended to the deployment bytecode. If your ABI-encoded constructor arguments do not match what was actually used during deployment, verification will fail. Use cast abi-encode (Foundry) or an online ABI encoder to generate the correct encoding.

"Contract has already been verified"

This is not actually an error -- it means someone (possibly you) has already verified this contract. If you need to re-verify with different source code (e.g., after discovering the original verification used incorrect code), you will need to contact Etherscan support.

Proxy Contracts

If your contract uses the proxy pattern (ERC-1967), you need to verify both the implementation contract and the proxy contract separately. Etherscan has a specific "Is this a proxy?" option on verified proxy contracts that links the proxy to its implementation, allowing users to interact with the implementation's ABI through the proxy address.

Best Practices for Contract Verification

1. Verify immediately after deployment. Do not wait days or weeks. Verify as soon as your deployment transaction is confirmed. The longer a contract sits unverified, the more suspicion it attracts.

2. Use Standard JSON Input. This format captures all compiler settings automatically and is far less error-prone than single-file or multi-file verification.

3. Automate verification in your deployment pipeline. Whether you use Hardhat, Foundry, or a no-code tool like PresaleHub, make verification a mandatory step in your deployment process -- not an afterthought.

4. Verify on all relevant explorers. If your token is bridged to multiple chains, verify on every block explorer where your contract exists.

5. Keep your source code organized. Use clear file names, standard directory structures, and well-documented code. Once verified, this source code is public and represents your project's professionalism.

6. Include license headers. Specify your license (MIT, GPL, etc.) in both your Solidity files and the verification submission. This clarifies the legal terms under which others can view and reference your code.

Conclusion

Smart contract verification is not optional -- it is a fundamental requirement for any serious token project. Verified contracts build trust, enable DeFi integrations, and invite community scrutiny that strengthens your project's security posture.

If you prefer to handle verification yourself, tools like Hardhat and Foundry make programmatic verification straightforward. But if you want to eliminate the complexity entirely, PresaleHub automatically verifies every token contract it deploys across all supported chains and block explorers.

Ready to deploy a verified token contract? Visit PresaleHub to create your ERC-20 token with automatic Etherscan verification, or read our Security page to learn more about how PresaleHub keeps your deployments safe.