Fix Verification Round

A fix verification round is the second review performed by a smart contract audit firm after the client has patched the issues identified in the initial audit report. It is the step that separates a complete audit from a half-finished one, and the absence of fix verification is one of the clearest signals that an audit firm is cutting corners.

How Fix Verification Works

After the auditor delivers the draft report, the development team works through the findings and ships patches for each issue. Once the patches are ready, they are sent back to the audit firm in a defined set of commits. The same senior researcher who performed the initial review reads the patches and answers three structural questions for each one.

First, does the patch actually fix the bug described in the original finding? It is common for engineering teams to address the symptom but not the root cause, and a fix that does not eliminate the underlying issue leaves the protocol exposed even though the report says the finding is resolved.

Second, is the fix complete or does it leave an edge case open? Real-world vulnerabilities often have multiple exploitation paths, and patching the most obvious one without considering variations is a recurring source of post-audit exploits.

Third, and most importantly, did the fix introduce a new vulnerability? This is the question that experienced auditors take most seriously, because patches written under deadline pressure are a common source of fresh critical bugs. A fix that patches a reentrancy vulnerability but introduces an access control flaw is a net-negative change, and only a second review will catch it.

Why Some Firms Skip It

Fix verification is labor-intensive. The firm has to allocate a senior researcher's time again, often weeks after the original engagement ended. Some firms charge for verification as a separate engagement, and others simply do not offer it at all. Founders who do not know to ask for it end up paying full audit price for half the work.

The cost of skipping fix verification is asymmetric. The audit firm saves a few days of researcher time. The protocol bears the full cost of any patch that turns out to be incomplete or harmful, which can include the kind of catastrophic exploits the audit was supposed to prevent.

What Should Be Included

A properly executed fix verification round produces an updated final audit report where each finding receives a final status. The standard categories are Acknowledged, Fixed, Partially Fixed, and Not Addressed. This final report, not the draft, is what should be shown to investors, users, and the board. It is also the document that supports the signed audit attestation the firm provides.

Verification should always happen on the same commit hash or a clearly identified follow-up commit, never on an open branch that continues to change. The code freeze discipline that applied during the original audit continues to apply during fix verification.

How to Demand It

When evaluating audit firms, ask directly whether fix verification is included in the base price. If the answer is yes, ask how many rounds are included, what the turnaround time is, and whether the same researcher who performed the initial review will perform the verification. If the answer is no, treat that as a structural problem with the firm's offering, not a feature you can negotiate later.