Pillar guide · audit applicability
Smart Contract Audit Verification: 7 Checks That Matter
Verify whether a smart contract audit is authentic, scoped to the right code, and still relevant to the deployed contract using seven evidence checks.
Reviewed 23 July 2026 · Primary sources linked below
Direct answer
A smart contract audit is relevant to a live contract only when the report is authentic, its reviewed source and scope are known, and that reviewed target can be connected to the code executing on-chain. Verification improves the quality of the evidence. It does not prove that a contract is safe.
Evidence workflow
What to check, in order
Find the original report
Start with the auditor's website, the protocol's official repository, or another first-party publication. A copied PDF or an auditor logo on a landing page is not enough by itself.
Evidence to keep: Original report URL, publisher identity, report date, and report hash when available.
Identify the reviewed source
Record the exact repository, commit, compiler settings, and any submodules or libraries named in the report. If the report does not identify a source snapshot, its applicability is hard to test.
Evidence to keep: Repository URL, commit hash, compiler version, optimizer settings, and linked libraries.
Read the scope and exclusions
List the contracts, functions, integrations, and assumptions that were included. Also record excluded modules, unresolved findings, and any review limitations.
Evidence to keep: In-scope files and functions, exclusions, severity table, and remediation status.
Resolve the live contract target
Confirm the chain and address users actually interact with. For an upgradeable system, inspect both the proxy and its current implementation rather than checking only the proxy address.
Evidence to keep: Chain ID, proxy address, implementation address, and reference block.
Compare source and runtime bytecode
Source verification links published source to deployed bytecode. Audit applicability needs an additional link from that deployed target back to the source version and scope reviewed by the auditor.
Evidence to keep: Runtime bytecode hash, verified source, build result, and explicit match classification.
Trace changes after the review
Check upgrades, implementation changes, critical configuration changes, and new integrations after the audit date. A valid old report can still be stale for the current deployment.
Evidence to keep: Upgrade events, implementation history, release commits, and the latest material change date.
Record controls and open gaps
Identify who can upgrade, pause, change oracles, move treasury assets, or alter other critical roles. Keep missing evidence visible instead of turning it into a positive verdict.
Evidence to keep: Admin map, multisig or governance evidence, timelocks, exit paths, and unresolved proof gaps.
Use the product
Check an exact chain and address
Use the public contract checker to query the Proof of Audits registry. A registry miss stays an evidence gap, not a vulnerability finding.
Open live contract checkSource ledger
Primary references and working records
Ethereum.org: Verifying smart contracts
Explains source verification, bytecode comparison, and full or partial matches.
Ethereum.org: Smart contract security
Explains why testing and auditing cannot find every issue.
ERC-1967: Proxy storage slots
Defines standard implementation, beacon, and admin storage slots.
Aave V4 public evidence record
Shows exact addresses, reference block, bytecode hashes, official report links, and open gaps.
Specific answers
Frequently asked questions
How do I verify a smart contract audit?
Confirm the report at an original source, identify the reviewed commit and scope, resolve the current chain and contract implementation, compare the deployed target with the reviewed source, and check for later changes.
Does verified source mean a contract was audited?
No. Verified source connects source code to deployed bytecode. An audit is a separate review with its own scope, date, findings, and reviewed source snapshot.
Does an audit prove a smart contract is safe?
No. An audit can reduce uncertainty within a defined scope, but it cannot guarantee that no vulnerability exists or that later deployments and upgrades remain covered.
What if the report does not name a commit?
Treat the source binding as unverified. Ask the protocol or auditor for the exact reviewed snapshot before claiming the report applies to deployed code.
Continue the cluster