Verified contracts: what an explorer’s “verified” badge proves (and what it doesn’t)

Open almost any token or app contract on a block explorer and you’ll see a tab called Contract, often with a green check and the words “Source Code Verified.” It’s easy to read that badge as a safety rating. It isn’t one. This page explains what verification actually checks, the different kinds of match you might see, and the questions the badge can’t answer for you.

How it works: matching source code to bytecode

Developers write contracts in a language like Solidity, then compile them to bytecode, which is what the network actually runs. ethereum.org’s verification guide defines source code verification as checking that the published source compiles to the same bytecode that sits at the contract address. Its point is simple: “the advertised contract code may be different from what runs on the blockchain,” and verification is how anyone can check.

The same page draws a line worth remembering. Source code verification is not formal verification. Formal verification asks whether a contract behaves correctly. Source verification only asks whether the code you’re reading is the code that’s running. A verified contract can still have bugs, a fee you don’t like, or a function that lets an owner freeze or move funds. Verification just means you can read it.

Not all “verified” labels mean the same thing

Etherscan’s guide to verification types lists four states:

• Unverified. The default for every new contract. You only see bytecode, which almost nobody can read.
• Similar Match. Applied automatically when the bytecode matches a contract that was already verified elsewhere. Etherscan notes this does not take constructor arguments (the starting settings) into account, and the badge is yellow, with the matched address shown.
• Exact Match. The source code and the constructor arguments match what was deployed. Etherscan shows a green badge plus the full source and deployment details.
• Runtime Match. The code stored at the address matches the source, but the deployment code and constructor arguments weren’t checked, so “the original deployment details may differ.”

Other verifiers use their own words. ethereum.org explains full (or “perfect”) verification versus a partial match. Comments and variable names don’t change the bytecode, so two different source files can verify against the same contract. That means a dishonest deployer could publish source with misleading comments or names. Full verification closes that gap by also matching a fingerprint of the compiler’s metadata file, which the Solidity docs say is appended to the runtime bytecode by default. ethereum.org notes that partial matching is still the more common method.

Proxies: the address stays, the code behind it can change

Deployed code can’t be edited, but many contracts are built so their logic can be swapped. ethereum.org’s upgrade guide describes the proxy pattern. You interact with a proxy contract that holds the data, and it forwards each call to a separate logic contract, sometimes called the implementation. Swap the implementation, and the same address now runs different code.

Etherscan’s proxy explainer describes how its “Read as Proxy” and “Write as Proxy” tabs load the implementation contract. It also notes that if the implementation was upgraded, the check has to be re-run to pick up the new address. So a verified proxy tells you how calls are forwarded. It doesn’t tell you what the logic contract does today, or who is allowed to change it.

ethereum.org also describes timelocks, which put a delay on changes so users have time to leave if they disagree with an upgrade. Without one, the guide says, users have to trust developers not to make arbitrary changes without notice.

How to verify: read a contract page calmly

1. Start from an address you trust. Get the contract address from the project’s official docs that you opened yourself, not from a token in your wallet, a reply, or an ad. Copycat tokens can reuse a famous name and still be verified. See address poisoning and clipboard hygiene.
2. Read the match type, not just the color. Exact, Similar, Runtime, full, and partial each check different things. A Similar Match points to another contract, so check which one.
3. Check whether it’s a proxy. If there are proxy tabs, look at the implementation address and remember that it can change.
4. Look for admin powers. In the Read Contract tab, an owner, admin, or similar field tells you someone can call privileged functions. Pause, mint, blacklist, and upgrade functions are worth noticing.
5. Remember what the badge isn’t. It isn’t an audit, a security score, or an endorsement by the explorer. Unverified code isn’t automatically malicious either, but you’d be trusting something you can’t read.
6. Connect your wallet carefully. A verified contract can still request an unlimited approval. Read the prompt as described in how to read a wallet prompt.

What we will not do

We won’t rate contracts, projects, or tokens, and we won’t say whether any verified contract is “safe.” We won’t give trade or price commentary.

Related free docs

• How to read a blockchain transaction
• What is a token approval?
• How to read a wallet prompt
• Smart accounts and EIP-7702
• Common crypto scams to recognize

Sources

• ethereum.org — Verifying smart contracts (source vs formal verification; full vs partial match; metadata hash)
• Etherscan Information Center — Types of Contract Verification (Unverified, Similar, Exact, Runtime Match)
• Etherscan Information Center — Navigating the Contract Code tab (Code, Read, Write, and proxy tabs)
• Etherscan Information Center — Proxy Contracts (implementation contracts; re-running checks after upgrades)
• ethereum.org — Upgrading smart contracts (proxy pattern; timelocks)
• Solidity documentation — Contract Metadata (metadata hash appended to runtime bytecode)

Educational content only — not investment advice. This page explains contract verification as a literacy topic; it does not recommend any contract, project, tool, network, or asset to buy, sell, or hold.

← All docs