Smart Contract Audits Are Not Enough
The industry treats audits as a stamp of safety. In reality, an audit is a point-in-time review with limited scope. Real smart contract security requires defense in depth: formal verification, bug bounties, upgradeability, and operational monitoring.
Smart Contract Audits Are Not Enough
In 2018, "we've been audited" has become the crypto equivalent of "we're compliant." It sounds reassuring. It creates a sense of safety. And it is often dangerously insufficient.
The crypto industry has developed a collective belief that a smart contract audit is a stamp of approval — that once a contract has been reviewed by a reputable firm, it can be trusted with user funds. This belief is wrong, and the consequences of acting on it have already been severe.
What an Audit Actually Is
A smart contract audit is a point-in-time review, conducted by a specific team, with a specific scope, under time and budget constraints. The auditors examine the code as it exists at the moment of review. They look for known vulnerability patterns, logic errors, and deviations from the specification. They produce a report with findings categorised by severity.
What an audit is not: it is not a guarantee of correctness. It is not a certification of safety. It is not a comprehensive analysis of every possible interaction between the audited contract and every other contract it might interact with. And it is not a substitute for ongoing security practices after deployment.
The gap between what an audit provides and what the market believes it provides is enormous — and that gap is where losses occur.
Why Audits Fail
Audits fail for several structural reasons, none of which reflect poorly on the auditors themselves. Code changes after the audit — a common practice where teams make "minor" modifications between the audit and deployment, inadvertently introducing vulnerabilities that were not present in the reviewed version. The audit scope does not cover all interactions — a contract that is safe in isolation may be vulnerable when composed with other contracts in ways the auditors did not anticipate. Economic attacks are often not in scope — auditors focus on code-level vulnerabilities, but many of the most damaging exploits are economic in nature, exploiting incentive structures rather than code bugs. And auditors are human — they work under time pressure, they have blind spots, and they miss things.
The evidence is already clear. The DAO — the most high-profile smart contract in Ethereum's history — was reviewed by multiple parties before its launch. The vulnerability that led to the $60 million hack was missed. Parity's multi-signature wallet was "audited" — and a critical vulnerability allowed a user to accidentally destroy $280 million worth of Ether by triggering a self-destruct function. These were not obscure projects with amateur code. They were high-profile contracts reviewed by competent teams.
Defence in Depth
Real smart contract security requires defence in depth — multiple overlapping layers of protection, each designed to catch what the others miss.
Formal verification, where feasible, uses mathematical proofs to demonstrate that a contract behaves according to its specification. It is expensive and time-consuming, but for contracts that secure large amounts of value, it is increasingly justified. Bug bounties incentivise external security researchers to find and report vulnerabilities before attackers exploit them — creating a continuous review process that extends far beyond the initial audit. Upgradeability patterns — proxy contracts, timelocks, and governance-controlled upgrades — allow teams to fix vulnerabilities after deployment without requiring users to migrate to a new contract. Operational monitoring detects anomalous behaviour in real time — unusual transaction patterns, unexpected state changes, or interactions with known malicious addresses — and can trigger automated responses like pausing the contract. And economic modelling stress-tests the incentive structures of a protocol under adversarial conditions, identifying attack vectors that code-level audits would miss.
No single layer is sufficient. The combination is what creates resilience. A contract that has been audited, formally verified, covered by a bug bounty, designed with upgradeability, and monitored in production is orders of magnitude more secure than one that has only been audited.
My View
If you are building on smart contracts — and especially if you are building contracts that hold user funds — treat security as a continuous process, not a checkbox. The audit is the beginning of your security practice, not the end. And if your marketing materials say "audited by [firm]" as if that settles the question of security, you are misleading your users and setting yourself up for a painful lesson.
Security is not a document. It is a practice — ongoing, layered, and never finished. The audit report is chapter one. The question is whether you write the rest of the book.