Is a re-audit cheaper than the first audit?

Usually, because the scope is the change and whatever it touches. But a small diff can touch a lot. A change to share accounting in a vault can affect every function that reads it.

Does a re-audit have to be done by the same firm?

No, but the original auditors already know the system, which saves time. If you change firms, share the previous reports so the new team can check earlier findings were fixed and stayed fixed.

We only changed a parameter. Do we need a re-audit?

Changing a value through an existing, audited admin function does not need a code review. Changing a constant in the source and redeploying does, because the bytecode has changed and nobody has checked the new value against the rest of the system.

Re-Auditing a Smart Contract After an Upgrade

When do you need a smart contract re-audit?

You need a re-audit whenever the deployed code stops matching the code that was audited: new features, an upgrade to an implementation contract, changed integrations, a fork onto a new chain, or fixes made after the original report. An audit covers one commit. Anything changed after it has not been reviewed, however small the change looks.

What counts as a change

An audit report applies to the bytecode built from one commit. These all break that link:

New features added after the audit, even if they reuse audited code.
Upgrades to the implementation behind a proxy.
Fixes made after the final report, including fixes for findings that were never re-checked.
New integrations with oracles, DEXs, lending markets or bridges.
Forks and redeployments on another chain, where block times, sequencers, precompiles and token behaviour can differ.
Dependency upgrades, such as a new version of a library your contracts inherit from.

How we scope a re-audit

We start from the diff between the audited commit and the new one, then trace outward: every function that reads state the change writes, every external call whose assumptions the change affects, and every invariant the change could break. The scope is the change plus its reach, which is why a ten line diff can still take days.

Storage layout gets particular attention on upgradeable contracts. A new variable inserted in the wrong place can silently corrupt existing state when the new implementation goes live.

Re-audit and remediation review are different things

Every HYDN audit includes up to two rounds of remediation review, where we confirm that the fixes for our findings hold and have not introduced anything new. That covers fixes to findings. New functionality written during the fix window is a change in scope, and needs reviewing as such.

Keeping the audit valid

The simplest protection is to verify, before deployment, that the deployed bytecode matches the audited commit. If it does not, your users are relying on an audit of code they are not running.