How to Verify Your Token Contract on Etherscan (2025 Step-by-Step Guide)

Complete guide to verifying your smart contract on Etherscan, Polygonscan, BSCScan, and other block explorers. Learn why verification matters for credibility and security.

Tutorial • Updated January 2025

Verifying your token contract on a block explorer like Etherscan is one of the most important steps after deploying your token. Verification makes your contract's source code publicly viewable, allowing anyone to audit it for security and legitimacy. This builds trust with potential investors and users.

In this comprehensive guide, we'll walk you through the entire verification process step-by-step, covering Etherscan (Ethereum), Polygonscan (Polygon), BSCScan (BNB Smart Chain), and other major block explorers.

Why Verify Your Contract?

🔒 Security & Trust

Users can review your contract code to ensure it's safe. Unverified contracts look suspicious and reduce credibility significantly.

✅ Credibility

Verified contracts display a green checkmark, signaling legitimacy. Essential for DEX listings and community trust.

📊 Better Analytics

Verified contracts show function names, events, and readable transaction data. Much easier to track and analyze.

🎯 Listing Requirements

Many platforms (CoinGecko, CoinMarketCap, DEXs) require or strongly prefer verified contracts before listing.

Prerequisites

Before verifying, ensure you have:

  • Deployed contract address on the target blockchain
  • Source code of your contract (if using no-code tools, they usually provide this)
  • Contract compiler version (e.g., Solidity 0.8.20)
  • Optimization settings (if optimized during compilation)
  • Constructor arguments (parameters used during deployment)
  • Wallet connected to block explorer (for authentication)

Step-by-Step: Verify on Etherscan (Ethereum Mainnet)

Step 1: Navigate to Your Contract

  1. Go to etherscan.io
  2. Search for your token contract address in the search bar
  3. Click on the contract address to view its page
  4. You'll see a "Contract" tab - click it
  5. If unverified, you'll see "Contract Source Code Not Verified"

Step 2: Click "Verify and Publish"

On the contract page, click the "Contract" tab, then click "Verify and Publish". This will take you to the verification form.

Step 3: Fill Out the Verification Form

You'll need to provide:

Compiler Type & Version

  • Compiler Type: Usually "Solidity (Single file)" or "Solidity (Standard JSON Input)"
  • Compiler Version: Must match exactly what was used to deploy (e.g., v0.8.20+commit.a1b79de6)
  • How to find: Check your deployment tool or compiler output

License

Choose the license for your code:

  • MIT License - Most permissive, commonly used
  • GPL-3.0 - Open source with requirements
  • Unlicense - Public domain
  • No License - All rights reserved

Recommendation: Use MIT License for transparency and trust.

Source Code

Paste your complete contract source code. If using OpenZeppelin contracts, you may need to use "Standard JSON Input" format.

Optimization

  • Was optimization enabled? (Yes/No)
  • Runs: If yes, how many optimization runs (usually 200 or 10000)
  • Must match exactly your deployment settings

Constructor Arguments

If your contract has a constructor with parameters, you need to provide them. Some tools can auto-encode these for you.

Step 4: Submit for Verification

  1. Double-check all information matches your deployment
  2. Click "Verify and Publish"
  3. Wait for processing (usually 30 seconds to 2 minutes)
  4. If successful, you'll see a green checkmark ✅

Verification on Other Block Explorers

Polygonscan (Polygon)

  1. Go to polygonscan.com
  2. Search your contract address
  3. Click "Contract" tab → "Verify and Publish"
  4. Process is identical to Etherscan

BSCScan (BNB Smart Chain)

  1. Go to bscscan.com
  2. Search your contract address
  3. Same verification process as Etherscan
  4. Often faster approval time

Arbitrum, Optimism, Base

Each has their own block explorer:

All use similar verification processes to Etherscan.

Verification Methods

Method 1: Single File Verification (Simplest)

Best for simple contracts without imports:

  1. Select "Solidity (Single file)"
  2. Paste entire contract code
  3. Select compiler version
  4. Submit

Limitation: Doesn't work if your contract imports other contracts (like OpenZeppelin).

Method 2: Standard JSON Input (Recommended)

Required for contracts with imports (OpenZeppelin, etc.):

  1. Select "Solidity (Standard JSON Input)"
  2. Create a JSON file with:
    • Compiler settings
    • All source files
    • Libraries and dependencies
  3. Upload or paste JSON
  4. Submit

Tools to generate JSON: Hardhat, Truffle, or Remix can export this automatically.

Method 3: Via API (Advanced)

For automated verification in deployment scripts:

  • Use Hardhat's verify plugin
  • Use Truffle's verify plugin
  • Direct API calls to Etherscan API

Using No-Code Tools: Automatic Verification

Many no-code platforms handle verification automatically:

✅ Thirdweb

Automatically verifies contracts after deployment. No manual steps needed if using their platform.

✅ OpenZeppelin Contracts

Provides verified contracts by default. If deploying manually, use their verification guide.

✅ Remix IDE

Has built-in verification plugin. One-click verification after deployment.

Check your deployment tool's documentation - many handle verification automatically, saving you time.

Common Verification Issues & Solutions

Issue 1: "Compiler version mismatch"

Problem: Version doesn't match deployment.

Solution: Find exact compiler version from your deployment. Check Remix, Hardhat config, or deployment logs. Must match exactly (even patch versions matter).

Issue 2: "Optimization settings don't match"

Problem: Optimization enabled/disabled doesn't match.

Solution: Check your deployment settings. If you're unsure, try both (enabled/disabled) - one will work.

Issue 3: "Constructor arguments incorrect"

Problem: Constructor parameters don't match.

Solution: Use a constructor arguments encoder tool. Etherscan provides one, or use hashex.org or similar.

Issue 4: "Contract bytecode doesn't match"

Problem: Source code doesn't compile to same bytecode.

Solution: This usually means wrong compiler version, optimization settings, or missing source files (for JSON input). Double-check everything matches deployment exactly.

Issue 5: "Unable to locate ContractCode"

Problem: Contract not found or incorrect address.

Solution: Verify you're on the correct network (mainnet vs testnet) and using the correct contract address.

Advanced: Verifying Contracts with Dependencies

If your contract uses OpenZeppelin or other libraries:

Option 1: Flatten Contract (Simple but Large)

  1. Use a contract flattener tool
  2. Combines all imported contracts into one file
  3. Paste flattened code
  4. Verify as single file

Tools: Hardhat flatten plugin, Truffle flatten, or online flattener.

Option 2: Standard JSON Input (Better)

  1. Export compilation output from your build tool
  2. Include all source files in JSON
  3. Upload JSON to Etherscan
  4. More reliable than flattening

Cost of Verification

Good news: Verification is completely free! You only pay gas fees if you need to redeploy your contract (which you shouldn't need to do just for verification).

The verification process itself costs nothing—it's just uploading source code and metadata to the block explorer.

Benefits After Verification

1. Green Checkmark Badge

Your contract page shows a green checkmark ✅ indicating verified status. This is immediately visible to anyone viewing your contract.

2. Readable Contract Tab

Instead of bytecode, users see:

  • Human-readable source code
  • Function names (not just addresses)
  • Comments and documentation
  • Ability to read and interact with functions

3. Enhanced Analytics

Verified contracts show:

  • Function calls by name
  • Event logs with readable names
  • Better transaction decoding
  • Contract interactions page

4. Security Auditing

Users and auditors can:

  • Review your code for vulnerabilities
  • Verify no hidden functions or backdoors
  • Check tokenomics and supply mechanisms
  • Build trust through transparency

Best Practices

1. Verify Immediately After Deployment

Don't wait! Verify as soon as your contract is deployed. This prevents confusion and shows professionalism.

2. Use Proven Contracts

If using OpenZeppelin or similar, verification is easier since these contracts are battle-tested and widely recognized.

3. Keep Deployment Records

Save:

  • Compiler version
  • Optimization settings
  • Constructor arguments
  • Source code files

This makes verification much easier later.

4. Test Verification on Testnet First

Deploy and verify on testnet (Goerli, Sepolia, Mumbai, etc.) first to practice the process before mainnet.

5. Add Comments to Your Code

Well-commented code builds more trust. Users can understand your contract's purpose and functions.

What If Verification Fails?

Don't panic! Here's a systematic approach:

  1. Check error message carefully - It usually tells you what's wrong
  2. Verify compiler version - Most common issue
  3. Check optimization settings - Second most common
  4. Try different verification methods - Single file vs JSON input
  5. Flatten contract - If using imports
  6. Contact support - Block explorers have help forums
  7. Use automated tools - Hardhat/Truffle plugins often work better

Alternative Verification Tools

If Etherscan verification is problematic, consider:

  • Hardhat Verify Plugin: npx hardhat verify --network mainnet CONTRACT_ADDRESS
  • Truffle Verify Plugin: Similar automated verification
  • Sourcify: Decentralized verification alternative
  • Remix Verification Plugin: Built into Remix IDE

FAQ: Contract Verification

Do I need to verify my contract?

Highly recommended! While not technically required, unverified contracts look suspicious and reduce trust significantly. Most serious projects verify.

Can I verify if I used a no-code tool?

Yes! Most no-code tools provide the source code. If they don't automatically verify, you can manually verify using the code they provide.

What if I don't have the source code?

You can't verify! You must have the original source code. This is why it's crucial to save your code when deploying. If using no-code tools, download or save the source code they generate.

How long does verification take?

Usually 30 seconds to 5 minutes! Most verifications are instant or very fast. Complex contracts with many dependencies might take longer.

Can I verify on multiple networks?

Yes! Each network has its own explorer. Verify on Etherscan for Ethereum, Polygonscan for Polygon, etc. You need to verify separately for each network where your contract is deployed.

Is my code public after verification?

Yes! Verification makes your source code publicly visible. Anyone can view, copy, and analyze it. This is intentional—transparency builds trust. If you need private code, don't verify (but this reduces credibility).

Conclusion

Verifying your token contract is a crucial step that takes only minutes but provides significant benefits:

  • ✅ Builds trust and credibility
  • ✅ Required or preferred by most listing platforms
  • ✅ Allows users to audit your code
  • ✅ Makes your contract more accessible and understandable
  • ✅ Completely free (no cost except your time)

If you used a no-code tool, check if they verified automatically. If not, follow this guide to verify manually. The process is straightforward, and the benefits are immense.

Haven't Created Your Token Yet?

Learn how to create your token first, then verify it using this guide.

Step-by-Step Token Creation Guide →

Compare Token Generator Tools →