Comparison guide · two different proofs
Smart Contract Audit vs Source Code Verification
Understand what a smart contract audit proves, what source code verification proves, and why deployed-code matching needs both evidence chains.
Reviewed 23 July 2026 · Primary sources linked below
Direct answer
Source code verification checks whether published source can reproduce deployed bytecode. A smart contract audit reviews a defined source snapshot for security issues. One does not prove the other, and neither automatically proves that an old report applies to the current implementation.
Evidence workflow
What to check, in order
Source verification answers a build question
It asks whether available source, compiler inputs, and metadata correspond to deployed bytecode. Full and partial match classifications describe the strength of that build relationship.
Evidence to keep: Verified source, compiler settings, constructor inputs, libraries, and bytecode match type.
An audit answers a scoped review question
It records who reviewed which source, when, with what method, and what findings or limitations resulted. The audit boundary can be narrower than the deployed system.
Evidence to keep: Auditor, reviewed commit, in-scope files, exclusions, findings, and review dates.
Audit applicability joins both evidence chains
The reviewed source must be connected to the live implementation at a defined block. Without that join, an authentic report and verified deployment can remain unrelated facts.
Evidence to keep: Reviewed commit to reproducible build to runtime bytecode to current implementation.
Upgrade history determines freshness
A proxy implementation can change while the proxy address remains constant. Each material implementation change needs a new applicability check.
Evidence to keep: Implementation history, upgrade events, release commits, and latest checked block.
Operational controls remain separate
A source match does not explain who can upgrade, pause, change oracles, or move treasury assets. Those powers need their own current evidence.
Evidence to keep: Admin slots, roles, multisig or governance controls, timelocks, and event history.
Use the product
See the distinction on a real deployment
The Aave V4 public record exposes observed runtime hashes and official report links while leaving the missing audit-to-commit mapping open.
Inspect the evidence recordSource ledger
Primary references and working records
Ethereum.org: Verifying smart contracts
Defines source verification and explains full and partial matches.
Ethereum.org: Smart contract security
Places audit work inside a broader security process.
OpenZeppelin Upgrades Plugins
Documents proxy, implementation, deployment, and upgrade validation concepts.
Proof of Audits code-match method
Shows the evidence classes used for live bytecode and implementation comparison.
Specific answers
Frequently asked questions
Is source code verification the same as an audit?
No. Source verification establishes a relationship between source and deployed bytecode. An audit is a security review of a defined source scope.
Can audited code be unverified on an explorer?
Yes. An audit can review private or unpublished source. That makes public deployment matching harder, but it does not mean the review did not occur.
Can verified source contain vulnerabilities?
Yes. Verification helps readers inspect the code that is deployed. It does not establish that the code is correct or free from vulnerabilities.
What is the strongest public evidence chain?
An original report tied to an exact source commit, a reproducible build tied to the current implementation bytecode, and current evidence for privileged controls and later changes.
Continue the cluster