Deployed vs Audited Code: What Bytecode Verification Found
Quick answer. In 25 deployed contracts from five public Guardian reports, 15 (60%) matched the final reviewed commit and 10 differed. Nine of the 10 come from one report; all 10 match later commits in the clients' own repositories.
Video transcript
An audit covers a commit. Users interact with whatever was deployed. We checked whether the two match.
In twenty five deployed contracts from five public Guardian reports, fifteen, or sixty percent, matched the final reviewed commit.
The misses are concentrated. Report A holds nine of the ten differences. Without it, fifteen of sixteen match.
Twelve of those matches include the reviewed fixes. Check them against the first round commit, and a correct deployment looks wrong.
Nine of the ten differences change logic, from a two line counter change to rewritten validation. One is formatting only. Six touch fewer than twenty five lines.
Each differing contract matches a later commit in the client's repository, written up to eighty five days after the final review. Whether anyone reviewed those changes is not in our data.
Use a release gate. Name the final commit, verify source at deployment, diff before you announce, follow the proxy, and check again after every upgrade.
For USDT0, Guardian matched deployed proxies, implementations and admins byte exact against the audited source. That work spans more than forty five engagements since February 2025. Risk Monitoring then flags new implementations as they land.
Read the full article for the method, or talk to Guardian about verifying your next deployment.
An audit covers a commit. Users interact with whatever was deployed.
We checked whether the two are the same, using only public data: Guardian's published reports, the clients' public repositories, and verified source on Sourcify and Blockscout.
Results are anonymized. Reports A to E are five reports from four clients, lettered by report date.
The sample is small, and concentrated: Report A holds nine of the 10 contracts that differ.
How We Compared
- Reports. Guardian's public portfolio data lists each report's repositories, review rounds, commits and in-scope files.
- Audited code. We read each in-scope file at every reviewed commit, from public repositories, with no credentials.
- Addresses. From deployment registries the protocols keep in those repositories.
- Deployed code. Verified source from Sourcify, or Blockscout where Sourcify had none. For proxies, the implementation the proxy points to now.
- Comparison. File contents with whitespace normalized. Where a file differed, we read the diff.
- Date. All reads on November 5, 2026 (UTC).
- Limits. 20 of the 25 are Sourcify partial matches, which allow comment and name differences. Formatting results are approximate; logic results are not affected.
How the sample narrowed
| Step | Count |
|---|---|
| Public Guardian reports | 320 |
| List in-scope files by repository | 72 |
| Reviewed commit readable in a public repo | 18 |
| Deployments found in a public registry | 10 reports, 48 contracts |
| Verified source found | 33 contracts |
| Compared with the final reviewed commit | 25 contracts, 5 reports |
Of the 48 contracts we located, 23 could not be compared:
- 15 had no verified source on Sourcify or Blockscout.
- 6 came from three reports that name no commit for their fix review.
- 2 run code written before the review began.
Match and Mismatch Rates
| Report | Contracts | Match | Differs | Report to deployment |
|---|---|---|---|---|
| A | 9 | 0 | 9 | 52 to 63 days |
| B | 4 | 4 | 0 | 102 days |
| C | 5 | 4 | 1 | 7 days |
| D | 6 | 6 | 0 | 32 days |
| E | 1 | 1 | 0 | 7 days before |
| Total | 25 | 15 | 10 |
- 15 of 25 contracts (60%) match the final reviewed commit.
- Three of five reports match in full. One matches 4 of 5, and one matches none of its 9.
- One report drives the rate. Without Report A, 15 of 16 match.
- Fixes shipped. 12 of the 15 matches would fail a check against the first-round commit, because they include the reviewed fixes.
That last point matters for anyone checking an audit. Compare against the final commit, or a correct deployment looks wrong.
What Differs
None of the 10 differences is a comment-only or parameter-only change.
- Formatting only (1): lint markers, an unused import removed and struct arguments written by name. Behavior is unchanged.
- Logic (9): the deployed contract does something the reviewed commit does not.
The logic changes ranged from small to large:
- A two-line change to when a counter increments.
- A failure path that now emits an event instead of reverting.
- An early return when a dependency is inactive.
- New input checks, a new role and rewritten validation in the largest contracts.
Six of the 10 change fewer than 25 lines of code. The largest adds or removes 339 lines, comments excluded.
Time Between Review and Deployment
Every differing contract matches a later commit in the client's own public repository. The deployed code was committed 3 to 85 days after the final reviewed commit.
- Report A: nine contracts from commits 75 to 85 days after the reviewed one, deployed 52 to 63 days after the report.
- Report C: one two-line change, committed three days after the reviewed commit and shipped a week after the report.
No later public Guardian report lists these files in scope. Whether another reviewer looked at the changes is not in our data.
Matching code shipped anywhere from a week before the report to 102 days after it. In Report E, the deployment landed the day the fix review ended.
Verification as a Release Gate
The differences in this sample are ordinary: a change after the last round, a formatting pass, a report with no fix-review commit. A release gate surfaces all three.
- Name the final commit. Six contracts here could not be checked because their reports list only the first round's commit.
- Verify source at deployment. 15 of 48 contracts had no verified source we could read.
- Diff before you announce. Compare each in-scope file with the final reviewed commit.
- Record later changes. Note whether each change after the last round was reviewed, and by whom.
- Follow the proxy. Check the implementation it points to now, not the one in the deploy script.
- Check again after every upgrade. A match today can break with the next one.
For when a change needs a new review, see when you need a re-audit and our upgrade change management process.
How Guardian Helps
Guardian verifies deployments as their own engagement. For USDT0, it has matched deployed proxies, implementations and admins byte-exact against the audited source.
That work spans more than 45 deployment, configuration and verification engagements since February 2025. Read the USDT0 deployment verification case study.
Risk Monitoring tracks every deployed address and whether the bytecode running today is the bytecode that was reviewed. New implementations surface as they land.
For multichain rollouts, see our guide to deployment verification.
Frequently Asked Questions
How often does deployed code match the audited commit?
In our sample of 25 contracts from five public Guardian reports, 15 (60%) matched the final reviewed commit. Three of the five reports matched in full; one report's nine contracts all differed.
What usually differs between audited and deployed code?
In this sample, logic. Nine of the 10 differences changed behavior, from a two-line change to rewritten validation. One was formatting only, and none was a comment or parameter change alone.
Does a mismatch mean the deployed code is unaudited?
Not necessarily. It means the deployed code differs from the commit the report names. Another review may have covered the change, so ask which commit it covered and compare again.
How can I check a deployment against an audit myself?
Take the final commit from the report and read the verified source on Sourcify or an explorer. Follow any proxy to its implementation, then compare the in-scope files with whitespace normalized.
Sources
- Guardian: Public audit portfolio and report data (read November 2026)
- Guardian: USDT0 Deployment and Configuration Verification
- Sourcify Docs: Exact Match vs Match
- Sourcify Docs: API, contract lookup (v2)
- Blockscout: Ethereum explorer, verified contracts
- Ethereum Improvement Proposals: ERC-1967, Proxy Storage Slots
Ship the code that was reviewed
Guardian verifies deployed proxies, implementations and configuration against the audited source.