Why External Audits Matter in Web3

A smart contract is a financial system that runs without you. Once it is deployed, there is no hotfix branch and no rollback — the code executes as written, for anyone who calls it, until the value is gone or the protocol is migrated. That single property is why external review matters far more here than in ordinary software.

Why you cannot audit your own code

This is not a comment on your team's ability. It is structural. The person who wrote a function tests it against the model they had in their head while writing it. That model is exactly the thing that needs challenging, and it is the one thing they cannot step outside of.

After three months in a codebase, whole categories of question stop occurring to you: what if this is called twice in one block, what if the token takes a fee on transfer, what if this address is a contract that reverts on receive. The answers may be fine. The problem is that nobody asks.

Where the money actually goes

There is a persistent belief that audits are about finding reentrancy. Reentrancy is well understood, well tooled, and increasingly rare in new code. The losses that still happen cluster somewhere else entirely:

• Accounting drift. Rounding that always favours the same side, reward accumulators that lose precision, balances tracked in two places that gradually disagree.
• Economic sequences. A series of entirely legal transactions that, taken together, extract value. No single call is a bug. The combination is.
• Oracle assumptions. Trusting a price that can be moved within a block, or failing to handle a feed that goes stale or returns something absurd.
• Integration surprises. Inheriting the behaviour of a token or protocol you did not write and did not read.

Every one of those requires someone to reason about what your protocol is for, not just what the code says. That is the part automated tooling does not do, and the reason a scanner report is not an audit.

What a real audit includes

• Manual review of everything in scope. A human reading every line, not a tool output with commentary attached.
• Business logic analysis. Does the implementation match the intent, and what happens when a user behaves adversarially rather than as designed?
• Proof-of-concept exploits. Findings that come with a reproducible test, so severity is demonstrated rather than asserted.
• Severity ratings with reasoning. Impact and likelihood stated explicitly, so you can prioritise under a deadline.
• Concrete remediation. Not “consider adding validation” but the specific change, in your code.
• A retest. Fixes introduce bugs. An audit that ends at the report leaves the last step unverified.

How long it actually takes

Timelines vary enormously with scope and with who you hire. A large firm working through a queue will often quote four to eight weeks end to end, much of it waiting. An independent auditor working directly on a small-to-medium codebase can turn the same review around in days.

1. 01

   Scoping

   Agree exactly which contracts, at which commit, and what the protocol is supposed to do. Vague scope is the single most common cause of a disappointing audit.

2. 02

   Review

   Manual reading of the codebase, then targeted analysis of wherever value accumulates: accounting, access control, reward maths, external calls.

3. 03

   Exploit testing

   Write tests for the paths that look breakable. This is what separates a finding from a hunch.

4. 04

   Report

   Findings with severity, reproduction, and remediation. You should be able to hand each one to a developer without translation.

5. 05

   Retest

   Re-review the patches. Confirm the fix works and that it did not introduce something new.

What an audit is not

An audit is a time-boxed expert assessment. It is not a proof that your code is safe, and no auditor can honestly offer one — proving the absence of bugs is not something the field can do. What a good audit buys you is a large reduction in the probability that an obvious or semi-obvious path to your users' funds is still open on launch day.

Security does not end at launch

The audited artefact is a specific commit. Every feature you add after that is unaudited code interacting with audited code, which is often where the interesting failures live. Protocols that stay safe tend to treat review as recurring: new modules get reviewed, significant refactors get reviewed, and someone maintains a relationship with a reviewer who already understands the system.

The economics

The comparison that matters is not audit cost versus your budget. It is audit cost versus the value the contract will custody. A protocol expecting to hold six figures and treating a review as an expense to minimise has already made the interesting decision — and the recovery cost of an exploit is never just the funds. It is the users who leave, the exchanges that delist, and the year spent rebuilding a reputation.

If you are shipping something that holds other people's money, external review belongs on the launch checklist next to the deployment script. Not because it is a formality, but because you cannot see your own blind spots by definition, and everyone who has lost funds to a smart contract bug was equally sure their code was fine.

Related reading: what it means to work with a good auditor and how to read an audit report once you have one.