DeFi Security Starts at the Chain Level - DeFi Security Summit 2025

Transcript

Okay. So, hi everyone. My name is Majek. I work at L2BIT as software developer. And in today's talk, I want to tell you why defy security really starts at the chain level. We'll look at what that mean practice, why it matters for users and how at L2B, we are trying to make those risk clear and easy to understand. So, yeah, Dei has matured last few years. We've gone from experimenting with small lending pools to protocols that now secure billions of dollars. To put that into perspective, a alone is now comparable to midsize traditional bank. In terms of asset locked, it would actually rank as 42 second largest bank in the world. That's how big DeFi has became. At the same time, we moved

beyond Ethereum. The action is now spread across dozens of L2s. Users interact with these chains every single day, often without realizing how different they really are. Most users don't think about the chains at all. They look at the protocol. They compare yields and they jump between deployments to chase the best return. From their perspective, a unis swap is unis swap. These are battle tested contracts running for years in production. Nothing can go wrong, right? But this creates the fundamental problem. Let's take a as an example again. It looks the same on Ethereum on base or our bedroom linear ink scroll. The logo is the same. The interface is the same. Even the contracts are the same. But in reality, those are completely different words.

And that's the starting point of this talk. Defi security does not begin with the protocol. It begins with the chain. When we say that, it's not just theory. It has real consequences for users. The question is simple. What happens when the chain stops or shut downs completely? We've already seen this tested with Dydxv3 on Stark X. When the team decided to shut it down and move on to building before, the system still held a lot of user fans. That could have gone badly if users had no way to exit, their asset might have been trapped there forever. But that didn't happen because Stark X has force withdrawal mechanism built in and even after operators stopped running the chain, users could still exit safely directly to Ethereum. You can see that on the chart. Uh after shutdown announcement,

the total value started dropping from around $1 billion down to around $30 million today. But the remaining funds are likely just forgotten. But overall it work exactly as intended. That's what real user protection looks like. It goes beyond audits and solid contracts. It's about what happens when the chain stops. Uh and if the chain doesn't give you the guarantees to exit in every situation, your funds are never truly safe. So because all of these problems, we to L2B research all these systems. We analyze every Ethereum scaling solution and we've built unified ways for you to see the difference and to understand in one place how secure and how mature each projects really are. But when you first

open L2, it can be a bit overwhelming. There are a lot of colors. There is some random thing like looks like a pizza in the table. There are some stages, but it's not random. It just shows how different these projects really are. Each one makes it own trade-offs and we try to make those differences clear and easy. So in the next part of this talk I want to walk you through what all of this actually means starting with the tap split. Then we will talk about this pizza like thing called riset and finally the stages framework. These are the core parts of L2B and once you understand them the whole site start to make sense and you can use it to to stay safe while surfing through DI. So yeah we split projects into three main categories. There's also the fourth one for project we haven't reviewed yet but

we'll skip them obviously today. This split is the foundation. It shows what kind of security model each project is built on. First, we have rollups. These are projects that have proof system and they use Ethereum for data availability. All the data you need to reconstruct the state lives on Ethereum. So, anyone can access it. That's a big step in the right direction. Then we have Validiums and Optimiums. These are project that also have proof system but they don't use Ethereum for data valability. Instead they rely on external DA layer like Celelesia or Aen DA but they also use DA bridge which is a set of contracts integrated into proof system that verifies that the data actually exists. It connects the external DA layer back to Ethereum security model.

It of course also introduced most more trust assumptions because now you depend on this DA layer and DA bridge both working as intended. And then we have others. These are projects that are missing something fundamental. Maybe they use external DA layer but without DA bridge or they use Ethereum for data valability but they don't have proofs or they have proofs but they are close to limited to few limited actors. These are the most trust heavy heavy setups. In disable you can of course also see what each project is exactly missing but this split is all just a foundation. Uh this is just a starting point because to really understand how chain SAV is we need to look where the actual risks are

and that's where the risk rolet comes in. It shows you the five main areas of risks for each project with each slice representing an assumption you make when using that chain. Green means strong warranties, yellow partial trust and red means you are depending on someone. In a moment we will go through each element one by one with some examples so you can easier understand what this risk looks like in practice. First element is state validation. It answer simple but crucial question. How is the system state verified? Green slice means the list fully functional proof system deployed. It's permissionless and delay attacks are bounded. And this is exactly the case for arbitr. Yellow slice mean proof system is safe overall but it can be affected by delay attacks. That's when

the operator slows down proof submission or challenge resolution to to slow down withdraws. Yellow can also mean that the white list is used but with at least five external actors that can use them. And here we have kinto and red slice means requirements aren't met. There is no open source code or proofs are just basically not deployed. And here we have blast with no proofs. Another element is data availability. It tells you if all the data needed to reconstruct this chain state is aable. Green slice mean data is posted to Ethereum. That's a true roll up. Anyone can access it.

Perfect solution. Here we have base which uses Ethereum blobs for storing all of its data. Yellow min data is stored on external DA layer and DA bridge is used. We've already talked about this setup on validium and optimum page. Uh and here we have son which uses a for DA together with the vector bridge and red means data is offchain without the DA bridge or it's on what we call basement DA run by a few trusted actors. Ethereum can't verify if the data actually exists. No one knows for sure.

And here we have corn which relies on a small duck. This topic is a bit more complex because each DA layer brings its own guarantees and risks. That's why we've built separate data valability risk framework for evaluating them. I also gave a talk about DAS and this risk framework on ifrag this year. So if you are interested please scan the QR code and watch it later. Okay, so next element is exit window. It tells you what how much time users have to exit if an upgrade is announced. Uh green slice means user get at least 30 days. This this is plenty of time to react. And here we have facet bluebird

with which contracts are not upgradable. Yellow slice mean between seven and 30 days. It's okay, but you're under time pressure. Here we have Starknet with seven days and red means less than seven days or even instant upgrades. Here we have linear with instant upgrades. It might sound minor but it's crucial because if governance can push a bridge upgrade that changes the bridge logic overnight, users might not have enough time to to exit before something bad happens. Also, some some systems also have security cancels which can make instant emergency upgrades. That's not necessarily bad. CES are useful for fixing bugs quickly, but it's also crucial to set them up properly because if they are compromised, they can

upgrade everything instantly. And other slice is proposer failure. So what happens if the entity posting roots to Ethereum goes offline? Green slice means anyone can post roots or in some upchains the system can freeze and let user withdraw through L1. And this is exactly the case for dydx be free that I showed you at the beginning. Yellow mean there is some fallback so governance or security council can step in to rotate proposers or post new roots. Here we have zk sync era with governance system that can replace proposers and red means it's fully centralized. So if the proposer stops the L1 view freezes we just can't finalize and you can't get their money back basically. And here we

have polygon zm with wid listed set of proposers. And finally the last element sequencer failure. So what happens if the sequencer stops or starts sensoring transactions? Green slice mean user can self-sequence blocks or force include transaction through an L1. Here we have Sonium which supports for inclusion mechanism but more on that in a minute. Yellow means user can submit transaction to an L1 cube but they can't force include them. Sequencer can't selectively sensor specific users but it can stop processing the queue entirely meaning everyone is stuck. Here we have abstract and red means there is no alternative path. So the sequencer is

down the whole chain is down. And here we have katana. And this metric is all about the livveness and sensor censorship resistance because if you can't force your transaction through, you don't really control your funds. And this is not just theory. It actually happened in practice because it actually happened on Sonium. It sequence sequencer started censoring all transactions related to ibo token which is trademark name for Sony's robotic puppy and all the transactions related to to this token were blocked. But Lucono from our research team proved that censorship resistance is real. He manually crafted transaction call data force included on L1 and after a few minutes transaction appeared in L2

explorer and this is exactly what green slice mean here. Censorship might happen but at least users have a mechanism to fight it. So to sum up the GOET gives you a simple visual snapshot of where the actual risks are for each chain. State validation shows if you can verify the state. Data availability is the data available. Exit window, how much time you have to react before something bad happens. And sequencer and proposer failure shows if the system can still work or at least let you withdraw if main operators go down or start misbehaving.

And now that we know where the actual risks are, the next natural question is how far each project has gone to remove them. And that's where we have uh that's where the stages framework comes in. It's a simple three-step ladder that shows the overall maturity and the centralization of each roll up with each step removing a piece of trust. And you can see that in roset getting greener. First we have stage zero. We call it full training wheels. Project postda and roots to ethereum has a basic proof system but it's still heavily centralized. small multiix and operators can upgrade freely.

Then we have stage one limited training wheels. Now user funds are protected unless 75% of the security council colludes. Exit windows last at least 7 days and governance can replace proposers. And finally stage two, no training wheels. Now proofs are permissionless. Exit window last at least 30 days and security council can only act in case of provable bugs like two proof system disagreeing with each other. And as Vitalik wrote in his blog post being stage zero at the beginning is totally fine. You need training wheels to test things and move fast. But over time you should upgrade towards stage two. Removing trust in people with trust in code. Yet many projects didn't

remove erh didn't remove training wheels even after years in production. So we at L2 bit we try to put pressure on these teams to grow up to keep evolving and to deliver on the promise of decentralization because we've built something amazing in defi open permissionless systems doing what is impossible in traditional finance but all of this still relies on the chain's benefit. So we try to make this invisible layer visible because transparency creates pressure and pressure creates progress. That's how we move from experiments to to real things.

So next time when you are bridging farming or just deploying more capital onchain don't just ask is this protocol safe also ask is the chain benefit safe because that's where defi security truly begins. Thank you. >> Awesome. Thanks Mek. I think we have time maybe for a couple of questions. Yep. I saw you uh raised your hand as soon as he was done. So, here you go. >> Hi, I'm uh Tom representing Facet, one of the only stage two roll-ups. So, exit window, right? Uh to get stage two, you need a 30-day exit window. But why 30 days? I've never seen any justification for that number. And in fact, the data you use, the argument you use favoring

the exit window, uh is very much anti-30 days. dydx if they had merely a 30-day exit window, users would have lost millions of dollars. They are good because they are immutable. Stage two should require immutability. What do you say to that? >> That's very good question. You can come to me after after the talk and we can we can discuss it. I can also contact you with someone from our research team. I I I guess they are better to to answer that question. Um, so you were talking about stage two as being like the final goal of any chain really, any L2. But what if the intended design requires some form of centralization? I know it's a bit taboo here.

>> I can't hear you. Well, can you like >> Oh, what is what if for example an app chain requires uh or at least like to for a good user experience, it requires um centralized sequencer to be able to uh have higher throughput or especially for specific applications like um uh like um uh Exchange for example where you want to be able for your transactions to be settled faster like uh in that case does stage two as the final goal for any L2 is really uh optimal in that regard.

>> Yeah, like on our website for every app chain we we below the stage batch we show that this is upchain because for most of the upchains the the case is a bit different. So we are trying to analyze every bit every bit differently that but we are showing that each each one is is an upchain. But if we want to talk later, we can we can go. >> All right. Maybe time for one more. No. Oh, good. Well, thank you, Mach. Thanks, [applause]