After the Audit: Remediation and Re-Verification Explained

The report is a checkpoint, not a finish line

An audit report is a snapshot of code at a single commit, with findings ranked by severity and a recommendation attached to each one. What happens next determines whether that report protects users or just decorates a GitHub repo. Teams that treat the final PDF as the end of the engagement are the ones you read about six months later, after a fix that "looked right" introduced a new bug the original audit never covered because the audit never covered it.

Post-audit remediation is the process of turning findings into merged, re-checked code. Done properly it has three distinct phases: triage and fix, re-verification against the specific findings, and a certificate or attestation that ties the final commit hash to the resolved report. Skip or compress any of these and you've spent money on a document instead of security.

Triage: not every finding gets fixed the same way

A typical mid-sized audit — say a lending protocol or a jetton contract with custom logic — comes back with findings bucketed as Critical, High, Medium, Low, and Informational/Gas. The instinct is to fix everything before launch. That's usually wrong.

Critical and High findings block deployment, full stop. Medium findings need a documented decision: fix now, fix in a follow-up release, or accept the risk with a written rationale (rare, but sometimes a Medium is a theoretical issue with no practical exploit path given the deployment constraints). Low and Informational findings are frequently batched into a single cleanup PR rather than fixed one-by-one, because each fix is itself a code change that needs review.

The mistake we see most often at this stage is a developer "improving" a fix beyond what the finding asked for — refactoring a function while patching it, or changing an interface signature because it seemed cleaner. Every line touched during remediation is a line that needs re-verification. Scope creep here is how a two-day fix cycle turns into a two-week one.

A worked example: fixing a reentrancy finding

Say the audit flags a withdraw function that violates checks-effects-interactions:

// Before — state updated after external call
function withdraw(uint256 amount) external {
    require(balances[msg.sender] >= amount, "insufficient balance");
    (bool ok, ) = msg.sender.call{value: amount}("");
    require(ok, "transfer failed");
    balances[msg.sender] -= amount; // too late
}

The minimal, correct fix reorders state mutation before the external call and nothing else:

// After — effects before interaction, plus a guard as defense in depth
function withdraw(uint256 amount) external nonReentrant {
    require(balances[msg.sender] >= amount, "insufficient balance");
    balances[msg.sender] -= amount;
    (bool ok, ) = msg.sender.call{value: amount}("");
    require(ok, "transfer failed");
}

Note what didn't change: function signature, event emissions, access control, gas-refund logic. That matters because re-verification is cheapest when the diff is narrow and the auditor can reason about it in isolation. A three-line diff takes an hour to re-check. A three-line diff that also renamed a variable and touched an unrelated modifier takes half a day, because now the auditor has to re-derive that nothing else moved.

The same discipline applies on TON, where reentrancy shows up differently — through message-passing races rather than external calls — but the principle is identical: fix the specific defect, touch nothing else, document the diff. We cover how FunC and Tact contracts get evaluated for these patterns in our piece on what TON auditors actually check, and jetton/NFT-specific failure modes in our Jetton and NFT standard security pitfalls writeup.

Re-verification is not a second audit

This is the part clients most often misunderstand. Re-verification does not mean the auditor re-reads the entire codebase looking for new problems. It means the auditor takes the original finding list, maps each one to a specific commit range, and confirms three things: the vulnerability is closed, the fix didn't reintroduce it under a different code path, and the fix didn't break invariants the audit already verified elsewhere (access control, upgrade safety, token accounting).

A competent re-verification pass produces a second, shorter document: a remediation report that lists each original finding with a status — Resolved, Partially Resolved, Acknowledged (risk accepted), or Not Resolved — and a commit hash or diff link as evidence. If your auditor hands you a one-line "all issues fixed" email instead of a mapped remediation report, that's a red flag regardless of how reputable the firm's name is.

Full re-audits are a different, and reasonable, decision when remediation touches more than roughly 20-30% of the original codebase, or when new features got bundled into the same release. At that point you're not verifying fixes, you're auditing new code, and pricing should reflect that — our breakdown of audit cost drivers across EVM, Solana, and TON covers how scope changes move the quote.

What an on-chain certificate actually proves

"Audited by X" badges are marketing. A useful certificate is a signed attestation, ideally anchored on-chain or in a content-addressed store like IPFS, that binds together: the audited commit hash, the report hash, the remediation report hash, and the deployed contract's bytecode hash (or init code hash for factories). Some firms publish this as a simple signed JSON blob referenced from a verified-contracts registry; others mint it as a non-transferable NFT or write a hash pointer into a registry contract.

The property that matters is verifiability without trust: anyone can pull the deployed bytecode, hash it, and confirm it matches what the certificate claims was reviewed. Without that binding, "certified" just means someone once looked at some version of the code. We've seen post-audit certificates issued against a commit that was later force-pushed over — worthless, because nothing ties the claim to what's actually live. If a certificate can't be checked against on-chain bytecode in under five minutes, don't rely on it for a listing or investor deck.

Timeline, cost, and where teams get burned

For a contract with 3-6 Critical/High findings, expect: 3-7 days for the team to implement fixes, 2-4 days for re-verification (shorter if diffs are clean and scoped as above), and same-day certificate issuance once the remediation report is signed off. Re-verification is typically billed at 15-25% of the original audit fee, not a fresh quote, unless scope crept into a near-full re-audit.

The failure pattern worth naming explicitly: teams launch on a fixed date regardless of remediation status, ship with Medium findings "acknowledged" that turn out to be exploitable under mainnet conditions the audit's test environment didn't model (real MEV, real gas markets, real liquidity depth). A finding rated Medium in a controlled review can become Critical in production. If your remediation plan includes accepted risk, get that decision in writing from whoever owns the deployment, not just the engineer who wrote the fix.

If you're heading into remediation without a clear escalation plan for who signs off on accepted risk, that's worth resolving with outside input before code changes start — a short strategy consultation up front is cheaper than a rushed decision under launch pressure.

Whether you're closing out findings from a prior audit or building the fix-verify loop into your release process for the first time, get the smart contract audit team that wrote the original findings involved in re-verification — they already know where the bodies are buried.