When Do You Need a Smart Contract Re-Audit?

By the Guardian team Updated November 2026 5 min read

Quick answer. Audit again whenever a change touches funds, permissions, pricing, liquidation, storage or upgrade logic, whatever its size; fixes count too. A diff audit usually covers it; a full re-audit is due after architecture changes or many stacked diffs.

Watch: When Do You Need a Smart Contract Re-Audit? 1:41

Video transcript

An audit covers one commit. Every change after it is code the auditors never saw.

In Guardian's published portfolio, 29 of 49 update reviews, 59 percent, found a Critical or High. The question is rarely whether a change needs review, but how much.

Review any change that moves funds or touches value logic like pricing. The same goes for permissions, upgrade mechanics, and new integrations. Fixes count too.

Of 20 update reviews with 12 or fewer findings, 7 still had a Critical or High. Euler's reviewed 2022 upgrade added a function missing a health check, later used to take 197 million dollars.

There is no industry standard TVL threshold that Guardian knows of. Size the review by what the change can reach, not the size of the diff, and add safeguards when large value is reachable.

A diff audit reviews what changed since the last audited commit, not the last release, plus the code it touches. Start over with a full re-audit when the architecture or trust model changes, or diffs stack up.

Guardian has reviewed every GMX update since October 2022. In 2026, a clean-sheet read of 27,805 source lines in GMX V2 still found two Criticals and seven Highs.

Read the full article for the complete decision table. Or ask about Vanguard, which includes six months of update review after production, at guardian.security.

An audit covers one commit. Every change after it is code the auditors never saw, shipped into a system that already holds deposits.

In Guardian's published portfolio, 29 of 49 update reviews (59%) found a Critical or High, and 11 (22%) found a Critical. See what 49 update reviews found.

So the question is rarely whether a change needs review. It is how much.

Changes That Always Need Review

Treat these as re-audit triggers, whatever the size of the diff:

New code that holds or moves funds: contracts, modules, facets, vaults or markets.
Value logic: accounting, pricing, interest, fees, rewards or liquidation.
Permissions: new roles, changed modifiers, new privileged functions.
Upgrade mechanics: storage layout, proxies, initializers and upgrade authorization.
New integrations: oracles, bridges, routers and new token types.
Fixes: for audit findings or incidents. A fix is a change like any other.
Toolchain: compiler or library upgrades in contracts that hold value.

For the storage and initializer mistakes that upgrades introduce, see five upgradeable contract vulnerabilities.

Small diffs are not safe diffs

Of the 20 update reviews in Guardian's portfolio with 12 or fewer findings, 7 still had a Critical or High.

The single finding in GMX's June 2024 Part 3 review was a Critical.

Public incidents follow the same pattern.

After a routine upgrade in June 2022, Nomad's Replica contract accepted 0x00 as a trusted root. In August, $190M was drained, Rekt reported.

Euler added donateToReserves in its eIP-14 upgrade in 2022. The function lacked a check on the health of the user's position, and in March 2023 it was used to take $197M.

That upgrade had been reviewed. Sherlock took responsibility for missing the flaw and agreed to pay a $4.5M claim, per Rekt.

Reviewing a change in isolation is not enough. Read the code it touches.

Changes That May Not Need One

Some changes need a verification, not an audit. Each still needs an owner.

Parameters within audited ranges, set through an audited setter. Check the value, then simulate it.
Identical bytecode on a new chain. Verify bytecode, roles and configuration instead.
Comments and tests only. Confirm the executable bytecode did not change.
Frontend, API or keeper changes. These need a pentest or offchain review, not a contract audit.

Each has a catch. A parameter can push the system into states the audit never tested.

A new chain can bring different tokens, oracles and gas limits. And a comment change still alters the metadata hash, so Sourcify reports a match rather than an exact match.

When in doubt, ask the auditor who knows the code. A short scoping call costs less than a guess.

Scale Review to Value at Risk

We know of no industry standard that sets a TVL threshold for re-audits. Size the review by what the change can reach, not by the size of the diff.

Change	Minimum review	When large TVL is reachable
New contract or module	Full audit of the new code and its integrations	Add a public contest or bounty scope
Value logic	Diff audit against the audited commit	Two independent reviewers; rerun the invariant suite
Permissions or upgrade path	Diff audit plus a storage layout check	Timelock and monitoring before execution
Fix for a finding	Fix review, ideally by the original auditor	Review the code around the fix too
New oracle, token or integration	Integration review	Fork test against live state
Parameter within audited range	Value check and simulation	A second signer decodes the calldata
Same bytecode, new chain	Deployment verification	Match bytecode, roles and peers per chain
Frontend, API or keepers	Pentest or offchain review	Include signing flows and admin panels

Regulated issuers may have the decision made for them.

Hong Kong's HKMA guideline for licensed stablecoin issuers (August 2025) says a licensee should engage a qualified third party to audit its stablecoin smart contracts at least annually.

It should also do so "whenever there is deployment, redeployment, or an upgrade to the smart contracts" (paragraph 6.5.5).

Re-Audit vs Diff Audit

A diff audit reviews the changes since the last audited commit, plus the code they touch. A full re-audit reads the whole system again.

	Diff audit	Full re-audit
Scope	The diff and the code it touches	The whole codebase
Baseline	The last audited commit	A clean sheet
Best for	Contained changes to audited code	New architecture or many stacked diffs
Catches	Bugs in and around the change	Bugs in how many changes combine

Always diff against the audited commit, not the last release. Otherwise anything shipped in between was never reviewed.

Move to a full re-audit when:

The diffs since the last full audit add up to a large share of the code.
Core flows or the trust model changed, not just features.
Several teams or auditors have touched the code since the original review.
You are about to put much more value behind the same code.

GMX is the long-run example. Guardian has reviewed every GMX smart contract update since October 2022.

In 2026, instead of another diff, Guardian re-reviewed the whole GMX V2 tree: 27,805 source lines over five months. Four years in, that clean-sheet read still found two Criticals and seven Highs.

Alongside it ran a design review, which "catches the problem where every change is correct and the system they add up to is not".

How Guardian Reviews Changes

Guardian's audits include focused reviews for upgrades: migrations, parameter changes, governance updates and hot fixes.

Vanguard, Guardian's enterprise security audit, includes six months of update review after production. Every change to the reviewed scope is audited at the same standard.

That covers up to 2,500 smart contract SLOC, or 10,000 SLOC for offchain codebases, split however your team ships.

For the process around each release, see smart contract change management.

Frequently Asked Questions

When does a smart contract need to be audited again?

When a change touches funds, permissions, pricing, liquidation, storage or upgrade logic, or adds a new contract or integration. Fixes count too. Parameter changes within audited ranges and identical redeploys need a verification rather than a full audit.

What is a diff audit?

A review of the changes since the last audited commit, plus the code those changes touch. It suits contained changes to audited code. It can miss problems in how many changes combine, which is when a full re-audit is due.

Does a fix for an audit finding need review?

Yes. In Guardian's published portfolio, 41 of the 125 onchain reports with a remediation round (32.8%) gained a Critical or High during it. Some fixes did not close the original issue; others introduced new problems in the changed code.

How often should a smart contract be audited?

On every change that can reach funds, not on a calendar. Some regulators add a floor: Hong Kong's HKMA guideline says licensed stablecoin issuers should have their smart contracts audited at least annually and on every deployment, redeployment or upgrade.

Sources

Keep every change covered

Vanguard reviews every change to your audited scope for six months after production, at the same standard as the audit.

Get a Vanguard quote See how Vanguard works