Bridges Panel

Transcript

Welcome to fun panel on bridges. So, we'll get started very soon. But before that, like let me throw in some introductions. I'm Mudit Gupta. I lead security and smart contracts at Polygon. And here we have a collection of interesting people. So, some of them you can see the names up there. And we have a surprise entry in terms of Neve from Hexagate. And I guess I'll let everyone introduce themselves and talk a little bit about what they do.

Hello everyone. I'm Yosuke and I'm working at two companies. At the first, I I'm tech lead at Fuzzing Network. Fuzzing Network is optimistic and liquidity bridge focusing on Ethereum layer layer two. We support Polygon, Arbitrum and then Optimism for mainnet and then we support any other layer two like Linea and then Base for testnet. And then we I am also technical advisor at Skyland Ventures, which is Japan-based VC. And then they invest to they have investments to Taiko, which is

ZKVM. And then they also have an investment for Orbital. Yeah. I yeah. I'm very glad to be here and then thank you for giving me this opportunity. Hi, thank you so much for having me. My name is Irene. I am head of strategy at LayerZero Labs. LayerZero Labs is the creator of LayerZero, the protocol, and omnichain interoperability protocol, and Stargate, the leading native asset bridge. Hey, I'm Robert. I help on OtterSec. We read a lot of bridge code.

Um yeah. Hi, I'm Valerian. Uh I work for Quantstamp as an auditor. And uh I made some audits on bridges. Hi, I'm Hugo, co-founder of Flare Network. Uh Flare's an EVM Layer 1 based around uh optimized data acquisition. Uh the reason I'm here is we just released a bridge protocol called LayerCake, which is essentially follows an optimistic model, um but we think we've solved sort of or have good solutions for uh the griefing attack that comes along with optimistic models and the slashing issues that are very, very hard to implement with optimistic models.

Um I can explain more later or you can go to our website flarelabs.org. Hello everyone. Thanks Munit. I'm Neve, I'm the CTO and uh of HexaGate. We're a real-time Web3 threat intelligence um company uh basically uh discovering all the threats and on multiple blockchains. So we help protocols bridges uh Web3 essentially like any Web3 developer to be able to uh detect uh and prevent any threat that might threaten the protocol or uh its users. So happy to be here.

Thanks everyone for the intros. We have a great set of panelists here. Um I'll give everyone some context about this panel. So everyone you see here uh most probably applied for a talk that was related to bridges and then Munit was like, "That's too mainstream. Let's put them all in a panel and let them fight. Let's have some fun. Let's have some drama." And that's why we are here. So in like this 30 minutes of panel or whatever, we can't really change the world, but we can at least have fun. So and that's the aim of this. There is no scripted questions or anything. It's just all going to be from heart and hopefully we'll have fun.

And with that, okay, I'll shoot with first like uh Kickstarter question. I'll ask everyone for one bridge they would recommend everyone to use and one bridge they would recommend everyone to avoid. I can start. So, I recommend everyone to avoid the multi-chain bridge. Following the last event. And essentially like there are like great bridges and I think they are quite unique in the way in the space in the sense that bridges are mainly off-chain and that also brings a lot of opportunities to stop attacks.

Because many times like you have a lot of time to protect before an exploit really happens. Of course like it narrows down the attack surface and it doesn't mean there is no attack surface. So, all in all like there is both snark based bridges like ZK EVM ones like Polygon recently launched and obviously a great innovation consensus is also about to launch there there is as well. Alongside like the optimistic ones which there are available which we've been using like extensively the ones from Arbitrum and Optimism and so on. So, all in all like they're great

other bridges which we're using like any day on Hexa Gate. Yeah, thanks for that. Let's keep it like bullet points just one name to avoid, one name to use. I'm happy to go next. I I'll say maybe a hot take but into your point about reducing code exposure, I would discourage builders from integrating bridge aggregators. And I would encourage people to use Stargate, the most popular native asset bridge built on top of LayerZero.

That's interesting. So, I'll come back to that, but anyone else wants to pitch in? Okay, I guess not. Then, let's continue with this. This is an interesting one. Why do you not recommend bridge aggregators? A few different reasons. I think first one is around code exposure. So, with bridge aggregators, there's additional middleware that you're introducing there. And on top of that, you're also creating a basket of bridges and and thereby increasing the chances that one shard of it will lead to a hack. And so, if you're building a wallet, for example, it might make sense for convenience to allow users to just sort of route to the the fastest bridge, like

in like an airline industry or those like flight aggregators. I don't know what they're they're called. Priceline, something like that. Um, but with bridging, it shouldn't be an airline industry. Like security is actually paramount. It's like don't take the the JetBlue when you're transferring your funds. And then I think the the other primary reason I would talk about is services versus protocols. A protocol is something that is immutable and evergreen, open, permissionless. A service requires the creator company to maintain the integrity of the product.

And so, if in your infrastructure stack, you're leveraging something that requires the liveness of that company, requires the founder to not be arrested, it requires the devs to not get COVID, then, you know, you're building in a lot of dependency into your product. And even things like is a service that you're leveraging does it require significant amount of runway? Will they close their series A? In crypto, we see a lot of projects that just poof and like the slot connect is gone because they've run out of funds. And so, you should be leveraging true protocols and ones that are not dependent on the integrity of of human behavior, but

also the liveliness of a creator company. Fair points. I wish I had someone from bridge aggregator here. Would have been a fun conversation. But those are very valid points. Do like since we anyone wants to defend bridge aggregators here? Go ahead. Um Yes, actually this is something that we we've thought a decent amount about. I think I guess generally when we think about these sorts of bridge aggregators, you have like some set of like end bridges and then you know you choose some threshold of the amount of bridges to sign before you know you pass some sort of message through, right? So for example, if you want to optimize for like really fast messaging, maybe you have like one out of n.

You know, if if you want to optimize for like authenticity of messages, maybe you have like n out of n or like n minus one out of n or like you know two-thirds of n over n. Um And I think one difficult part, you know, I I kind of I kind of agree with Irene like in the status quo. I think right now you know there's not that many super legitimate bridges. And I think one difficulty is that like you know n is probably going to be something small, right? Like n is going to be like three or five or something. And it's pretty difficult to to find you know maybe like seven or 10 really reputable bridges that you can even put in some sort of aggregator set. And I think one difficulty there is like if you have you know only three bridges, you know, if

you have a two out of three that doesn't really give you a super meaningful improvement in security, right? I mean I think there's like two things you want to optimize for. One is like passing correct messages. The other is making sure that you don't expose yourself to unnecessary denial of service risk, right? So if you have like a three out of three multi-sig for example or three out of three three out of three aggregator, you know, if one of the bridges go down as Irene mentioned then your entire set goes down. Which is probably not great, right? So you probably want something like two out of three or three out of five. Um that being said, you know, I think as more bridges um develop and they become more mature, I feel like if we get to the threshold where we have like seven bridges that we're really confident

about, um maybe something like a four out of seven multi-sig or even a three out of five could make sense, right? You know, if you have four out of seven, three three of those bridges could go down and you we still preserve, you know, critical properties of liveness and safety. Um, and you know, I think that gives you a lot better guarantees than if you just have one bridge, it might be hard to know which one um to use even though there's a lot like, you know, a lot of relatively solid ones. Um, this way you're kind of just like spreading out the risk. Yeah, makes sense. I for one like I'm not a hater of bridge aggregators, I actually use them, they're super cool, but in a in a different way. So, I don't um as Irene was saying like integrating with the bridge aggregators is um I

think risky at least uh right now. The way I use them is like to search for the bridge that actually supports from where I want to go. Like I want to go from this weird chain X from this weird chain B and like there is I have no idea which bridge actually supports it. Like layer zero maybe, but probably not every these are two weird chains. So, I just go to the bridge aggregator and then it tells me like which all bridges actually support this path and then I can choose the best one. I can go there directly and do it. So, it's a good like Searching and discovery. Like I will say there is a a huge green space or white space for a tool like this and even myself when I'm doing like daily diligence on on different pathways, I

have so many tabs open at once. But then with bridge aggregators, I will say uh there often times issues with the data that they're actually pulling there and I think every other day we are in conversation with these teams about how to fine tune that. Yeah, for sure. They'll get better, but yeah, there's something there they can work on. Uh okay, moving on to the next question. So, as we have seen like bridges are a technology that has that is constantly under attack, especially now that um the last few big hacks in the space have been all related to bridges. Multichain, Nomad, Ronin, Harmony, all of these bridge like over 100 million dollar hacks. Um so to the folks here on the panel,

on the bridges that are left, not many are left, but among the ones that are left, um and even the ones that have recently gone down, what common weaknesses do you see? Like what what problems do you see in the bridges right now? Is this on? Yeah. Um the biggest fear I have for bridges is uh essentially criminal charges over the essentially what a bridge is, the majority of the bridge models, maybe exclude optimistic, maybe exclude layer zero, but certainly the multi-sig based bridges. So that's essentially a could be painted as a conspiracy to transmit funds that have not been uh

you know vetted. Uh and to me, I think, you know, with the SEC losing, you know, pretty heavily against uh you know Ripple, I think that another vector of attack is more sort of criminally based around money transmission without um without compliance. Um it's uh a weakness, but it's also a consequence of uh trade-off. I would say that uh if a protocol wants to increase the security of some part, they would have to increase the centralization, for instance, and the instantralizations have some positive effects in terms of

security over the whole system, but in the other way, it has also some uh drawbacks. And each uh a lot of bridges have some weaknesses based on the components used. Um but in as a in from another perspective, we can also consider this as a a choice a design choice. And we have to be aware of um the all the components of the bridge before trying to using it.

Yeah. Um maybe another comment from my end is that I don't really view bridges as some unique creature like substantially from different protocols, but only the fact this is there's only the fact that there normally uh um are in charge of like custody lots of funds because like they connect chains together and this is why they become so lucrative to attackers. And the fact that they're like a bit more of a complex uh beast, it makes them much more interesting for attackers like to actually research. Cuz in a different protocols eventually like you got a you have like a few primitives that you can work with a protocol. On a bridge, you have so much so much more. Uh and many of the attacks uh this

you've mentioned multi-sig were around like even private key compromises and that's only like just web two kind of uh threats for bridges. And this is because like the the team has probably haven't figured a way like to actually operate the bridge in a decentralized and more secure manner, but they're just like have those keys like managed in an unsecure uh way. Uh so I would say like just really hard to cluster like vulnerabilities on bridges, but rather say that the attack surface is so vast as opposed to uh just vast as opposed to just different protocols. So it just can be anything like private keys managing possibly like uh the bridge all the possibly Merkle proofs that can

be like validated in the in the wrong manner uh and possibly tokens can be attacked as well because and then you get like unbacked unbacked minting and so on. They're just like so composable in their nature. So, it makes them the tax surface just bigger. I have a feeling Robert will probably speak to this as well. We've used OtterSec for for audits. But to your point around the the risk vectors for for bridges being similar to just general protocols, the majority of bridge hacks over the last year were due to smart contract upgrades and largely made by protocol developers who were intending to introduce something that

was positive like a new feature or patching something. And so, if you're using upgradeable contracts to build a bridge, you are introducing all of the protocols that have integrated your bridge or all of the users to the risk of like widespread contagion. In the same way that you would never accept an upgrade pushed to your Trezor or to your Ledger, why would you do the same for your DeFi protocol? You should be able to to opt into it and those contracts should be immutable. And so, that was something that really informed how we designed the Layer Zero protocol.

How do you design a messaging protocol that is entirely comprised of immutable smart contracts, but also enables evolution with research over time with with better validation techniques since what we're using today should not and will not be what we use 5 to 10 years from now. And then, to your point around my fellow panelists point around like government crackdowns and things like that, also designing a bridge or messaging protocol to be censorship resistant, for example, from from day one and comprised, again, built with immutable smart contracts guarantees that your technology cannot then comply with or be perverted to fit into

different regulatory environments. If you build your technology in a way so that it can, it will be. But if you create these primitives that are evergreen and simply cannot, then they won't. Um I guess I'd kind of just Can I ask a question or can I disagree with people? Yeah sure. Okay. Um Yes, I guess one thing one thing on the legal risk I think one of my panel I think you mentioned like the legal risk, right? Um I I guess I wanted to clarify a little bit. When you say legal risk, are you saying that bridges are too centralized because there's like one entity that that is exposed to all of this legal risk or is it um like bridges as a whole like if you send funds illicitly that like the entire bridge bridge can be taken down?

No, no. I I I think it's essentially uh I think Irene's comment between the protocol and the service provision, right? Which is, you know, if you look at, you know, a multi-sig bridge, you have some set that have come together in some manner, usually without, you know, a decentralized process to come together, usually an agreement between each other. Uh that is if those people are transferring funds across chain that are essentially from a uh rotten source, that could very easily be painted as a conspiracy to launder money.

I think that makes sense. Okay. Yeah, for sure. Um that's a definitely an interesting risk vector and for sure the governments have their um eyes on that. But uh us being more experts in the tech, uh let's uh move on to the tech questions. So, I'll ask the like on bridges it's true like there are different types of bridges, not all bridges are same. I broadly categorize them in three categories, centralized, MPC bridges, and then the decentralized bridges, which work on proofs and so on. Um so, on that the MPC bridges have uh seen lots of hack recently uh with um multichain for example like turns out

all of their keys were with one person even though claim they claim to be MPC. Uh similarly with with Ronin uh they were MPC but five by nine and four of them were one entity and that entity also had access to the fifth. So again just one centralized player and similar thing with Harmony. So an open question here from a technology perspective that how would you guarantee or trust an MPC bridge that they are actually using the proper MPC technology and aren't just hiding behind MPC as a like as a wall?

Um I think we should add some redundancy at the level of the communicator. So between two chains the communicator has a role to watch is to do to watch what happens on the source chain to verify if it's a malicious or um normal request and then to relay on the destination. And uh the MPC is only one communicator and I think if we could add different technologies concurrent and to make a kind of meta MPC with

two out of three different protocols or different solutions maybe we could have a better and more secured way to communicate and to relay the the messages. However, I think it it would come with more commissions because more people would be involved. However, the risk of collusion would be lower. Makes sense.

Yeah, I I mean, I feel like this question is, I guess, um more about like how do we ensure decentralization of any validator set, right? Like I think, you know, the root cause of of these hacks, I don't think was like MPC. I think it was that, you know, the CEO had all of the validators on his personal data list account. And, you know, like once the guy got that got arrested, uh it it seemed like, you know, that that was a single point of failure. Um I mean, I I I feel like this is a pretty hard problem, right? It's like, you know, you can you can attest, and I think multi chain did attest, in fact, that they had, you know, relatively independent validators that when when we asked them, I think they they claimed that they only owned like seven out of

22 of the validators. Um But, you know, I I think it's really up to to the community or or people to like dig into the identity of of these validators and and try to ensure that they are like indeed independent entities that are, you know, hopefully reputable. Um and and have their own control, right? Cuz I think otherwise it's it's pretty hard, like from a pure technology standpoint, like only looking at the chain, I think it's essentially impossible to determine that like the the end user of these EOAs or of these private keys are actually different. Um you know, it requires some off-chain sleuthing or or some additional analysis that, you know, to to to paint a more complete picture.

And I would just add that another mechanism I've seen uh more or less uh implemented by the next solution of Chainlink is to have um the the actors playing the role of the communicator split in two roles. One that is doing the communication uh part, and one that is doing the verification that uh the communi- is the validators are doing the right job or not. And it's like uh a level of verification inside the verification component, I think. That approach of separating the roles and having two concurrent role both incentivized to act

in favor of the protocol could be a solution. Yeah. Um, yeah, I I kind of agree. I kind of disagree. I mean, I think that like at the end of the day you have like data from one chain and you want to get to another, right? And then like however you slice it, you have, you know, different parties attesting that data and then you want to like, you know, in in abstract you want to like take some aggregate set of those signatures and then come to some sort of conclusion about if if that data passing is valid, right? So, I think, you know, you could split it up in two. You could have like two different roles and, you know, maybe like one set needs to agree and then the other set also needs to agree and maybe that mitigates risk somehow. Um, but you

know, I I I think that still kind of runs into the same issue of like if if everything's centralized, you know, you're you're still screwed, right? I don't think it really fundamentally solves the problem. You know, you could slice it up into three roles. Like maybe you have like three different stages. Like one person proposes, another person like approves, and then the final person executes, right? Um, but does that really change anything? Like I think kind of at the end of the day if we're using these bridges, we really need to dig deep and kind of understand like are these actually separate entities or are they just like pretending or masquerading to be. I'll add one thing which again is more from the smart contract risk angle rather than the the human engineering side, which is that client diversity matters a lot as well. We talk about it

in in very different contexts like the Ethereum uh validator context, but in this case if uh a bridge has you know, requires 13 out of of 19 validators to agree, but all of the validators leverage ultimately like the same code or created by the same dev company, then the vulnerabilities that are introduced into one are like multiplied across all of those. And so, that's incredibly important to keep in mind as well. And some of the architectures that exist right now don't actually uh encourage client diversity or aren't open and permissionless to allow other protocols to run some of these off-chain components and actively participate in their security layer.

That's a very interesting point. So, on that, like how does Layer Zero promote client diversity? So, it's interesting that you were talking about Chainlink and their architecture. Ours is is is slightly different. Layer Zero deploys endpoints on all of the chains which we support. So, these are EVMs, non-EVMs, rollups, app chains, etc. These endpoints are smart contract libraries and these are immutable. Between the endpoints are the off-chain entities which we call the Oracles, plural, and Relayers, plural. And all an Oracle has to be is an entity which can retrieve and submit a block hash. And all a Relayer has to be is an entity that can retrieve and submit a transaction proof. So,

there are, you know, two separate tasks that need to be put into play. The protocol determines which Oracles and Relayers they select. And of the Oracles consortium, it could be three out of five. It could be two out of three that have to form a, let's say, like a yes from the Oracle side. And same with the the Relayer side. The protocol can run one of those components, meaning the protocol could run a Relayer of the Relayer consortium and one of the Oracles could be, let's say, the top 50 delegates of their protocol and provide more utility to their protocol token in this way.

And it's the message can only pass across the protocol if both the Oracles and Relayers consortium form an agreement. Otherwise, if if one of those um consortiums disagrees, the message reverts. So, this is sort of, you know, base security layer here and allows applications to price their their their security as they'd like. So, if you're building a game and you're transacting 5-cent NFTs between chains, it might make sense to use, you know, the custom Chainlink DON that was built for Layer Zero and the Layer Zero Labs Relayer.

But if you're circle, and you are moving USDC between chains as an omnichain token, you probably want to price your security a lot higher. You might want to run one of those components yourself. You may pull in highly reputable entity to run one of these relayers, and you can add on in more as you'd like. If you're a decentralized protocol, then your governance can vote to add more or swap in and out oracles or relayers based off their likeness and their performance. That is is how we encourage client diversity. Each of these entities are built by different dev companies, and it's in the hands of the application to to price.

Therefore, LayerZero is the line of security there. Makes sense. That's super nice. So, security with bridges, like it with everything, it's a continuous process. So, we've discussed a lot about things you can do really before launching the bridges or like at any moment of time. But, there is one aspect which is monitoring and incident response, which you got to pay attention to once you have launched the code, once everything is live. So, on that aspect, yeah, an open question to everyone. First of all, like maybe let's start with the good things this time. So, any bridge you are seeing right now which is doing something right, any example you can share?

I don't want to speak too much, so I'll Any bridge that is doing monitoring or incident response right, or any protocol in general? Yeah so nobody is doing it right, I guess. Yeah, so I think like maybe this circles back to the recommendation part where you asked like for recommended bridges. So, obviously there is a spectrum, and obviously teams with less personnel would have like less capacity to handle like security processes and all of that.

And when you have like bigger teams, which like develop a bridge, like they already have much much more capacity in order like to initiate like the right security processes, the right like instant response plan, the right monitoring in place, like mapping all the threats, and monitoring for them. So, of course like there is when we like I don't like this term like the diligence in bridge because eventually like the access to is to get obstructed and it really depends on what what chains you want to move from. But for instance, like if you take big companies like running bridges of like normally what you see is that they're really minded about security.

And then they employ like things like monitoring, instant response, mapping out invariance in order like to look for those invariance in real time and so on. And from our experience with working with with bridges, like what we normally see when a bridge is like incorporated into securing the bridge, like they work with us, we map out like all the all the known threats, like for instance, just giving an example, like if you're running even a layer two, like which I treat like layer two to layer one token bridge, if it if it's doing like a ZK EVM type of bridge, it's a very complex

technology like for just a few auditors to just audit and and conclude a SNARK is okay, like the arithmetics are okay and all the circuits are just make sense. And if the bridge is that huge, it makes obviously a huge opportunity for attackers to actually research that and find a vulnerability. So, for instance, like mapping all those threats as a bridge as a as a company operating a bridge and then monitoring for what happens if someone finds a vulnerability in the snark. Like without knowing what the vulnerability is, like maybe we can monitor when the snark validation breaks. So, what we see as a company is that like normally when you mature and you grow, like those big companies like

like Polygon and others when they launch new stuff like that, normally they also are really minded for monitoring mapping all all those known threats, but monitoring for the unknown threats and so on. So, I think this is kind of a quick way to do a diligence of who is like have the capacity and security personnel to actually run an instant response plan and like security like the right security processes in order to protect a bridge.

Yeah, nice one. Can I Yeah yeah. Yeah, I've always been like a little skeptical of monitoring. I mean, I think like do you really care if like do you really want people to tell you that you've lost $5 million or do you like rather not lose $5 million in the first place, right? Like I think monitoring is kind of funny because it's like oh, after we got hacked, okay, now we know that we lost $100 million. It's like okay, it's kind of late now, right? Um, you know, I I I think bridges I think there are like meaningful mitigations bridges can do. I I just don't know if they're on the monitoring side. Like for example, one thing that I think LayerZero does and a couple other bridges is having some sort of rate limit on the total amount of withdrawals. I think this this is pretty

intuitive, right? Like if you know, if we have some sort of you know, random chain, it probably doesn't need to be sending $50 million back to Ethereum mainnet, right? Like you know, where where does that money come from? Um, I think there's a lot of sane mitigations in terms of rate limits that you know, probably make more sense that could help mitigate you know, even in the case of say a relayer compromise or like some sort of endpoint compromise on the other chain, you know, at least you can limit the amount of damages. And I feel like that goes a really long way as opposed to you know, having some sort of monitoring setup that's like okay, we lost 30 $30 million, but it's kind of late now. Yeah, maybe it's small comment from my end and on the monitoring side. So, like there are there is a spectrum for

monitoring like so from our perspective like when we monitor stuff like our goal is eventually to detect the threats like beforehand. So, in the case of bridges like many times like it really depends on the bridge like many times especially for bridges because there is the off-chain component and sometimes there is a delay before anything happens. And also like there is sometimes a natural delay for attackers when they deploy just the attack code the contract which gives like opportunity for companies like us to detect the threat up front but in but again in bridges like you have much more opportunity to also detect fronts detect threats before they impact any digital assets like for example um if you monitor like for a bridge which does like a multi-sig kind

of uh signing so many times like before withdrawal is even possible like you could monitor like whenever the multi-sig is concluded that some some withdrawal is possible for example uh there are like there are many examples of multi-sig bridges which like do that and if you had monitored like in real time the fact that uh something bad is going to happen before like the malicious withdrawal happens uh then you're able given like the right processes because it's inseparable from monitoring you're able to mitigate the threat. So, monitoring can take like pre like we're aiming for pre hack uh Oh yeah, I think we're talking about

similar things then. I guess you're you're talking about like monitoring as the transaction goes to the bridge and not like after it like lands on the other side. Um Yeah, on that like I can So, Yeah, go ahead. And so I think uh probably bridges that are trusted probably need a lot of monitoring cuz you know as we've basically been discussing this entire most of this conversation is how do you make a trusted bridge essentially as decentralized and least trusted as possible whilst it's still trusted but when it comes to something like an optimistic bridge you still need quite a lot of monitoring specifically to monitor you know are people submitting fraud proofs

you know and if cuz if a if a malicious event is is you know missed your you know your window is finite. One thing that we had observed and learned from with a lot of these bridge hacks was you know issues with accounting for example that that show up in how these smart contracts are written and so we created something called pre-crime and we actually don't talk about it very much but we'll do moving forward since we are working to to scale this so that it protects all applications that have integrated layer zero. Pre-crime is a proprietary security module which forks every message that goes across the protocol and test it locally against a set of invariants determined by the application. Only then do the messages

get pushed back and run across mainnet and it's called pre-crime to stop a hack before it happens and so that invariant could be like accounting around avoiding the double spend problem. It could also be you know if you're an NFT project and integrating layer zero to enable seamless movement native movement between chains. It could just be like white listed addresses. Whatever you like for that invariant to be as the application developer and this is what has protected stargate since it's launched more than a year and a half ago through its peak of 4.4 billion in TVL the whole team just watching every single black hat attacker try and and break the the protocol. This is what protected it and then in addition to Robert's point about rate limiting which we have introduced

when we launched the Aptos bridge for the new non-EVM layer one last fall we decided to adjust the block confirmations and set them to be incredibly high. It was, you know, arduous. It took about 3 days for transfers out of Aptos. However, that was a security measure we took because it was a new chain and and there are a lot of unknowns. Uh over time, we've been reducing those block confirmations, but, you know, one thing that LayerZero enables and and we built into the protocol was uh ownership of the application developer to determine those block confirmations. And so, if you're trying to avoid uh like reworks involved with a particular chain, you might want to set those higher. Uh if again, pricing your risk.

If you're just transacting 5-cent NFTs, maybe you set all of the block confirmations really low. And that's okay. Yeah, 100% makes sense. Monitoring is like a lot more, obviously, than just detecting a hack once it has happened. So, uh you obviously like once the hack has already happened, then detecting it is not as uh important, at least for the protocol. But, uh monitoring is a lot more than that, especially for bridges where there is a time delay between the transaction initiation and settlement. You can intercept a malicious transaction uh in between that time. Uh so, for optimistic rollups, as uh mentioned, like you need uh fraud proofs. So, someone needs to be

generating everything happening on the chain to generate these fraud proofs. For uh like other bridges, you can monitor uh smart contracts being deployed that might try to create malicious messages to your protocols and things like that. So, there are a bunch of monitoring uh tooling that is definitely important. Uh and even like often times, you can white hack during a hack. A good example would be Nomad Bridge. So, Nomad Bridge was like slowly hacked over hours by many parties. Uh it was kickstarted by I believe it was a black hat. I don't remember if they returned the funds or not. Um but and then like a bunch of white hats kicked in and started uh

rescuing what they can. So, that only uh like if they had even better they had some monitoring and that's why like all of this uh they could respond in time. But if you work on monitoring more, maybe you have uh playbooks defined, some automation around this that like kicks off automatically when something is detected, then maybe you can act faster, save more funds, um and so on. So, it is important. And this reminds me of a interesting war room story I had. And um I think we'll we'll let's start discussing some war room stories.

Ideally uh around bridges, but whatever comes to your mind. I'll start with this one uh which is related to monitoring and why it's important. So, in this space, lots of people, not just protocols, are monitoring the chain for malicious transactions. And I guess we have only 1 minute, so I'll uh round off this story really quick, but uh there is one one group which monitors for hacks so that they can short the token and make money. So, what they do is they uh I won't go into specifics of how they do it because uh like that that's also a secret sauce for them, let's say. But if they detect anything that is about to go wrong, they will short the token. If something doesn't go

wrong and now their short position says whatever, they will reach out to the protocol, tell them, "Hey, like we detected this in your protocol. Have a look." It's a very interesting ideology which is like sustainable. So, I was in one war room where they detected something and then nothing happened, so they reached out to the protocol uh within like 10 minutes and that, "Hey, we detected this, but your protocol hasn't been drained yet." The protocol, without understanding what this is, immediately uh blocked immediately paused the protocol as their response, which is good. At this point, they only had a contract address which was private source code Um I and all they knew was this contract has been deployed by malicious address

known malicious address and it interacts with their contracts. So at this point they don't know if it's a hack or they are just using the protocol but they paused it and then we spent next one hour de-compiling the contract understanding what it does and it turns out it indeed was an active attack that they were going to pull off. Nobody knows why the attacker didn't execute the transaction. Maybe they were testing it. Maybe gas was too high. That was expensive times or whatever but they deployed the exact like the attack contract but didn't execute it yet and within like one hour this team although detected by someone else but was able to pause the protocol fix the vulnerability and save all of the TVL

they had. So monitoring can be important just because like in this space although everything can be instantaneous it usually isn't. People do things one by one. Like they it's still being run by immature kids like most of the hacks are being done by immature people if I'm being honest. So you still have time to respond and that's why it's important. Before we wind up So I'll leave it open for like final comments if anyone has like really short 30 seconds maybe. The monitoring I think it is important to have a mechanism that can minimize the damage even if your smart contract had a exploit or hacked because

like Yeah. I think as a community we really should focus on building trustless bridges not making trusted bridges safer. That's solid. So we have next panel on auditing. I'll warm up the audience with an auditing question, fun question here. So, everyone we started by asking everyone like name your favorite bridge and least favorite bridge. Let's do it for auditors. Name your favorite auditor and least favorite auditor.

Go ahead. I can give it a shoutout to some auditors and I'm super lucky to have like personal relationships with a bunch of them. One sitting next to me, which is Robert from OtterSec. We're also huge fan of the Zellic team, the Zokyo team, Paladin team, and always looking for more. One thing I'm super proud of at LayerZero is we have spent more money on audits across every single protocol in crypto. So, we're in you know, tens of millions at this point and we are happy to keep spending money on audits. Every piece of code we push is immutable and even if it's four lines of code, we will get multiple audits. So, if you're an auditor and you also want to be my friend, come find me.

Anyone else wants to name anyone? I guess not. Then we'll round it up here. Thanks everyone for being on the panel and thanks for the audience. Thank you.