Audit Methodology
Should Auditors Fix the Code They Audit? Smart Contract Audit Independence and Remediation Guidance
One of the oldest arguments in security consulting has quietly become one of the most important arguments in smart contract auditing: should the auditor stop at identifying vulnerabilities, or should they also tell the client how to fix them? The question sounds operational. It is actually about incentives, assurance, and the boundary between independent review and engineering participation.
In crypto, that boundary matters more than it does in most software domains. An audit finding is not just a ticket in Jira. It may sit between a protocol and a nine-figure loss. Teams want actionable outcomes, not abstract warnings. At the same time, an auditor who writes the patch is no longer a neutral observer in the same sense. They become, at least partially, a co-author of the code they are supposed to assess.
My view is that both sides are right about something important. Good smart contract audit recommendations are often necessary. But the word "recommendation" hides a spectrum. There is a major difference between saying "move effects before interactions" and handing over a deployable Solidity diff. If you do not separate those categories, the debate around auditor independence becomes confused very quickly.
The Real Distinction
Conceptual guidance
Describe the invariant that must hold and the design direction that restores it.
Low independence risk
Illustrative pseudocode
Show the intended sequencing, checks, or state transitions without presenting deployable code.
Manageable if clearly labeled
Production patch
Provide Solidity that can be copied into the codebase with minimal modification.
High independence and liability risk
The Case For Providing Smart Contract Audit Recommendations
Clients pay for decisions, not just diagnosis
A finding that stops at 'this is dangerous' is often incomplete in practice. Most teams hire a smart contract audit because they want the system to be safer on a deadline. That means they need help translating a vulnerability into a concrete remediation path, not just a severity label.
The auditor has the deepest context on the bug
By the time a finding reaches the report, the auditor has already traced the exploit path, understood the relevant invariants, and ruled out weaker explanations. That context is expensive to rebuild. In many cases, the person best positioned to suggest a fix is the person who found the flaw in the first place.
Smaller teams often do not have in-house security engineering
For a mature protocol with internal reviewers, fix direction may be optional. For a two-person startup shipping its first upgrade, it is essential. Without remediation guidance, the audit can become a handoff to nobody. The result is not independence in a meaningful sense. It is just remediation debt.
No fix recommendation means longer remediation lag
The longer a team spends debating what a finding actually requires, the longer the vulnerability remains live in staging, in code review, or sometimes in production. Good remediation guidance shortens that lag by giving the engineering team a safer starting point and a narrower design space.
Security reviews in web2 usually include remediation guidance
Penetration tests, secure code reviews, and infrastructure assessments almost always ship with recommended mitigations. That is normal because security work is expected to be actionable. Smart contract audits are not identical to web2 testing, but the user expectation is similar: tell us what is wrong, and tell us how to move forward.
There is also a practical point that auditors sometimes understate: the exploit path is usually much clearer than the remediation path from the client's perspective. The auditor has already done the difficult interpretive work. They know which invariant failed, what assumption was violated, and whether the bug is local or systemic. Asking the client to reverse-engineer a safe fix from a finding description can turn a strong audit into a weak handoff.
This is why many teams, especially early-stage teams, experience an audit report without remediation guidance as incomplete. A strong code review security audit should improve the odds that a flaw is removed correctly, not merely documented elegantly. That does not require the auditor to become the implementation team, but it does argue for meaningful smart contract audit recommendations rather than sterile bug descriptions.
The Case Against It: Why Audit vs Remediation Is a Real Boundary
The auditor stops being fully independent
Once an auditor writes the patch they later evaluate, they are no longer just reviewing code. They are partially authoring it. That changes the nature of the engagement from independent assessment toward consulting or co-development, even if everyone still calls it an audit.
A flawed fix creates an obvious conflict of interest
If the auditor's proposed remediation is incomplete, introduces a new bug, or breaks an invariant elsewhere, who is supposed to review that fix objectively? The same firm that suggested it has a natural incentive to defend its own reasoning. That is not a trivial governance problem. It is the core independence problem.
Fix-writing can anchor the audit itself
Auditors can drift toward findings they already know how to solve cleanly. That sounds subtle, but it matters. The mental move from 'is this dangerous?' to 'can I propose a neat patch?' can bias attention toward solvable local defects and away from uglier systemic risks that do not fit neatly into a code diff.
Traditional auditing draws a harder line
Financial auditors do not prepare the books they audit. They review, challenge, and opine. The analogy is imperfect, but the principle is useful: independent assurance weakens when the reviewer begins producing the object being reviewed. Smart contract security is more engineering-heavy, but the independence tradeoff is real.
Recommendations can create false confidence
Even when the recommendation is sound, implementation usually diverges. Variables are renamed, adjacent logic is refactored, tests are weakened, or the fix is merged alongside unrelated changes. Teams then remember that 'the auditor gave us a fix' and conclude the issue is resolved, even though the deployed implementation may no longer match the original guidance.
The independence argument is not ceremonial. It goes to the heart of what an audit is supposed to buy. Clients do not just purchase expertise. They purchase adversarial distance. The auditor is paid to look at the system from outside the decision chain and say whether the code is safe enough to ship. That distance weakens if the same firm is effectively designing the implementation.
The problem gets sharper after remediation. If an auditor proposes a patch and then later marks the issue as resolved, the engagement starts to resemble self-review. Even when everyone acts in good faith, the structure is fragile. The more detailed and deployable the recommendation becomes, the more reasonable it is to ask for a second reviewer, a diff review, or a separate engineering engagement rather than treating the original audit as sufficient.
A Better Framing
Auditors should explain the security property, not own the final patch
That is the middle position the market usually wants but rarely names clearly. The auditor should absolutely explain what safe behavior looks like, what class of remediation is appropriate, and what new failure modes the team must avoid while fixing the issue. But the client, or a separately-scoped engineering partner, should usually be the one who authors production code. That preserves most of the value of remediation guidance while keeping some meaningful separation between assurance and implementation.
The Legal Dimension: Who's Liable When the Fix Fails?
The legal issue is where this debate stops being philosophical. Suppose an auditor provides a specific remediation, the client implements it nearly verbatim, and the patched contract is still exploitable. If funds are later lost, it is not hard to imagine the client alleging negligence, professional liability, or breach of contract. Even if that claim ultimately fails, the auditor has already absorbed the cost of the dispute. The mere fact that the code was suggested in an audit report changes how the engagement may be interpreted after an incident.
The core problem is that the line between remediation guidance and engineering advice is blurry, especially in Solidity. A sentence like "replace external call ordering to restore CEI" is obviously guidance. A code block that can be copied into production is much closer to professional implementation advice. The smart contract audit market still lacks the contractual maturity of traditional software consulting. Liability caps, role definitions, review obligations, and professional indemnity coverage are not yet standardized across firms, even though the assets at risk are often vastly larger than in ordinary software engagements.
Courts and regulators have not cleanly defined the duty of care a smart contract auditor owes once the firm crosses from finding bugs into prescribing solutions. That uncertainty creates asymmetric risk. The client still bears execution risk because they deploy the code, but the auditor may inherit legal exposure without being paid or insured like a true implementation partner. In other words, the market often prices remediation guidance as a small add-on while the downside can look more like engineering liability.
The practical answer is discipline, not wishful thinking. If an audit firm offers fix recommendations, they should be explicitly non-binding, illustrative, and accompanied by a clear statement that the client must independently review, test, and validate any remediation before deployment. Where the recommendation materially shapes production code, the safer path is to require a re-audit or at minimum a focused diff review. Without that structure, the legal posture around audit vs remediation is far less settled than the industry often pretends.
How NanoLab Handles the Boundary
NanoLab provides fix recommendations as guidance, not as deployable code.
Recommendations are labeled as illustrative and must be independently reviewed, tested, and integrated by the client.
Reports include explicit disclaimers that remediation guidance is not professional engineering advice or legal advice, and that NanoLab does not assume liability for implementations derived from audit suggestions.
After remediation, NanoLab recommends a re-audit or at minimum a scoped diff review before deployment.
That approach is opinionated by design. We think clients deserve actionable remediation guidance, especially when a finding is subtle or time-sensitive. But we do not think an audit firm should quietly slide into being the unacknowledged implementation owner. If a team wants production-level engineering help, that should be structured, priced, and reviewed as a different kind of engagement.
The reason is simple: clarity protects both sides. It protects the client from treating an illustrative recommendation as a final patch, and it protects the auditor from implicitly taking on a role the contract never priced correctly. In smart contract security, fuzzy engagement boundaries do not stay fuzzy for long. They usually get clarified after something breaks.
Conclusion
So, should auditors fix the code they audit? Usually, no. Should they provide remediation guidance? Usually, yes. Those answers are not contradictory once you distinguish conceptual guidance from production implementation.
The right model depends on the team, the engagement, and the type of vulnerability. A mature protocol with strong internal security engineering may only need design-level direction. A smaller team may need more help understanding safe sequencing, authorization boundaries, or invariant preservation. But the closer the auditor gets to authoring deployable code, the weaker auditor independence becomes and the less fairly the legal risk is usually priced.
That is why the legal dimension matters so much. It tips the scale toward caution. Auditors who provide fixes without explicit disclaimers, independent validation requirements, and a clear engagement structure are taking on risk the market still treats as free. The sustainable position is narrower and more disciplined: explain the flaw, outline the safe remediation path, insist on independent review, and re-check the diff before anyone calls the issue resolved.
NanoLab Smart Contract Audit
See how NanoLab handles remediation guidance in practice
Review the NanoLab sample Compound V2 report for an example of how we communicate findings, recommendations, disclaimers, and follow-up review expectations in a real audit deliverable.