The Next Billion in Web3 Will Get Hacked Unless We Rethink Security

Transcript

Hi everyone. I'm Sarah Hicks. I'm co-founder and chief strategy officer of Olympics. We build a pre-deployment deterministic security infrastructure for smart contracts. And today we're going to be talking about why the next billion dollars in Web3 will get hacked unless we change the way we think about security. So what we're going to be going through today is how the risk landscape has evolved, um what the attack vectors are that are leading to exploits today, why the status quo in security in Web3 is insufficient, and how we can actually borrow from best practices already set in high-risk traditional finance systems um so that we can secure uh the smart contracts and prevent the next billion

from being hacked. So let's start with the reality of the numbers. So the target has grown exponentially. Um in the past year we reached 4 trillion in crypto market cap. Uh we reached 33 trillion in stablecoin transaction volume, which is double uh Visa's volume as an example. And we had 350 billion in real-world assets tokenized. And institutions are all in. Citibank, Fidelity, Morgan Stanley, Visa, Mastercard, everybody has come into the space. So the target is big and hackers are coming. Um and then we have a new risk multiplier. So the um increase, the massive increase in the use of AI in coding has kind of

increased a or introduced a risk multiplier on two sides. One of them is that the barrier to entry for writing smart contracts has been dramatically reduced. You don't have to have a Solidity coding background to be able to write and deploy a smart contract with AI. But that's great. AI is getting very, very strong. And the reality of the strength of AI on the flip side is that folks can use AI to hack smart contracts. Um and we've seen plenty of examples of where um AI has been introducing vulnerabilities into code. We saw earlier this year the first hacks on code bases that had been co-authored by Claude. Um and Veracode estimates that about 45% of AI code um has vulnerabilities in it. And the reason

for that is that AI is designed to write code that runs. It's not designed to write code that is secure. And so what does that mean for security? So in 2025 we saw 3.5 billion in exploits. In smart contracts alone we saw 240 million in preventable losses. Um so losses that were actually able to be detected prior to deployment, but the teams just didn't uh have the tools to do so. Um and that's a scary reality when we're looking at all of these institutions coming into the space. Um the next billion is going to get hacked unless we unless we change the way we're doing things.

So let's talk a little bit about how the attack surface has evolved. So um smart contracts, protocols are not just interacting with themselves, one protocol anymore. There's this deep composability risk because protocols are interacting with other protocols, are interacting with vaults, are interacting with strategies. And so when we do see a vulnerability happen somewhere, it kind of proliferates throughout or cascades throughout this sequence of integrations. The second is uh bridge exploits. So before you used to see these exploits of, you know, protocols alone, now we have bridges that have um we have more and more bridges spinning up with higher and higher volume moving through them.

Um and bridge uh exploits themselves, although only representing a small about 5% uh a small fraction of the total number of exploits, um they were kind of overrepresented in the financial losses. So around, you know, 26, 27% um of the total financial losses came from bridge exploits. So it's another thing that we need to keep an eye on. And then we have governance attacks. So we had a a lot of governance attacks over the past, you know, year or so. Um and a lot of them were exacerbated or caused by smart contract vulnerabilities. So flash loan attacks were um responsible for the majority of governance attacks that took place in 2025. Um and finally, these are not crimes of opportunity. Um we have

nation-state actors that are, you know, systematically looking for ways to access this again growing target. Um we know that it's, you know, the single um biggest source of funds for the likes of DPRK. Um and in 2025, although the total volume of exploits um was lower than it ever had been, uh the volume of financial losses per exploit was exponentially higher. So 2.5 2 billion in theft um with 74% fewer exploits leading to those losses. So let's talk about how smart contracts actually continue to fail.

So when we're looking at the top four um most common attack vectors that have led to attacks in 2025, and this is from a uh report or a postmortem that we did of all of the EVM smart contract exploits that took place in 2025, you can you can find that annual report on our website, olympics.security. Um but logic vulnerabilities still represent the the top um single most exploited attack vector in smart contracts, representing 72% of hacks. Um and that's things like incorrect state assumptions, unsafe operation ordering. These are quite simple things that kind of feel like silly mistakes, but they do continue to happen. Um Next up, uh next most common, uh

representing 55% of smart contract exploits, we have access control failures. So this is due to things like missing authorization checks or allowing arbitrary callers access to privileged functions. Then next up at 40% we had precision or accounting errors. And so although these were the fewer fewer incidents, they represented um the highest dollar impact. And so one example of that, and we'll we'll chat about it a bit later, um again, is the Balancer hack. So a a rounding rounding bias rounding error.

And finally, representing 30%, um we have price manipulation or oracles. Um And again, the reality of this is, and I mentioned it on on the second slide, this the total smart contract exploits in 2025 represented about 240 plus million in losses. And 49 out of 50 of them were preventable. They were things that were detectable in that pre-audit commit if you were running the right types of tests. Um and the reality of this and what it tells us is that the code is behaving as written. It doesn't necessarily mean that it's behaving as intended. And so we need to leverage different testing methodologies that can test what the code is actually going to do, not just if the code is going to do

what we want it to do. So why does the status quo for security in Web3 fail? So we kind of have a couple of things that are that are happening in in most um established teams with kind of a a robust current uh security posture. They've obviously got internal testing, leveraging various different types of testing. Um but one pretty standard one is something like, you know, unit testing and end branch coverage. And then we've got audits, um which everyone is is very familiar with, but you know, you engage an external third party to to come in and review your code. And then once you've deployed, you have things in place like on-chain monitoring to alert you of anything that might be going

wrong. But let's speak to the limitations um of each of these elements of of the kind of current status quo. So test coverage. Branch coverage does not equal adversarial coverage. So most exploited paths in 2025 were technically covered, um but they were not covered under adversarial or hostile conditions, hostile inputs, extreme states, the types of things that are actually going to to take place that that could lead to an exploit. So we need other metrics other than branch coverage for testing.

And we need to enforce those. Then audits. Why are audits not foolproof? Of course they're very important element in the security stack, but they are inherently limited in a number of ways. So one of those ways is that they're limited in scope. So they're typically um limited to say a new release or a new product. They're limited in in scope. They're a snapshot of the code at that moment in time. They're not a continuous test and retest and audit and re-audit of that code in the context of the entirety of a code base. And this is uh a perfect thing to be illustrated by the Balancer exploit.

So Balancer had uh you know, three-year-old code that was audited at the time and deemed safe. There was a potential vulnerability, but in the context of the code base it wasn't exploitable. So the team acknowledged it, there was a comment in the code base, all good. They move on. Three years later, they have the a new code some new code, they have a new audit, and same thing. That scope, that particular point in time, is audited, it's deemed safe. They deploy, all good. Not all good. The interaction between the old audited safe code and the new audited safe code created a vulnerability that was exploited for 121 million dollars. So it's a perfect example of why a limited audit scope is not going to be sufficient for high-risk financial systems.

And the second piece to audits, because they are services, is that there's a huge kind of potential range in quality that you'll experience, whether that's varying firm by firm or whether that is auditor by auditor, uh and whether that auditor has a you know, a deep understanding of your code base. You know, that's why we see a lot of the big teams use audit firms on retainer, so that the the same teams are kind of picking up more and more context on the code as they go. Um and then the other piece is what what tools or what testing methodologies are actually being employed by that auditor that is doing the audit of your code base. So, all of these things create a really wide range in in the kind of quality of audits.

It's not something that's kind of mathematical or quantifiable or or verifiable, and that is why all audits come with a disclaimer that says, you know, this this isn't a guarantee. This isn't exhaustive. This is a best guess with the resources, with the context, with the time, with the scope that we have. Um and then the reality is that 90% of exploits happen on audited code bases because they just simply cannot be bulletproof given these limitations. And finally, on-chain monitoring. Again, a very critical layer in a robust security approach, but it's reactive.

It's it's letting you know that an exploit is taking place, which is fantastic. It can let you allow you to mitigate losses and kind of if you've got the necessary kind of pause functions in place, you can, you know, stop the bleeding. Um but it doesn't prevent the vulnerability from happening altogether. You can think about it like a smoke detector. It's not helping you with the faulty wiring that has led to this electrical fire, but of course it's going to let you know, and you can get the people out of the building. But anyway, these are the pieces that today make up a strong security posture in Web3. Um and when you look at Balancer again as an example, they were kind of going above and beyond the current status quo. They had three audits across that code base. They had on-chain monitoring in place. It wasn't

enough. The good news is there is an alternative that is actually already available. And this is one of the kind of funny ways that crypto is, although very innovative, kind of behind traditional financial systems. So, in high-risk financial systems, so payments custody clearing risk engines, the high-risk or critical components of the software are held to a higher standard. So, deterministic testing is required for critical paths. Formal methods are used to verify where failure is totally unacceptable, and there needs to be proof of security, proof of correctness, rather than probabilistic confidence.

And and you know, an audit as an example is probabilistic confidence. It is best guess with again the resources, the time, the the context that we have. And and these practices in high-risk financial systems are put in place before production, not after incidents. We don't just say like, okay, we'll deploy and we'll we'll see how it goes when it's live. These pieces need to be mathematically verified ahead of time. And in blockchain, in this new financial paradigm, smart contracts are the critical component of the high-risk financial software. They're immutable. There is direct access to liquidity to custody value, and failure means immediate financial and immediate reputational damage.

Um in cases of some of the DeFi protocols that we've seen, it means total erasure of a business. Um for, you know, some of these big institutions coming into the space, if they lose, you know, 100 million, it's not going to be the end of them from a financial standpoint, but it's certainly going to be bad from a reputational standpoint. You can't have, you know, Robinhood, Citibank having an exploit. Anyone who's not even touching the blockchain elements of of their offerings is going to be really scared of that. So, we need this new security layer in Web3 as well. We need to hold ourselves to the same standard as traditional finance when it comes to security. And these formal methods aren't new. They're just underutilized in Web3.

But there's a reason for that, and it's because historically they're quite inaccessible. So, something like formal verification used to be solely able to be conducted by mathematician PhD level mathematicians who have the capabilities of writing in formal verification languages, writing invariants, defining invariants, defining specs, doing the mathematical equations, and providing proofs. It's not something that the average developer can do. And so, that's why in our space historically, um it's been something that you might have to employ like a third party to kind of do for you. But it means it's expensive. It means it's not scalable. And again, largely it's just inaccessible.

Luckily, that has changed in the last couple of years. We now do have automated formal methods testing that integrates into developer-friendly workflows. Um and we have the ability then not just to apply them to a you know, a scope of just the kind of critical most critical paths, um but we have the ability to apply them continuously throughout development to the entirety of the code base. So, this is what that would look like in practice. So, we know security must shift left. We can't we can't keep leaving it with with the auditor, and we can't keep leaving it with post-deployment monitoring. We've got to shift it left. That is an established practice in other high-risk systems.

And we do see this as spaces mature, as industries mature, as institutions move into industries, we see that security shifts left, security spend shifts left, the expectations are increased for for security. And and again, it must be verified before deployment. So, when we're looking at our current sort of development and deployment life cycle in Web3, we write the smart contracts, write the code. We review ourselves internally, various kind of manual or automated forms of testing to prepare for audit. Then we go to that external third-party audit. We deploy. We monitor on-chain.

In this write and review section, the the leftmost section of this life cycle, we need to employ formal methods and of course AI. Like I mentioned a little bit earlier, AI is getting better. That's good. It's also bad. But in this context, we can leverage it as well. But more importantly, we do need these deterministic formal methods. So, we need to be leveraging things like simple testing deterministic testing like static analysis, so heuristics, pattern matching, static detectors. But we also need more adversarial, more hostile, more complex, more sophisticated testing methodologies like formal verification, like fuzzing. But we also need to be exhaustive. So, we need exhaustive path exploration, which can be

executed through things like symbolic execution. And we need to not just test the code, but test the test suites. We need things like mutation testing. And all of this needs to feed into sort of a personalized testing engine per protocol port per ecosystem because there's context that exists not in the code itself, but in design docs, in the developers' brains, in kind of like threat intelligence that's being amassed from the ecosystem, from the existing audit database in that ecosystem or in similar protocols. All of this needs to be encompassed into kind of formal methods testing that is happening again prior to audit, prior to deployment, so that we can shift left and we can be verifiably secure before we go to audit.

And I had mentioned AI and the fact that it's useful here as well, but kind of deterministic testing was was more important or it's a really critical additional layer, and there's a reason for that. And that is proof. Um so, we have probabilistic security, we have deterministic security. Probabilistic security means we are surfacing issues based on likelihood. We are pattern matching at scale. We're limited to known vulnerabilities and looking for those. Um outputs are typically not necessarily reproducible or repeatable. Same inputs might result in different outputs.

Um but AI is valuable for triage, for gathering signals, for telling us where we should look, but it's insufficient alone. We need that deterministic part because we need to evaluate whether properties hold across all paths. We need to make sure that outputs are reproducible and measurable. Um we need audit trails. It can't be black box. And we need to be able to enforce this security with CICD gates and make sure that these formal methods scale with deployment velocity. So, the improved security life cycle looks like this. During continuous development, we can use things like static analysis, unit testing again, but branch coverage isn't enough, so things like mutation testing to look for edge cases that are currently uncovered by

branch coverage. Um in audit prep after code freeze, we need to use fuzzing, formal verification, exhaustive path exploration, symbolic execution, um and test the entirety of the code base, not that limited audit scope, not the diff. Then we go to external audit, reputable firms, as many audits of course as we can as budget allows, and on-chain monitoring in place with, importantly, the corresponding runtime controls to make sure that the pause function is actually there if you do get an alert. So, that leaves us here. We have a choice. Currently, Web3 security is where traditional finance security was 20 years ago. I think we're all we'd all be sad to hear that because we like to think that we're much more innovative and much more advanced. Um but we can continue down the path that we're on

right now and think of security as an afterthought, point-in-time audits, monitoring after deployment, hope nothing slips through the cracks. Or we can think of security as infrastructure. We need continuous deterministic testing embedded throughout development. We need pre-deployment enforcement of these these security metrics. And we need proof, not probabilistic confidence. Because when code becomes capital, correctness is non-negotiable. So, that's it. The these are are systems that are already being used by real teams out there, including Circle, Uniswap, LiFi, Securitize. These automated deterministic security tools do exist, and we need to make sure that we're holding ourselves across the industry to the same standard as we hold

ourselves in traditional finance. And yeah, the next billion in Web3 will get hacked unless we change the way we're thinking about security. and we do have the tools to change the way we're thinking about it. It's just about taking the next step in embedding it. Thank you. >> [applause]