To verify a contract, compile the published source with the same settings and compare the result with the bytecode at the deployed address. A match proves the source produces that code. It does not prove the code is safe, and it says nothing about whether the contract is correct.
What verification means
ethereum.org describes source code verification as comparing a smart contract's source code with the compiled bytecode used when the contract was created, to find differences. Verifiers recompile with the same settings and compare against the code at the address.
The moving parts
Compiler settings. Version, optimizer options and similar choices change the output. A mismatch in any of them breaks the comparison.
Constructor arguments. These are appended to the deployment data, so they must be included when checking that the deployed code matches.
Metadata hash. Solidity's metadata records compilation details and source file hashes, and its hash is appended to the bytecode. The documentation notes that if any compilation setting, or even a byte in one source file, changes, the metadata changes.
Full versus partial match. A full verification checks the metadata hash. A partial match does not. The page says partial matching is currently more common, so a partial match tells you less than the word verified suggests.
What it does not prove
- That the code has no bugs. Verification only shows what the code is.
- That the owner cannot change behaviour later, for example through an upgradeable proxy. If the address is a proxy, you must verify the implementation too and check who can change it.
- That the contract is correct. That is the job of formal verification, which the same documentation describes as a separate activity concerned with whether the contract behaves as expected.
A practical routine
- Find the deployed address and note whether it is a proxy.
- Check whether the match is full or partial.
- Read the verified source for admin functions and who holds them.
- If it is a proxy, locate the implementation and verify it as well.
- Compare against the audit report's commit, and confirm the audited version is the deployed one.
For your own releases, pin compiler versions, record settings in the repository, and publish verification as part of the deploy script. That also helps customers who want to check your work.
The same idea, proving an artifact came from known source, appears in software supply chains as reproducible builds and provenance. Safeguard's SBOM features record what went into a build, and a free scan is at gold.safeguard.sh/scan.
Quick check
Does verified source mean audited?
No. Verification shows the published source matches the deployed code. An audit is a separate review of whether that code is sound.
Why does a one byte change matter?
The metadata hash covers the source files and settings, so any change alters it and a full verification would fail.
Sources
Last reviewed: 19 October 2026.
