Can An Audited Protocol Still Be Hacked Later?
A “passed audit” badge can read like a seal of permanent approval, but what it actually certifies is much narrower, and much more time-bound, than that phrase tends to suggest.
The short answer
Yes. An audit examines a specific version of a protocol’s code at a specific point in time, using the auditor’s particular methods and expertise, and it can’t guarantee that every possible vulnerability was found, nor does it cover code changes made after the audit was completed. Protocols that update frequently, which is most of them, can introduce new bugs with any subsequent change, regardless of how thorough the original review was. An audit lowers risk; it doesn’t eliminate it.
Why audits have limits by design
An audit is a review conducted by specific people with specific expertise, working within a specific timeframe and budget, examining a specific version of the code. That combination of constraints means an audit can reasonably catch known categories of vulnerabilities and common mistakes, but it can’t exhaustively prove the absence of every possible flaw, especially subtle ones involving how multiple contracts interact under unusual conditions. Different auditors, given the same code, don’t always find the same issues, which is part of why some protocols undergo multiple audits from different firms rather than treating one review as sufficient on its own.
What changes after the audit is done
Software evolves. A protocol that passed an audit and then shipped new features, fixed unrelated bugs, or integrated with another external protocol has, in a real sense, changed the thing that was actually reviewed. Unless every subsequent change is re-audited, which is costly and not universally done, the codebase running in production can drift meaningfully from the version that earned the original approval. This is one reason wrapped assets carry their own layered risks: every additional layer of code and every additional integration point is a new place where something can go wrong, audited or not.
Edge cases and interactions are the hard part
Many real exploits don’t come from an obvious bug sitting in isolated code; they come from unexpected interactions between otherwise reasonable pieces, including how a protocol handles extreme market conditions, unusual transaction ordering, or data from an external source. This is part of why decentralized oracles differ meaningfully from centralized ones in the risk they introduce: a protocol’s own code might be sound, while a dependency it relies on for outside data becomes the actual point of failure. Audits generally focus on the protocol’s own logic and can’t fully account for every external system it touches.
What a later exploit means for connected wallets
A protocol compromise doesn’t only affect funds deposited directly into it. If users previously granted the protocol an unlimited token approval to simplify repeated interactions, a later exploit can potentially use that standing permission to move tokens out of every connected wallet, not just the protocol’s own holdings. This is a good reason to periodically review which apps still hold active permissions, rather than assuming a past audit means old approvals are permanently safe to leave in place.
What a past audit does and doesn’t tell you
- It tells you a specific, dated version of the code was reviewed by people with relevant expertise, using their own particular methodology.
- It doesn’t guarantee the current, live version matches what was reviewed, especially for actively developed protocols.
- It doesn’t eliminate the risk from external dependencies, including price feeds, bridges, or other protocols it interacts with.
- It doesn’t replace ongoing risk awareness, since new attack techniques and previously unknown categories of bugs continue to be discovered industry-wide over time.
What to weigh
An audit is a real, meaningful signal, not a formality to be dismissed. But treating it as a permanent guarantee misunderstands what the process actually covers. Anyone weighing exposure to a given protocol is better served checking how recently it was audited, whether major changes have shipped since, and what dependencies it relies on, rather than treating “audited” as a single word that settles the question for good.