Contract verification is one of the most important post-deployment steps for any token project. When you verify a contract on Arbiscan, you're publishing the human-readable Solidity source code that corresponds to the deployed bytecode on-chain. Anyone can then read what your contract actually does — it's the difference between a black box and an open book. Verified contracts get a green checkmark on Arbiscan, dramatically increasing their perceived legitimacy. Unverified contracts are routinely flagged as suspicious by token scanner tools and cautious investors.

The good news: if you deployed your token using createarbitrumtoken.com, verification is typically handled automatically. But if you need to verify manually, or want to understand the process, this guide walks through every step. Verification is free and takes about 5 minutes.

What Verification Actually Does

Smart contracts are deployed as bytecode — a low-level encoding of instructions that the EVM understands. Bytecode is not human-readable. When you write Solidity and compile it, the compiler transforms your readable code into this bytecode. Verification reverses this process by submitting the original Solidity source and the compiler settings, which Arbiscan uses to reproduce the bytecode and confirm it matches what's deployed.

Once verified, Arbiscan stores your source code permanently. The "Code" tab on your contract page changes from showing raw bytecode to displaying the full, syntax-highlighted Solidity. Anyone can read it, audit it, and confirm there are no hidden backdoors. The "Read Contract" and "Write Contract" tabs become interactive — users can call functions directly through Arbiscan's UI without a separate frontend.

Auto-verification: createarbitrumtoken.com automatically submits verification to Arbiscan after deployment. If you see the green checkmark on your contract page shortly after deployment, verification was handled for you and you don't need to do anything else.

Before You Start Manual Verification

To verify manually, you'll need:

  • Your contract address on Arbitrum One
  • The Solidity source code used to deploy the contract
  • The compiler version used (e.g., v0.8.20)
  • The optimization settings (whether optimization was enabled and how many runs)
  • The constructor arguments (ABI-encoded) if your contract's constructor took parameters

Tokens deployed through createarbitrumtoken.com provide all of this information in the deployment confirmation. Save the deployment details at this point — they're needed for verification.

Step-by-Step Verification on Arbiscan

  1. Go to Your Contract on Arbiscan Navigate to arbiscan.io and paste your contract address in the search bar. Hit Enter. You'll see your contract's overview page, showing the transaction that created it and the current ETH/token balances.
  2. Click the "Contract" Tab Below the address and balance information, click the "Contract" tab. You'll see "Bytecode" with raw hex code. There will be a blue button or link saying "Verify and Publish." Click it.
  3. Select Verification Method Arbiscan offers three main verification methods: "Solidity (Single file)" — paste your entire Solidity code; "Solidity (Standard JSON Input)" — upload a JSON settings file; "Solidity (Multi-part files)" — upload multiple .sol files. For most tokens generated by createarbitrumtoken.com, "Solidity (Standard JSON Input)" is the most reliable method. Choose it.
  4. Select Compiler Version From the dropdown, select the exact compiler version that was used. This must match precisely — using v0.8.21 when the contract was compiled with v0.8.20 will fail. The deployment details from createarbitrumtoken.com include this information. Typical versions used are in the v0.8.x range.
  5. Upload or Paste Source Code For Standard JSON Input: upload the JSON file provided in your deployment package. For Single File: paste the complete Solidity code. Make sure you include all imported contracts — or use the "flatten" option in development tools like Hardhat or Foundry to produce a single flat file with all dependencies included inline.
  6. Set Optimization Settings If the contract was compiled with optimization enabled, set "Yes" and enter the number of optimization runs (commonly 200). If optimization was disabled, set "No." Mismatched optimization settings cause bytecode mismatch errors.
  7. Enter Constructor Arguments If your token contract takes constructor arguments (like name, symbol, supply), these need to be ABI-encoded. Arbiscan's interface often auto-detects these from the deployment transaction. If not, you can generate the ABI encoding using online tools or by examining your deployment transaction's input data.
  8. Submit and Wait Click "Verify and Publish." Arbiscan will attempt to compile your submitted code and compare the resulting bytecode to what's deployed. This takes 30 seconds to 2 minutes. If successful, you'll see a success message and your contract page will update with the green verified checkmark.

Deploy and Auto-Verify Your Token

createarbitrumtoken.com handles contract verification automatically after deployment. No manual steps needed.

🚀 Create Token Now

Common Verification Errors and Fixes

Bytecode Mismatch

This is the most common error. It means the bytecode generated from your submitted source doesn't exactly match what's deployed. Common causes:

  • Wrong compiler version — double-check the exact version (0.8.20, not 0.8.21)
  • Wrong optimization settings — optimizer enabled/disabled, or wrong run count
  • Missing imports — if using single-file mode, make sure all dependencies are included via a flatten tool
  • Wrong EVM version target (Arbitrum uses EVM compatible settings — use "default" or "paris")

Constructor Arguments Not Found

If Arbiscan can't auto-detect constructor arguments, you need to provide them manually in ABI-encoded format. You can find the raw constructor argument bytes by looking at the deployment transaction's "Input Data" on Arbiscan and extracting the bytes after the bytecode portion. Tools like abi.hashex.org can encode parameters for you.

Already Verified

Not actually an error — if you see "Contract Source Code Already Verified," your contract was already verified (possibly automatically by the deployment tool). Go back to the contract page and click the "Contract" tab to see the verified code.

What to Do After Verification

Once your contract is verified, you can do several useful things through Arbiscan:

  • Add a token logo: Arbiscan allows token deployers to submit a logo image that appears next to the token name in the explorer. This significantly improves the token's professional appearance.
  • Add token information: Submit your project website, social media links, and description to appear on the token page. Go to arbiscan.io/tokenupdate and fill in the form.
  • Share the verified contract link: Use the direct URL to your contract's Code tab as the canonical reference for your source code in project documentation.
  • Interact via Read/Write tabs: You can now call contract functions directly through Arbiscan's UI, useful for debugging and administrative tasks.

Alternative Verification Methods

Hardhat Verification Plugin

If you deployed with Hardhat, the @nomicfoundation/hardhat-verify plugin can verify automatically: npx hardhat verify --network arbitrumOne CONTRACT_ADDRESS "Token Name" "TKN" 1000000 18. This handles all compiler settings automatically from your Hardhat config.

Foundry Verification

Foundry's forge verify-contract command supports Arbiscan: forge verify-contract CONTRACT_ADDRESS src/Token.sol:Token --chain-id 42161 --etherscan-api-key YOUR_API_KEY. Get an Arbiscan API key from arbiscan.io/myapikey (free account required).

Via createarbitrumtoken.com

Tokens deployed through createarbitrumtoken.com are automatically verified in the same transaction batch. The platform submits the source and compiler metadata immediately after your deployment confirms. You don't need to take any additional steps.