 That's a big stage. Thanks so much for showing up. My special thanks is to make a dial-fam, obviously. And I'm gonna talk a little bit about bridges. You might have heard a lot of talks about bridges. This one might be slightly different, because the subject of the talk is actually quite serious. I mean we had a lot of problems with bridges recently. So before I actually go into the cracks of the matter, let's just go back and look at a bit of a history. So how come I'm here? Two years ago, more or less, we started to work at the multi-chain strategy for the make-a-dial, and we asked ourselves a question, how do we actually move Dai to different chains? So it was actually quite hard, and for us, let me go back. So two years ago, we started to work on the multi-chain strategy. And we had to look at all the other chains, and we had to find out how secure they are to actually be able to move Dai in a very secure manner. And to do that, we looked at the security of all the other chains. So basically, I created the spreadsheet, and I posted the spreadsheet on the forum, and frankly, after a while, not a lot of people looked at the data and looked at what we had to say. So I figured that we need to make this information more broadly available to the broader audience, and we basically created a website called L2P. And the reason for us to actually do that was to make people aware that security of Dai on all the other chains is very, very different. If you hold Dai on, let's say, polygon, if you hold Dai on phantom, you'll be looking at a very, very different Dai. And the security properties of the Dai will be very different. For make or die, it is of the utmost importance that Dai is censorship resistance. And if you hold Dai on all these other chains, you should really ask yourself a question. Is this really a Dai that you hold on Ethereum? Does it have the same properties? Or is it actually different, right? And can you make all these different Dai is fungible? And what is it really needed to be able to mint Dai on all these other chains? So these are actually quite hard questions, and that's why it took us so long to get all of us to where we are here. And once we looked at all the other chains, we want to publish all the results. And this is how L2P was born. L2P was essentially initially created as a website to disclose all the risks for all the different chains. And it took us really, by surprise, how important this thing was. Everyone was like really looking at the risks and the value locked and at all the information that we actually uncovered in a way. So let's have a very quick look at the state of the bridges and where we are today. So essentially, when we look back at the last year, it was a bad year, right? We had a hack at the Poly Network. We had a hack at the Chain Swap. We had a hack at the Annie Swap. So last year was really, really bad. But that doesn't really compare to what we witnessed this year. And it's really shaping up to be much, much worse. So it all started with the wormhole hack. Then we had Ronin Network. It was like huge. $600 million was taken from that bridge. Then we had the Harmony Nomad. This one was particularly bad. I personally really liked Nomad architecture. I was actually trying to convince my peers at Maker to have a very closer, much closer look. And unfortunately, to a bug in a smart contract, it was hacked literally two weeks after I pitched Nomad. So that was really, really intense. And then, probably a week before Defcon, you might have heard about Binance. And I even had to correct my presentation because of what happened literally yesterday, right? It's not just the bridge. Some other DeFi protocols were hacked as well. But yet, we had another bridge hack. So bridges are scary. And bridges seem to be really weak point in all of this. And we had to take a closer look at all of them. So far, we spent the last two years looking mostly at the rollups. And now, it was time for our team to have a look at other bridges as well. And how we published this information, like I said before, we basically looked at all the S-grows. We looked at all the values that was locked in all the bridges. But looking at other, not just the rollups, looking at other bridges was essentially requested by the community. And if Josh Sark from Ethereum Foundation asks you to actually do something, you should really consider it. So without the favor of it, I mean, this is actually my pleasure to announce that at L2 Beat, we also are covering all the bridges. You can check it out. It's actually up and running and live since yesterday. And I'm going to tell you a little bit how we look at these bridges and what are the findings that we uncovered by looking at these bridges. So to put it simply, we obviously track total value locked in these bridges. So we can see more or less the same type of list as for layer 2s. We track total value locked and you can see how much value is at stake. This is all the value that potentially can be hacked. And the bridges are like these huge pinatas for potential hackers. So we really need to understand what are the risks and what are the security assumptions behind all these bridges. And then you can look at the bridges to rollups as a type of canonical bridge. So you can combine this information and you can see the total value locked in all of these systems and all of these bridges. But as you know, L2 Beat is primarily about the risks. We want to disclose the risks. Like you can see on this particular example, most of you probably know that optimism does not have fraud proofs right now deployed. And this information should be known and available to everybody. So you know when you move your funds to optimism, what are the security assumptions? I mean, we are in a close contact with Optimus team. We know that they're working on the fraud proof system. But as it stands right now, you have to trust them, right? You have to trust the team and you have to trust the sequencer. So I guess we thought that we need a proper risk framework for bridges that would work more or less the same way as we did that before for rollups. We believe that risks should be disclosed. We believe that we should make everybody aware of the underlying security assumptions. We should constantly monitor infrastructure for upgrades and we should really monitor the other security parameters. And this is tough. This is hard because some of these constructs are actually quite, quite complex. And you need proper automation, you need proper tooling. You actually need to be able to read from storage diffs, which if you have ever tried to do that, it's not particularly easy. And thankfully, right now there are some tools that actually allow you to do it much easier. But generally, what you need to do is you need to replay all the potential Ethereum transactions that change the particular slot. So that's tough. But this is our task. And we believe that once we do that, we'll actually make multi-chain infrastructure more transparent and secure while keeping teams honest. And it is all about honesty, right? It is all about proper disclosures. It is all about making sure that users do understand the risks. So what are the risks when you're actually using bridges? And you would be surprised how a few people actually do understand. Most people kind of think that when funds are in transit, and once they arrive to the destination, they should be safe, right? So it's almost like crossing the bridge across the water. And once you've made it to the other side, you're safe. But you're not. You're definitely not safe. And I will try to explain why. But before I do that, I will actually show you a few interesting findings that you might actually also find surprising. So the first one, and I think it's actually quite a big one, is the multi-chain. Multi-chain is one of the biggest bridges with the biggest DVL. Turns out that last year, they actually removed from escrow quite a lot of funds, like literally millions of dollars. So normally, for that type of bridge, you expect that you put your funds into the escrow. And on the other side of the bridge, some funds will be minted, right? And when you go back, the funds from the destination, they will be burned. And the validators will release the funds from the escrow. Turns out that in this particular case, validators actually took funds out of the escrow without actually burning them from the destination. So that was odd. And the amount was very significant. And it seems like no one cared. Like people were not really aware that that was happening. And just the fact that it is possible for the validators to take funds out of the escrow, this is the risk assumption that, you know, you should be all aware of, right? If you're using the bridge that's externally validated, that's the thing, you know, they can all take your funds. So in this particular instance, apparently the funds were used to provide liquidity to any tokens on a lot of different chains. And to make sure that this is exactly what happened, you would have to, like, go to all the other chains and check it out. But, you know, my question to the multi-chain team is, what's this part of the contract, right? Where are users aware? And what is the consequence? Can actually users withdraw all their funds? And more importantly, what is this additional trust assumption? Because if the validators can remove funds from the escrow, they can do all sorts of things as well, right? And how do you actually monitor what they're doing? So this one, then you have something called plasma bridge. Some of you, again, might be aware of, because this is one of the two bridges that you normally use to move tokens to polygon. And this particular one has a very interesting documentation. It says in the documentation that it provides increased security guarantees because versus a seven-day withdrawal period. And during that period, you can challenge validators from polygons. So it's kind of like a plasma exit mechanism. However, the best of my knowledge, this was actually implemented and deployed on a testnet, but it was never deployed on a mainnet, right? So if you look at the mainnet code, and by the way, who's looking at the mainnet code of the bridge, you know, the contract, probably very, very few of you, you'll see that the method that allows you to actually challenge the validators is empty, right? You can't do that. So frankly, the plasma bridge right now has the same security assumptions as the POS bridge, the main bridge that you normally use to the polygon. And it's got this user nuisance of seven-day withdrawal period. And the last one that I wanted to mention, which in the documentation, the risks were properly disclosed. But again, I think that the user should be aware of that if you use the OmniBridge to move your funds to the XTI chain, they might invest some of these funds. They might actually put the funds that you normally expect to be in the escrow, into other, into compound or wherever they like actually, right? So normally it's called rehypotheicication. This is the practice where, you know, banks are using your funds to actually invest them, and you're running into liquidity risk potentially. If you were to withdraw all the funds, it, they may not be available. They might be like locked somewhere in, in, say, other or whatnot, right? So the whole process is very transparent, but the power of validators to actually do that may be surprising to some of you. Because again, it's a question, what are the security assumptions, right? And what do you normally expect when you put the funds into the bridge? So, so now with all these examples, you may wonder, you know, how do you actually collate all this information? And how do you actually make it available to the users? And this is a challenge. We've got hundreds of bridges. We've got hundreds of different destinations. We've got hundreds of tokens. And every single transfer may be actually different, right? And this is a challenge for us as well, because we really wanted to make it very transparent to everybody. And we wanted to make sure that users are actually aware what exactly is happening behind the scenes. So, so we try to kind of, you know, make it the whole framework user friendly. And I will quickly summarize what you will be seeing on the L2B bridges section. So first of all, we kind of differentiate primarily two different bridge types. And the first one is a token bridge. And that's the bridge that means tokens on the destination. And then, so this is something that, you know, normally you should be, like, intuitively expecting, right? You put tokens in the SQL, the bridge means tokens on the destination. However, a lot of bridges cannot mint tokens, right? Like, take die is an example. I mean, most bridges won't have access to die minting facilities. So they have to do something different. They have to, on the destination, they have to create a liquidable. They have to mint something or maybe, you know, through some other mechanism, and they will, like, swap whatever they minted for the die that is, like, sitting and waiting for you on the destination. And we call these types of bridges liquidity networks. And I think what is the most confusing for end users is that if you go to UI of almost any bridge, you will not know if you're actually using token bridge or a liquidity network. In fact, some of the bridges are hybrid. Sometimes, for some tokens, they may actually mint you tokens. Sometimes they may use liquidity pools. And it, like, as in the case for the multi-chain, you can have, like, some mixed results. Some of the tokens may be minted for you as some of the tokens may be actually coming from the liquidity pool. So these types of bridges we will call hybrid. And again, if you compare token bridges to liquidity networks, they have a very different risk profiles. So for the end users, I think it's very useful to actually understand the difference between the two, right? You have unlimited liquidity for the token bridge. You have tokens that, if you keep the token at the destination, you will face the risk of the validators of that bridge. And generally, token bridges can be quite slow and expensive, while the liquidity network is almost like the opposite, right? It has limited liquidity, typically. So you may end up with your tokens being stuck. But tokens held on the destination are not at risk of this network. They're actually at risk of the token bridge that was used initially to move tokens to the liquidity pool. So again, this is the risk that's actually quite difficult to disclose. And finally, they can be fast and they can be cheap, right? So this is the column on the L2B, which you can check very quickly. And this is something that should be essentially easy to read for all of you. And if you use any particular type of a bridge, you know, I do encourage you to check it out and understand the consequences. More importantly, from the risk perspective, and this is like maybe a little bit more technical, is the question how the messages are actually relayed between the source chain and the destination chain. So technically, we use all sorts of terms for this, like arbitrary messaging bridge or some other terminology. But because we wanted to make the framework sort of user friendly, we just want you to understand what are the four, in our opinion, primary mechanisms that are actually used to relay the messages. And again, these messages are important because when you look your token at the source, the destination somehow has to be informed, how do you mean the token of the destination, right? So what are the four different categories? Well, first of all, you've got the third party, meaning that you have to trust someone to relay this message, and that particular party can essentially break you, right? So you put full trust on that party. Then you've got what we call the optimistic scheme. We relay the message, we trust that the message is correct unless someone actually proves that the message is incorrect. So your intuition should be like, who's watching the relayers, right? Who are the watchers and what is the length of the of the fraud-proof window? Because optimistic message bridges, they always have watchers and they always have the fruit, fraud-proof window. Then we've got bridges that we normally call as secured by light clients, and essentially what it means is that we trust the destination chain to tell us what happened, right? So when, let's say, Polygon validators say that something happened on Polygon, I don't check that this is exactly what happens, I just trust the Polygon validators. And on Ethereum, I just need to build software that will check the signatures essentially, right? So you're putting your trust on the validators on the destination chain, and the most secure bridges, in our opinion, are the trusted bridges that use Ethereum as the ultimate source of truth. So we don't trust anybody, we build smart contracts on Ethereum that will validate if the destination chain is not lying to us. Obviously there are two techniques right now, you can use ZK proofs or you can use fraud-proofs, that's why we've got ZK roll-ups and optimistic roll-ups, and if implemented correctly, these are by far the most secure bridges provided that there are no bugs in the implementation, right? So what can go wrong? I mean, you forgot the external validators, everything can go wrong, right? They've got full access to the escrow, they can mint whatever they want to mint, if there's a bug, you know, you can have billions of tokens minted out of thin air, and validators can censor, they can steal, they can freeze funds, they can do whatever, right? You have to fully trust validators. Now for optimistic validation, as I said before, you need to make sure that watchers are actually active because if no one's watching, the fraudulent message can be relayed. For the light client validation, if you're transferring your tokens to a chain that's weak, that has very, I don't know, it's a low-value chain and validators can be potentially 51 percent attacked, then your tokens again can be stolen from escrow, so you have to really understand how strong is the chain that you're moving your tokens to, and finally, for roll-ups, for full client theorem validation, in theory, nothing can go wrong, right? So funds cannot be censored, funds cannot be stolen, as long as there are no bugs in the implementation. And this is the how we actually show, who is validating all these bridges, and I think this is the most important column that you should all focus if you want to understand how a particular bridge operates. Then we have the upgradeability, so this is essentially the information whether the bridge can be upgraded and who have got the upgrade power, and again, we kind of have to assume that whoever's got this power is honest, so this is a very important security assumption. If you can upgrade the bridge, you can steal all the funds, that's as simple as that. And finally, and I think this is the most interesting aspect, which is often overlooked, is who's got the minting power on the destination, right? So take again DAI as an example. If you move DAI via three different bridges, let's say you use the make-a-dow bridge, and move your DAI to Arbitrum Optimus Starknet, your DAI will be essentially minted by make-a-dow contracts, right? And it will have exactly the same properties as your DAI on the mainnet. But if you move DAI through the polygon bridge, then your DAI on polygon will be minted by polygon validators, and they might actually have the upgrade power of the DAI. And finally, if you move DAI on phantom, it will be minted by multi-chain, multi-seq, right? So again, it's a question to you, I mean how secure you feel with your DAI in your wallet. So this is the last column that we show on our framework. And as I said before, I guess you know the end game for all of us should be to build trustless bridges. Because everything else, we need to put our trust on some other parties, and these bridges are very, very hard to build. We had some problems with Arbitrum Bridge. There was a bug, it was essentially fortunately uncovered, and the bridge was intact, but as you can see, the roll-up bridges can be buggy. Same situation happened in optimism, and this is one of the reasons why these bridges are right now not fully yet permissionless, and I hope they will be very, very soon. But even more importantly, as you can see from this transaction, that's actually moving, how much is it? This is actually over 700,000 ether from one version of the bridge to another version of a bridge, and that power has Arbitrum Multiseak. So even though you may think that Arbitrum has fraud-proofs and whatnot, they still have a Multiseak that can move all the funds from the bridge, and they did in this very transaction, and it doesn't really raise any alarm. So that was kind of interesting. We saw this transaction, and we analyzed this transaction. It was an upgrade, and everyone knew that Arbitrum was about to upgrade, but seeing such a transaction moving essentially billions of funds in one move, it's kind of scary. So to sum up, we kind of think that we have no choice. We have to put engineering effort into building those roll-up bridges. I don't think it makes a lot of sense moving forward to rely on third parties in the long term. In the short term, they may be quite useful because we need that functionality, but in the long term eventually we need to find a way to actually make sure that the code behind all these roll-ups is actually secure. And as I said before, I mean the code is very, very complex. These bridges are actually very hard to analyze. I guess for a while none of these roll-ups have shed the training wheels, so you should really also understand what are the current assumptions. But every single team that we talked to, they have promised us that eventually these training wheels will be shed. So there's some hope for the future, but how do we make sure that such complex software is bug-free and how do we make sure that these roll-ups will not be hacked in assuming months? And I think this is probably one of the hardest questions from the engineering perspective and from the perspective of the whole community. We don't seem to have a solution for dealing with discovery of potentially critical bugs without actually relying on some honest actor, right? If the bug is found, we all want some good guys to shut down the bridge, fix the bug, and restart the bridge without the bug. That's quite obvious, right? No one wants really the bridge to be to be drained by malicious actor. However, right now it just seems that the best we can do is to sort of create a multisig of some trusted security engineers, I guess, or a security council of sorts, and these guys can perform these sudden upgrades. And to make it permissionless and to make it immutable, that also means that we are exposed to potential problems. So thank you so much for listening and I do hope that the future is bright and hack-free.