Code Freeze

A code freeze is the policy decision and engineering discipline of stopping all changes to a smart contract codebase during an active audit. While a frozen commit hash is the artifact that locks the version under review, the code freeze is the behavior the team commits to in order to make that artifact meaningful.

Why Code Freeze Matters

A smart contract audit takes three to four weeks of focused manual review by senior researchers. During that time, the auditor builds a complete mental model of the system: how contracts call each other, where state is mutated, what trust assumptions apply, where economic incentives could be weaponized. Every line of new code that enters the codebase during the audit invalidates a portion of that mental model.

If a team continues to merge features mid-audit, the auditor is reviewing a moving target. A finding identified in version A may be irrelevant in version B if the relevant module was refactored. A new module added mid-engagement is unreviewed at delivery. The result is an audit report that does not describe the code that actually ships, which is the worst possible outcome because it provides false confidence.

Code Freeze Scope

A proper code freeze covers the entire audit scope as agreed in the pre-audit phase. Out-of-scope code can continue to change because the audit will not review it anyway. In-scope code, including any shared utilities or dependencies that are part of the engagement, must remain at the frozen commit hash.

The freeze typically extends through the end of the fix verification round, not just the initial review. Patches for findings are made on top of the frozen baseline, and the same discipline applies. New unrelated features wait until after final report delivery.

Common Code Freeze Failures

The most common code freeze failure is the "small fix" that turns into a refactor. A developer notices a minor issue during the audit and decides to fix it. The fix touches a module that the auditor is actively reviewing. Now the auditor has to re-read that module or risk delivering a finding that no longer applies. This compounds quickly across multiple "small" changes.

The second failure mode is the deadline conflict. A team agrees to a code freeze, then discovers mid-audit that an investor demo or partner integration requires a feature they had not anticipated. They merge the feature anyway. The audit either expands in scope at the firm's expense, gets delayed at the team's expense, or simply ends with unreviewed code in production.

The third failure mode is the documentation gap. The team freezes code but never communicates the freeze to all engineers. A junior developer pushes a hotfix to main without realizing the audit is in progress. This is particularly common in teams without a dedicated audit liaison.

How to Hold a Code Freeze

Effective code freezes are enforced through branch protection, not goodwill. Lock the main branch or the audit branch through GitHub or GitLab permissions during the engagement. Designate one person as the audit liaison who has the authority to approve any exceptions. Document the freeze in writing as part of the audit readiness checklist before the kickoff call.

If a true emergency requires a mid-audit change, communicate with the audit firm immediately. Most firms can accommodate a scoped exception if they know about it, and a properly described delta is much cheaper than a re-audit.