Web3 protocols are still losing billions to exploits despite passing audits. Here is why the industry needs to rethink security from the ground up, starting at the code level.

Every year, billions of dollars disappear from Web3 protocols. Not from projects that skipped security entirely, but from projects that did everything the industry told them to do. They hired auditors. They passed reviews. They shipped with confidence.

And then they got drained.

The uncomfortable truth is that the standard Web3 security playbook has a structural flaw. It treats security as a finish line rather than an ongoing system. Audit passed, box ticked, contract shipped. What happens after that is largely left to chance.

Harry Donnelly, Founder and CEO of Circuit, put it plainly in a recent episode of The Security Table: if you are treating security as a checklist, you do not really care. Not because teams are malicious, but because a checklist mentality stops you from asking the questions that actually protect you.

This article breaks down why the current approach is failing, what a real security stack looks like, and how teams can start shifting left before vulnerabilities become exploits.

The Checklist Problem: Why Ticking Boxes Is Not Enough

Checklists have a specific and dangerous failure mode that does not get discussed enough in Web3 security circles. It is not just that they can miss things. It is that they actively discourage looking for things that are not on the list.

When a team approaches security with a pass or fail mentality, the question they are implicitly asking is: did we meet the minimum bar? That is a fundamentally different question from: how do we make it structurally difficult to lose user funds?

The first question produces compliance. The second produces resilience. Only one of them actually protects your protocol.

Donnelly put it well: checklists are a starting point, not an endpoint. They give you the first set of things to look for. But the gaps that get exploited are usually the ones that nobody thought to add to the list.

This pattern has played out repeatedly across major DeFi exploits. The Balancer hack. The Abracadabra Money incident. Protocols that had security controls in place, audits on file, and still lost tens or hundreds of millions of dollars because something fell outside the scope of what anyone had thought to check.

Checkbox security does not fail because the boxes are wrong. It fails because it trains teams to stop looking once the boxes are checked.

What the Insurance Industry Understood Before Web3 Did

One of the most telling signals that Web3 security has a structural problem comes from outside the industry entirely.

When Circuit went to underwriters at Lloyd's of London to understand what keeps insurers up at night, they did not hear concerns about whether protocols had passed audits. The question the insurers were asking was more fundamental: what happens the moment those controls fail?

Insurers have real financial skin in the game. When a claim gets filed, they pay out. That incentive structure produces clear thinking about risk that the Web3 industry, which has historically been more focused on shipping fast than protecting users, has largely lacked.

What the underwriters understood is that custodial controls are the last line of defense. Everything that happens before that moment, audits, monitoring, testing, contributes to security. But if those controls are breached, whether through a stolen API key, a compromised private key, or any other vector, the funds are gone unless something else intervenes.

Detection without response is not a security strategy. It is a very expensive way to watch yourself get exploited.

The Last Mile Problem: Why Detection Is Not Enough

Most Web3 security stacks are built around detection. On-chain monitoring tools watch for suspicious patterns. Alerts fire when something looks wrong. Security teams get notified.

And then humans have to respond.

That last step is where billions have been lost. The window between detection and response, the time it takes for humans to get into a room together, assess the situation, and take action, is often longer than the time it takes for funds to disappear.

Donnelly describes it with a scenario that is uncomfortable precisely because it is realistic: someone comes in hungover and presses the wrong button. Puts in the wrong zero. Makes the kind of mistake that humans make.

If there is one thing standing between that mistake and a billion dollars disappearing, that one thing will eventually fail. That is not pessimism. That is how single points of failure work.

The solution is not to hire better people or run more drills. The solution is to build systems that do not depend on humans being perfect under pressure.

Automated response, the ability to take action without waiting for humans to come into the loop, is not a nice-to-have. It is the missing layer in most security stacks.

Building a Real Security Stack: The NIST Framework Applied to Web3

The good news is that a comprehensive security framework already exists. The NIST Cybersecurity Framework, built around five functions: Identify, Protect, Detect, Respond, and Recover, maps directly onto the Web3 security problem. The Web3 industry has largely been implementing only the first two.

Protect covers your custodial and non-custodial wallets. Cryptography, transaction policies, quorums, access controls. The goal is preventing unauthorized access to private keys and unauthorized movement of funds.

Detect covers on-chain monitoring and signal detection. Pattern recognition, anomaly detection, alerts when something looks like a known attack vector. Mempool monitoring is a key tool here, particularly effective for Bitcoin, though not sufficient on its own across all chains and attack types.

Respond is where most stacks fall short. Automated response that acts on signals without waiting for human intervention. Moving funds to safety before the transaction confirms. This is the gap that Circuit is built to close.

Recover covers disaster scenarios. Key backup, fund recovery, getting back online after a worst-case failure. This layer is almost entirely absent from most Web3 protocols.

Having all of these pieces in place is necessary but not sufficient. Purchasing security software and configuring it correctly are two different things. Transaction policies that are not configured protect nothing. Whitelisting that is not set up protects nothing. The stack has to be designed to fit actual operations, not just checked off a procurement list.

Assets, Not Keys: The Reframe That Changes Everything

Here is the hot take that reframes the entire Web3 security conversation.

The industry has been obsessing over private key security. The cryptography, the hardware wallets, the multi-sig setups, the access controls. Enormous amounts of engineering effort and capital have gone into making private keys as difficult to compromise as possible.

But private key security is not the goal. It is a means to an end.

The goal is protecting the assets.

Those are two different problems with two different solutions. And the industry has been almost exclusively solving the first one.

Donnelly frames it as a choice: if you had to pick between protecting the private key and protecting the assets themselves, which would you choose? The answer is obvious. But most security architectures are built as if the key and the assets are the same thing, as if compromising the key is inherently the end of the story.

It does not have to be. If your response layer is fast enough and smart enough, a compromised key does not have to mean lost funds. The assets can still be moved to safety. The damage can still be contained.

That shift in framing, from key security to asset security, is the mental model that actually produces resilient protocols.

Shifting Security Left: Why the Problem Has to Be Solved Earlier

The conversation about detection and response is critical. But it addresses the problem after code has already been deployed, after vulnerabilities are already live in production, after the attack surface already exists.

The most effective place to stop an exploit is before it is ever deployed.

This is the concept of shifting security left: moving vulnerability detection earlier in the development lifecycle, into the IDE, into the CI/CD pipeline, into the hands of developers before code ever touches a staging environment, let alone mainnet.

The traditional approach places security at the end of the development process. Write the code, build the product, then bring in an auditor to review it. The problem with this model is not just that audits miss things, though they do. It is that finding a critical vulnerability at the audit stage means rearchitecting code that is already written. It is expensive, slow, and creates pressure to ship anyway.

When security is integrated into development from the start, vulnerabilities get caught when they are cheapest to fix: at the moment they are introduced. Not weeks later. Not after the product is already built around flawed assumptions.

This is also where the checklist mentality is most damaging. When teams view the audit as the security step, they are implicitly treating everything before it as a security-free zone. Developers write code without security feedback. Reviewers look for functionality, not vulnerabilities. By the time a security professional sees the code, there are layers of decisions built on top of the original flaw.

Shifting left is not about replacing audits. It is about making audits more effective by ensuring the code that reaches them is already as clean as possible.

How Olympix Fits Into the Security Stack

Olympix is built around a single premise: security that happens after deployment is always playing catch-up. The goal is to find vulnerabilities before they ship, not after they are exploited.

The platform gives development teams a suite of proactive security tools that integrate directly into the development workflow. Static analysis that catches vulnerability patterns as code is written. Mutation testing that verifies your test suite actually detects the vulnerabilities it is supposed to catch. Automated unit test generation that closes coverage gaps before they become attack vectors. Fuzz testing that probes code with unexpected inputs to surface edge cases no manual reviewer would think to try.

The numbers make the case plainly. Olympix would have prevented approximately $240 million in exploits in 2025 alone, representing 98% of all EVM smart contract hacks that year. That is not a marginal improvement on the status quo. That is a fundamental shift in what proactive security can actually deliver.

Teams using Olympix see the impact across the entire development cycle. Audit findings drop by 65% on average, because Olympix catches the same issues ahead of the audit before a security firm ever sees the code. Audit spend drops by up to 50%, because fewer findings on cleaner code means fewer rounds of review. And projects launch 20% faster, because shorter audit cycles and higher development confidence remove the bottlenecks that slow teams down.

Working with protocols like Circle, Uniswap Foundation, and Cork Protocol, the pattern is consistent. These are not teams that were skipping security. They were teams doing everything right by the standard playbook, who found that continuous developer-integrated security caught things that point-in-time reviews had missed.

In the context of the full security stack, Olympix operates at the earliest layer. Before the code reaches an auditor. Before it reaches staging. Before any of the detection and response infrastructure even has anything to monitor. It is the layer that ensures the code entering the pipeline is as hardened as possible before it ever becomes a live attack surface.

The security question should not be: did we pass the audit? It should be: how do we make it structurally difficult to ship vulnerable code in the first place? That is the question Olympix is built to answer.

The Institutional Pressure That Is Forcing the Industry to Grow Up

There is a forcing function coming that will accelerate this shift whether the industry is ready for it or not.

Institutional capital, the financial institutions, asset managers, and large custodians that represent the next major wave of entrants into the space, does not operate with a checkbox mentality. These organizations manage billions of dollars of other people's money. Regulatory exposure is real. Fiduciary responsibility is legally enforceable. The idea that a passed audit constitutes sufficient security diligence does not survive contact with a compliance team.

Donnelly observed this directly. Institutional players are not asking whether a protocol was audited. They are asking how the protocol makes it structurally impossible, or as close to impossible as achievable, to lose user funds. That is a fundamentally different standard.

Meeting that standard requires the full stack. Proactive vulnerability detection during development. Layered protection at the wallet and custody level. Continuous monitoring across all signal types. Automated response that does not depend on humans being in the right place at the right time. Disaster recovery planning for worst-case scenarios.

The protocols that will capture institutional capital are the ones building toward this standard now, not when it becomes a requirement.

The Bottom Line

Web3 security is not a checklist problem. It is a systems problem.

The protocols that will stop losing billions to exploits are the ones that build security into every layer of the stack, from the moment code is written to the moment funds are moved. Not as a compliance exercise. Not as a box to tick before shipping. But as an ongoing commitment to the users whose money they are responsible for.

That means shifting security left, catching vulnerabilities during development rather than after deployment. It means layered protection that assumes something will eventually go wrong and plans for it. It means automated response that acts faster than humans can. And it means reframing the goal from protecting the key to protecting the assets.

The industry has the tools to do this now. The question is whether teams are willing to go beyond the checklist and actually use them.

If you are building on EVM and want to stop vulnerabilities before they reach audit, let alone mainnet, Olympix is where to start. Request a demo to see how teams are shipping faster and more securely.