What is the difference between a perfect match and a partial match?

A **perfect (full) match** means every byte of the on-chain code lines up with the recompiled source, **including the trailing metadata hash** that the Solidity compiler appends. A **partial match** means the runtime code matches, but the metadata bytes differ, usually because the developer uploaded slightly different source files than the ones used at deployment, even though the compiled behaviour is the same. Perfect is preferred, partial is still trustworthy for the logic but not for "this is the exact source the developer wrote".

Why does verification matter for trust?

Unverified contracts are **black boxes**. You can see what they do by sending transactions, but you cannot read the intent. Verification flips that: you can read every function, see access controls, spot back doors, and compare against a known good template. Most major audits, tokens, and DAOs require verification before they will be listed on aggregators like CoinGecko, DefiLlama, or 1inch. **No verification, no listing** is a sensible default for users too.

Who actually verifies, Sourcify or Etherscan?

Both, and they are independent. **Sourcify** is a **non-profit** initiative run by the Ethereum Foundation. It stores sources in a public IPFS-backed repository and verifies by recompiling and comparing the **metadata hash**. **Etherscan** runs a proprietary verification service per chain (Etherscan, Arbiscan, BscScan, etc.). A contract can be verified on one but not the other. This tool queries **Sourcify** because its API is fully open; if Sourcify says "verified", Etherscan usually agrees within hours.

Can a contract be re-verified later?

**Yes**, anyone can submit sources to Sourcify at any time, even years after deployment. As long as the sources recompile to the deployed bytecode, the entry appears. This is how community members verify orphaned contracts whose original deployer never bothered. There is no permission needed and no fee, and verification is **publicly contributable**, not gated by the contract owner.

What is the metadata hash that perfect-match verification compares?

When solc compiles a contract it appends a small CBOR-encoded blob to the end of the bytecode. That blob includes a **SHA-256 hash of the metadata.json** describing the compiler version, optimizer settings, and the exact source file contents. Even one whitespace change in any source file flips the hash. **Perfect match = metadata hash matches**, which is why it is a strong guarantee that the published sources are bit-identical to what was deployed.

Is the bytecode on chain really immutable?

**Yes for plain contracts.** Once deployed, the runtime code at an address cannot be modified: no admin key, no compiler can rewrite it. The only way to "change" a contract is to **deploy a new one and stop using the old one**, which is why proxies exist (see below). The exception is the rare **SELFDESTRUCT** opcode, which removes the code entirely but cannot replace it. So if a verified source matched today, it still matches in ten years.

Why is the ABI useful, and where does it come from?

The **ABI** is a JSON list of every function and event the contract exposes, with their argument types and selectors. Libraries like ethers, viem, web3.js, and web3.py need it to **encode calls** and **decode responses**. You can hand-write an ABI from the source, but the compiler generates one for free and embeds it in the metadata. This tool pulls that ABI straight from Sourcify so you never have to recompile yourself.

What are constructor args and why are they shown separately?

**Constructor args** are inputs the deployer passed **once** during deployment to initialise things like the initial admin address, the token name, the maximum supply, etc. They are appended to the deployment transaction and stored next to the bytecode. Verifying a contract requires recompiling the exact source AND knowing the exact constructor args; if either differs, the bytecode does not line up. Sourcify exposes them as a separate text file when available.

What about proxy contracts, why do they look weird?

A **proxy** is a thin contract that forwards every call to an **implementation contract** stored at a separate address. Common patterns are **EIP-1967** (transparent proxy), **UUPS**, and **diamond proxies**. The proxy itself often has a tiny verified source (just the forwarding logic), while the real behaviour lives in the implementation. To audit a proxy, you must verify the **implementation address** too: read the storage slot 0x360894... (EIP-1967) on the proxy, then run this tool on whatever address you find there. USDC, USDT and most modern tokens are upgradeable proxies for this reason.

YourDevToolsPro

Smart Contract Source Verifier

Paste an address, pick a chain, see whether the contract source is publicly verified on Sourcify.

LiveRuns in your browser

Paste a contract address and pick a chain. The server reads on-chain bytecode and checks Sourcify for matching source. You get Solidity files, the ABI, optimizer settings, and constructor args, each with a Copy button.

How it works

The server calls eth_getCode on the chosen chain's public RPC, then queries Sourcify's check-by-addresses and files/any endpoints. From metadata.json we extract the compiler version, optimizer settings, and ABI. Results are cached for one hour per chain:address. Limit 30 verifications per hour per IP.

What this tool does

Paste a smart contract address, pick a chain, and we check whether the deployed bytecode has a matching public source in Sourcify. You see the verification status at a glance: Fully verified, Partially verified, or Not verified. When a match exists, we pull every `.sol` file, the parsed ABI, the constructor args, and the compiler settings.

There is no API key and no wallet connect. The lookup runs on the server through public Sourcify endpoints and a chain RPC, so you can audit any contract on Ethereum, Optimism, Arbitrum, Base, Polygon, or BSC without installing anything.

How to use it

Paste a contract address in the input field. It must be `0x` followed by 40 hexadecimal characters.
Pick the chain the contract lives on. The same address can host different code on different networks.
Click "Verify". The server reads on-chain bytecode and asks Sourcify whether anyone has published matching source code.
Read the verification badge: green means a perfect match, amber means a partial match (metadata differs), red means no verified source was found.
Open the source files panel and click any file to expand it. Every block has a one-click copy button.
Scroll to the ABI to grab the interface description in JSON. This is what you paste into ethers, viem, or web3.py to talk to the contract.
If the contract had constructor args, they appear as a separate copyable block, useful for re-deploying the same contract on a testnet.
Use the sample chips (USDC, WETH, Uniswap V2 Router) if you just want to see how a fully verified contract looks.

When this is useful

Six common situations where checking source verification saves you from costly mistakes:

Before signing a transaction with a brand-new dApp: open the contract address, see whether the source is public, and skim the function you are about to call. Unverified contracts can do anything.
Auditing a token before adding it to a watchlist: a verified contract with a standard ERC-20 implementation is a much weaker scam signal than an unverified one with the same name.
Pulling the ABI for a contract you want to script against: no need to find the project's repo or guess function selectors. The ABI block is one click away.
Comparing two contracts that should be identical: paste each address in turn, scroll to the source files, and diff them locally. Perfect matches share the same metadata hash.
Verifying that a proxy implementation has not silently changed: read the proxy's source, find the implementation slot, then verify the implementation contract too.
Onboarding new engineers: open Uniswap V2 Router or USDC in the sample chips to show how a healthy verified contract looks in three seconds.

Questions and answers

When a developer deploys a smart contract, only the compiled bytecode lands on chain. The original Solidity is not there. Source verification means the developer publishes the Solidity files plus the exact compiler settings, somebody recompiles them, and the result is byte-for-byte identical to the on-chain code. From that moment on, anyone reading the explorer sees both the human-readable source and a proof it matches what is running. It is the closest thing crypto has to a public audit trail.

Related tools

ERC-20 / Token Info Lookup

Paste a contract address, pick a chain, get name, symbol, decimals, and total supply straight from the blockchain.

TX hash detective

Paste a 0x transaction hash and see which EVM chain it lives on, who was the sender and receiver, how much gas it cost, and what tokens it moved. Auto-detects across six chains. No wallet, no API key.

Multi-chain address activity

Paste one 0x address and see the balance, transaction count, and USD value on six EVM chains: Ethereum, Optimism, Arbitrum, Base, Polygon, and BSC. No wallet, no sign-in.

Crypto address validator

Check whether a BTC, ETH, SOL, LTC or ADA address is valid before you send funds.

Smart Contract Source Verifier

Paste an address, pick a chain, see whether the contract source is publicly verified on Sourcify.

LiveRuns in your browser

Smart Contract Source Verifier

How it works

What this tool does

How to use it

Paste a contract address in the input field. It must be `0x` followed by 40 hexadecimal characters.
Pick the chain the contract lives on. The same address can host different code on different networks.
Click "Verify". The server reads on-chain bytecode and asks Sourcify whether anyone has published matching source code.
Read the verification badge: green means a perfect match, amber means a partial match (metadata differs), red means no verified source was found.
Open the source files panel and click any file to expand it. Every block has a one-click copy button.
Scroll to the ABI to grab the interface description in JSON. This is what you paste into ethers, viem, or web3.py to talk to the contract.
If the contract had constructor args, they appear as a separate copyable block, useful for re-deploying the same contract on a testnet.
Use the sample chips (USDC, WETH, Uniswap V2 Router) if you just want to see how a fully verified contract looks.

When this is useful

Six common situations where checking source verification saves you from costly mistakes:

Before signing a transaction with a brand-new dApp: open the contract address, see whether the source is public, and skim the function you are about to call. Unverified contracts can do anything.
Auditing a token before adding it to a watchlist: a verified contract with a standard ERC-20 implementation is a much weaker scam signal than an unverified one with the same name.
Pulling the ABI for a contract you want to script against: no need to find the project's repo or guess function selectors. The ABI block is one click away.
Comparing two contracts that should be identical: paste each address in turn, scroll to the source files, and diff them locally. Perfect matches share the same metadata hash.
Verifying that a proxy implementation has not silently changed: read the proxy's source, find the implementation slot, then verify the implementation contract too.
Onboarding new engineers: open Uniswap V2 Router or USDC in the sample chips to show how a healthy verified contract looks in three seconds.