How to Verify a Token Contract on Basescan
An unverified contract is a wall of hex. Verification is the free, off-chain step that puts the source code behind your token address — and it is the first thing anyone doing diligence on your launch will look for.
Short answer
Open your token on basescan.org, go to Contract → Verify and Publish, and submit the exact source that was compiled at deploy time together with the exact compiler version, optimizer setting and EVM version used to build it. The explorer recompiles and compares. It costs nothing and uses no gas. Tokens deployed through the CoinDevTools Base token creator are submitted for verification automatically after deployment — the settings table below is what you need if you ever have to finish it by hand.
What verification actually proves
When you deploy a contract, what lands on Base is compiled bytecode — machine instructions for the EVM. The Solidity you wrote is not stored on-chain and cannot be recovered from the bytecode in any readable form. Verification closes that gap from the other direction: you hand the explorer your source and the settings you compiled it with, the explorer compiles it itself, and if the output is byte-for-byte identical to what is deployed, it publishes your source against that address. The proof is the recompilation, not your say-so.
That is a narrower claim than most people hear. Verified means readable and honest about itself — the code on the page is the code that runs. It is not an audit. It does not mean the contract is fair, safe, or free of an owner-only mint function. Plenty of contracts that drained their holders were verified; the drain function was right there in the published source, and nobody read it. What verification removes is the excuse for not looking.
The practical consequences are immediate. A verified contract gets a Contract tab with the full source, plus Read Contract and Write Contract tabs that let anyone call view functions — total supply, owner, balances — straight from the browser. An unverified one gets a hex blob and a line that says the source code is not verified. Token-scanner tools, which most Base buyers now run before they buy anything, lean heavily on published source; without it they fall back to bytecode heuristics and report far less, far less confidently.
Why it matters more on Base than you would expect
Base made deployment cheap, and cheap deployment changed what buyers assume. When putting a token on-chain cost real money, a deployed contract carried some implicit commitment. On an L2 where the whole launch sequence costs a fraction of a dollar in gas, it carries none — anyone can deploy a hundred tokens in an afternoon, and the people buying know it. The result is a market that filters hard and filters fast, on whatever signals are cheap to check.
Verification is one of the two or three signals in that first pass, alongside whether ownership has been renounced and whether the LP is locked or burned. It is also the cheapest of them to satisfy: no gas, no waiting, no decision to make. Skipping it does not read as a deliberate choice to the person looking at your contract page. It reads as someone who did not know the step existed — which is exactly the profile of the launches they are trying to avoid.
The manual walkthrough
Open the contract on Basescan
Paste your token address into basescan.org and open the Contract tab. If it reads "Contract Source Code Not Verified", you have a compiled blob on-chain and nothing human-readable attached to it.
Choose the verification method
Solidity (Single file) works when the whole contract, including its imports, was flattened into one file before compiling. Solidity (Standard-JSON-Input) is the more reliable route for multi-file projects because the JSON carries the compiler settings with it.
Match the compiler version exactly
Pick the same solc version that produced the deployed bytecode, down to the commit hash. A token deployed through CoinDevTools was compiled with v0.8.24+commit.e11b9ed9.
Match the optimizer settings exactly
Optimizer enabled or disabled, and the runs value, both change the output bytecode. CoinDevTools compiles with the optimizer enabled at 200 runs and the EVM version set to shanghai.
Add ABI-encoded constructor arguments if your contract takes any
If the constructor accepted parameters, Basescan needs them ABI-encoded, without the 0x prefix. Contracts whose values were written into the source before compiling take no constructor arguments at all, so this field stays empty.
Submit and wait for the check
The explorer recompiles your source with the settings you gave and compares the result to the bytecode on-chain. A match publishes the source on the Contract tab, adds the Read and Write Contract tabs, and costs nothing — verification happens off-chain, so there is no gas.
Settings for a CoinDevTools-deployed token
Verification fails on mismatched settings far more often than on wrong source code. These are the exact values used to compile ERC-20 tokens created through this site on Base and Ethereum — copy them into the Basescan form field for field.
| Field | Value |
|---|---|
| Compiler type | Solidity (Single file) |
| Compiler version | v0.8.24+commit.e11b9ed9 |
| Open source licence | MIT |
| Optimization | Yes |
| Optimizer runs | 200 |
| EVM version | shanghai |
| Constructor arguments | None — values are written into the source before compiling |
| Base contract | OpenZeppelin Contracts v5.0.2 — ERC20 plus Ownable |
The contract itself is OpenZeppelin's ERC20 and Ownable from Contracts v5.0.2 — the same widely reviewed implementation thousands of production tokens use — with your name, symbol, decimals, supply and owner address written into the source before compiling. That is why the constructor arguments field stays empty: there is nothing to pass in at deploy time, because the values are already in the code.
When it fails, it is one of these
Bytecode does not match
The single most common result, and it almost always means a settings mismatch rather than a wrong source file. Work through the four inputs that change output bytecode: compiler version (including the commit hash), optimizer on/off, optimizer runs, and EVM version. One wrong runs value is enough to produce a completely different blob.
The source you are submitting is not the source that was deployed
If you edited the contract after deploying — even a comment, even whitespace inside a string literal — the recompiled bytecode diverges. Verify the exact file that was compiled at deploy time, not the copy you have been tidying up since.
Missing or wrongly encoded constructor arguments
Constructor arguments are appended to the deployment bytecode, so the explorer needs them in ABI-encoded form to reproduce it. They are not the human-readable values you typed; they are the hex encoding of them. If your deployment tool showed them, copy from there rather than re-encoding by hand.
Already verified, or verified as a Similar Match
Etherscan-family explorers automatically attach source to a contract whose bytecode matches an already-verified contract, and show it with a yellow badge naming the address it was matched to. It is genuinely useful — it is how factory-deployed and proxy contracts get readable source without each one being submitted — but it is a match against someone else's submission, and it ignores constructor arguments. Submitting your own source is what turns that into a full match of your contract.
Wrong chain or wrong API key
Base is chain ID 8453. If you are verifying programmatically, note that the Etherscan family retired its per-explorer V1 API endpoints in August 2025 in favour of a single multichain V2 endpoint where the chain is passed as a chainid parameter and one API key covers every supported chain. Scripts still pointed at the old per-chain host will fail regardless of how correct the source is.
The step you inherit from a launchpad, and the ones you do not
Tokens minted through a launchpad factory usually appear verified without anyone submitting anything. That is the Similar Match behaviour doing its job: every token the factory deploys shares one bytecode, the explorer has already seen a verified copy of it, and it attaches the same source to each new address with a yellow badge naming the contract it matched. Convenient, and worth understanding before you treat it as a reason to use a factory — it is one free step, and it is the only part of the launch it removes.
Deploying the contract yourself means the bytecode is yours alone, so verification is yours to do — automatically in the normal case here, manually with the table above if it does not complete. In exchange you own the contract outright, choose your own supply and decimals, build your own pool at your own opening price, and carry no protocol claim on your token's future trading. If you are weighing that trade specifically on Base, the Clanker alternative comparison lays out both shapes side by side.
Whichever route you take, verification is one item on a longer list. Renouncing ownership, locking or burning the LP, and getting the token indexed are separate steps with separate evidence, and buyers check them separately. The Base token launch checklist covers the full sequence in order.
Related
Deploy a Base token you can verify
Standard OpenZeppelin ERC-20, deployed from your wallet, submitted for verification automatically.
Create Base Token →FAQ
Does verifying a contract on Basescan cost gas?
No. Verification is an off-chain process: you send your source code and compiler settings to the explorer, the explorer recompiles it and compares the result against the bytecode already stored on-chain. Nothing is written to Base, so there is no transaction and no gas. It is free on Basescan, and free on every Etherscan-family explorer.
Does verified mean my token is safe?
No, and this is the most commonly misread badge in crypto. Verified means the published source matches the deployed bytecode — that what you can read is what is running. It is not an audit, not an endorsement, and says nothing about whether the code contains a mint function, a blacklist, or a transfer tax. A verified contract with an owner who can mint unlimited supply is still a verified contract. What verification does is make those properties readable instead of hidden, which is why the absence of it is a red flag even though the presence of it is not a guarantee.
What happens if I never verify?
The token still works. It trades, it transfers, it shows up in wallets and on aggregators once a pool exists. What you lose is the ability of anyone to check it. Basescan will show "Contract Source Code Not Verified", the Read and Write Contract tabs will not appear, and every experienced buyer who opens your contract page sees the same thing: a token whose creator did not do the one free step that lets people read the code. On Base, where deployment costs cents and the buyer pool is sceptical by default, that reads as carelessness at best.
What compiler settings did CoinDevTools use for my token?
Solidity v0.8.24+commit.e11b9ed9, optimizer enabled at 200 runs, EVM version shanghai, single-file source, MIT licence, and no constructor arguments — the name, symbol, supply, decimals and owner address are written into the source before compilation rather than passed to a constructor. CoinDevTools submits the contract for verification automatically after deployment, so in the normal case there is nothing for you to do. If the explorer did not complete it, those settings are exactly what you need to finish the job by hand.
Why do launchpad tokens already show as verified?
Because a launchpad deploys every token from the same factory, so each new token shares its bytecode with contracts the explorer has already seen. Etherscan-family explorers attach the existing source automatically in that case — the Similar Match behaviour — which is why factory-minted tokens tend to arrive readable with nobody having submitted anything. A token you deploy yourself has its own bytecode, so it needs its own verification. That is a real convenience difference, and it is worth knowing it is the only step you inherit by using a factory.
Is Basescan verification the same as verifying on Etherscan?
Mechanically, yes — Basescan is the Etherscan-family explorer for Base, with the same interface, the same verification form and, since the V2 migration, the same API surface with Base addressed as chain ID 8453. If you have verified a contract on Etherscan you already know how to do it here. The only real differences are the chain you point at and the explorer domain your buyers will be looking at.