How Solana's Largest Perp DEX Was Exploited for $285 Million

Transcript

Hi everyone. Welcome to Unchained. Your no hype resource for all things crypto. I'm your host Laura Shin. Thanks for joining this live stream. Before we get started, a quick reminder. Nothing here on Unchained is investment advice. This show is for informational and entertainment purposes only and my guest and I may hold assets discussed on the show. For more disclosures, visit unchainedcrypto.com. Introducing Nexo, the premier digital wealth platform. Receive interest on your digital assets. Borrow against them without selling. Trade a variety of cryptocurrencies all in one platform. Now available in the US. Get started today at nexo.com/unchained.

Today's topic is the Drift protocol hack. Here to discuss is Omer Goldberg, founder and CEO of Chaos Labs. Welcome, Omer. Hi Laura, thanks for having me. Solana's Drift protocol, the largest decentralized perpetual futures exchange on the Solana blockchain, was hacked for $285 million, which just for context, uh the protocol's total value locked before the attack was about $500 million. So, that was over half of the money uh in the protocol that was drained. That also puts this hack amongst the top 10 DeFi hacks of all time and the biggest this year thus far.

The Drift token dropped from over 7 cents to 3.9 cents on the news and is now trading a bit above 5 cents. So, the hack was pretty multi-layered and also quite methodical, it seems. Um it sort of seemed chilling reading about it and it made me feel a little uneasy. >> [laughter] >> Um the attacker or attackers compromised the system a little while ago, actually, and then they kind of waited. So, yeah, there things about it that seem similar to the Bybit attack. But anyway, Omer, why don't you walk us through what it was that it appears these hackers did to uh perpetrate this hack.

Yeah, definitely. Um and I really agree with what you said in the opening that it is chilling. I think we've seen a lot of hacks, unfortunately, already in this year. Um many of them seem like it you know, could be someone who's potentially less experienced and gains access to some uh key or admin privilege and kind of takes it from there. Um but this one was very technical, uh well thought out, and from what we know today spanned at least uh 3 weeks. Um I can jump into kind of the entire timeline or >> Yeah, yeah, please do.

Cool. So, around I think as of today, around 21 days ago, um for if I'm not mistaken, for the first time, uh Drift initiated uh a migration towards a multi-sig. Um this multi-sig was a two-of-five multi-sig. Uh notably, it had zero time lock on any of the functions it could execute. And for listeners, what time lock means is even though certain um privileges in an application need to be signed by white-listed addresses, a time lock basically says after they sign it, there's a gap uh between when it actually executes. And this is typically an additional uh security precaution to make sure that what was signed and the change enacted is indeed what you want

it to be. Um so, this happened about 20 days ago. Um and in parallel to this, there was a fake token set up called CBT. Um completely fake, only no kind of pre-existing um activity outside of this hack. And the attacker waited. I think some of the speculation was that they waited until April 1st for April Fools' Day, so that when messages um of the hack were being dispatched, there'd be confusion about whether or not it was real or a prank. Um and pretty swiftly, um within seconds, at least for the first batch, the attacker executed uh a series of transactions that effectively enabled them to

uh deposit and and manipulate the price of the collateral uh into the Drift vaults and extract all of the blue-chip assets. Uh so, that was like the first part of the attack. Later, there's how they kind of got out, bridged out, and into Ethereum. Um but there are at least five or six discrete steps that the attacker had to do, which for me indicates that uh this was not like a random person who stumbled upon the keys. They studied the program. They were methodical um and strategic in how they planned everything and executed it.

Yeah, yeah, and we'll break down more of these steps um as we go, but um when I was looking at this, it really felt like the original sin here was around this the admin key. So, explain how it was set up and how it appears to have been compromised. Yeah, so um in contrast to last week, we were talking about the Resolve hack. Um and the Resolve hack was unique in the sense that there was one key uh that had effectively unlimited privileges to mint as much USR as they wanted, which made it easier uh for the hacker in terms of how many keys needed to be attained and compromised.

Here, it wasn't a single key. Uh it was a multi-sig. However, it was a two-of-five multi-sig. So, this is like the minimum amount of uh signatures that you would need in a multi-sig. So, it's one step above a single key. The We're We're still waiting for an official, I think, postmortem. I think Squad have uh written a few updates as of right now, it doesn't look like that their infrastructure was compromised. They're the multi-sig provider on uh Solana. Drift are are still in an active war room, so we don't know exactly how, although there is speculation uh with the recent uh wave of supply chain attacks that have been kind of perpetrated and and uh executed by uh Lazarus or or DPRK. And by that, you're

talking about the Axious attack that So, I'm not a technical person, but it's something like there's these libraries that just hundreds of millions of people access kind of very frequently. And so, you know, these these exploits in a way could be sitting in a lot of different systems. Yeah, it's exactly that. Um Axious is but one of them. Axious is a particularly popular package, but developers in crypto and web two, they'll like install, you know, hundreds, sometimes a thousands of different packages and dependencies that are open source and written by other developers. The way that this particular like method works is it's actually quite clever. So, if you can actually uh receive control on one of these

packages, you just make a tiny modification where you can add a piece of code that effectively um once run on any developer's machine, gives you root access to the machine. So, you can read and write whatever you want. And the second something like that happens, which we've seen um with Axious last week with Light LLM, one of the biggest AI packages, but there've been hundreds of packages that have been infected in this manner. You can do whatever you want in the machine. And this is a much easier vector because you don't need to break any cryptography. Um you just need to maybe do a little social engineering um for one of the many open source developers that may not even realize who and how their package uh is being used by. And you have access to the whole machine.

So, this is like it allows them to cast a wide net. Yeah, so the other piece that was interesting is you tweeted about um you know, some of the steps that you saw. And um when you talked about that new multi-sig, you said basically, so Drift created this new multi-sig and it was a signer from the old multi-sig that created it. But then you wrote, "The signer did not add themselves to the new role." And at first, I was like, "This must be a typo." I was so confused. Then I realized, "Oh, wait." What he's saying is you know, somebody had gotten a hold of um the keys of the previous signer, created this multi-sig. They probably weren't aware.

Um and then you noted that basically, the new multi-sig was immediately signed by a second co-signer 1 second after it was created. And that met two out of five thresholds. So, when you see that kind of evidence of you know, the steps leading to the hack, what is that say to you about you know, how this hack was pulled off and why uh the admin key was so critical to it? Yeah um so, this next part is a bit of how I interpret the event and trying to like understand how it could have happened.

Uh but it's still very much in the fog of war, but um Drift had actually communicated about the migration to like a multi-sig. Um and again, I think we mentioned that this might be the first time this happened, at least for this specific role. Um I'll I'll I'll speak on why I think it may have happened um like suddenly now, a week before the hack. But it it looks like the this was a planned event and I think that the hacker had some type of access that the team didn't know about. Um and so, he may have had access kind of to the rest of the keys and that's where the two signatures came from.

Okay. Okay. So, then the other thing that was so fascinating was um see, you briefly mentioned this CBT token that they created. And they gave it some wild parameters, ones where if anybody had looked at it, they would have realized like this is not a legit coin. What were those parameters and why would that flag that this coin could be so dangerous? Yeah, so I think just to clarify between two things. The The coin CBT itself is just like a a scam token that was created for the purpose of this attack.

Um had very low liquidity and just a regular kind of token on Solana. What did have the unlimited uh parameters and infinite parameters and next parameter set was the market. Um, so this enabled the the user or the exploiter to add CVT as a new collateral asset on the Drift protocol. So depositing it as collateral, they then continued to pump the price of that pool the cuz they they also as they configured the market could decide which oracle was being used. So created a token, uh, spun up a fake oracle or like a real oracle that was pointing to the fake pool, pump the price, and then, uh, they had all of this kind of credit in the system that

they could use to withdraw and drain Drift from all of the blue chip protocols. So this is again why I say it's sophisticated because this attacker was preparing. He he spun up the feed, he was running fake volumes, uh, in the AMM where the CVT pool um, where the CVT pool is being traded and the oracle read the price from. And then also created a fake market on Drift, uh, with max risk parameters, all of this happened very like un- unnoticed effectively during the time of the exploit and with no restrictions. Yeah, yeah, so here's where we get to that original point we were talking about about how this feels chilling because so far we can see that not only was there a social engineering

component, but then there was an oracle manipulation and then there was market manipulation >> [laughter] >> like like it's just, you know, using all the tools in the toolbox in uh, you know, I'm I'm going to give him some credit in a creative way. Um, so so you know, at that so at that point just talk about then exactly what they did with the with the coin to to pull off the attack. Yeah so A in terms of all the toolboxes like very reminiscent of at least the market the the oracle manipulation pump of Mango Markets, um, getting access to all of the admin keys is very reminiscent of USR. So definitely kind of drawing on a lot of different techniques and stacking

them together to do this. Um, the main difference here however was uh, the manner in which the market was created. Um so you know, in any kind of lending application or vault application, it's a it's a pretty big deal which assets can be white listed as collateral because you're extending a credit line against those assets. So again, this was an unknown token with those privileges of the admin. They were able to white list this token. Um, and decide where the oracle was coming from.

Uh, what what kind of AMMs it was reading from. And here once they pumped on a very low liquidity pool the price of the asset, effectively they had hundreds of millions of dollars um, in collateral. At least that's what the Drift program uh, viewed it as and gave them all this credit to extract all of the blue chip assets against it. So it it's um, there's a few extra steps here, but the actual method of extraction is something that we've seen time and time again. Yeah, honestly this reminds me of when um, for whatever reason after Avi Eisenberg did the Mango Markets attack, he reached out to me saying he wanted to come on the show. And when I interviewed him,

I I think I used the word market manipulation or something. I don't remember exactly what what I said like the actual words, but he said to me something like, "Oh, well, what is the legitimate price of a token?" Like he kind of disputed that it was manipulation. He was saying that was the legitimate price at that time. So um, you know, again that's, you know, the kind of maneuver that was pulled here like at least when it comes to the smart contract. Um, Interestingly, I don't think I've ever shared this before, but Avi Eisenberg also contacted us at that time um, because after the Mango Market attack, uh, he tried to wage a similar attack on Aave. Um, and we had

configured the parameters such that we we had these machine learning models which estimate the cost of the attack. So Avi was asking us for access to it. He's like, "Hey, can I see if my numbers match up with yours?" Um, so that was one of the Yeah, that was one of the crazier DMs that we received at Chaos. Yeah, clearly he's um, not not the typical person. >> [laughter] >> But anyway, okay, so let's talk about the next bit because um, there's another component that I've seen I I it has been generating some controversy on crypto Twitter, which is this notion about uh, durable nonces, which is kind of a core part of how Solana works. So explain what a durable

nonce is like like what the purpose is for them, and then how that also became a potent attack vector. Yeah, so the durable nonce basically like what it solves for is that you can solve you can sign transactions that don't have time expiration. Um, and and there are legitimate like use cases for this in an application where the user doesn't want to be burdened with uh, signing a bunch of transactions, perhaps the application wants to ask the user to give a few permissions up front and then streamline the UX from there. Um, so this is like one of the things that it solves for, but what it did here is as soon as the attacker had access to those keys, they were able to sign in those

transactions and not ring any alarms and just wait for the perfect time to execute the attack. Um, typically without the durable nonce, they would have to sign and execute the attack I think within a two-minute time frame. Oh, okay. Okay. So here's like a funny thing. Um, or oh, okay. No, that's okay. So sorry, I'll explain in a moment what I meant by that. So okay, so Anatoly Yakovenko, the founder of Solana Labs, tweeted about their durable nonce. He tweeted quote, "Durable nonces observed on chain. So to sign it off chain, attacker creates the nonce on chain first and then transfers authority to the target. Your cold storage offset can

actually monitor for this and flag it with with PagerDuty. There's no way to not have this feature because cold storage custodians have to have arbitrary amount of time to recover the key. So any system with smart contracts will basically end up with some version of this no matter what." So do you agree with him that there is no other way to to not have this or do you think that durable nonces should be rethought in some way? So so I understand uh, what Anatoly is tweeting is I think my understanding of that tweet is that you can monitor and set alerts for this. Um, so what I mean in theory you can sign any type of transaction. Here there was a transfer

of authority, which is actually something that we've seen in many many DPRK uh, attacks that they transfer authority to a different wallet in in a an attempt to obfuscate like their addresses. And all of this can definitely be alerted and monitored for. So my understanding of the tweet and just generally my thought on durable nonces is using the correct way, it's not like a bug uh, in the VM. Unfortunately, it it's been used for a lot of exploits. Uh, it does have legitimate use cases, but for sure it's something that you can monitor uh, and get alerted on and that's where PagerDuty comes in. Uh, especially for anyone that's dealing with hundreds of millions of dollars or doing, you know, hundreds of billions or even trillions on an annual basis from a notional perspective, uh, these are exactly the

things that you want to be looking out for and PagerDuty is just uh, uh, very common kind of software solution to alert you when these things happen, uh, get through your do not disturb and kind of get the team that's on call to start taking a look. Okay, I guess the one thing is um, if the pager's going off then isn't it too late at that point? Like like already something's happened, right? And like you might not be able to do anything about it. So is that really the best solution? No, I mean I so basically in anything in security or risk management related or operational security, the the way to solve this is actually having like a good set up sound architecture um, and robust system. And that's number one. This is like after the fact. And if

we look at even hacks from the past month like USR and even here, um, it looks like it took the team hours to react. Um, and so that would solve for that second part of knowing that something bad has happened, but it's not necessarily going to prevent it. Right. Okay. Yeah, that's why um, hm, I I don't know. It feels to me like at the very least potentially it could be structured differently, but I'm not a technical person, so anyway. Um, okay. It could be structured in many ways to your point, right? Like this is one of the big uh, breakthroughs in, you know, EVM and SVM is that it's Turing complete. Um, you can program whatever you want. Um, and so yeah,

there's many ways to prevent it. Um, but when something bad happens or something irregular, you want the monitoring to just to alert the team and even the partners who are integrating. Yeah. Okay. Well, in a moment we're going to talk about what potentially Drift protocol should have done, but first we're going to take a quick word from the sponsors who make the show possible. Step into a new era of wealth. Discover Nexo, the premier digital wealth platform. Manage your crypto portfolio with confidence and control. Receive interest on your digital assets. Borrow against them without selling. Trade a wide range of cryptocurrencies, all in one platform.

Now available in the US with 30 days of exclusive privileges for new clients. Experience Wealth Club Premier. Access enhanced interest rates, reduced borrowing costs, and crypto cashback on swaps. Get started today at nexo.com/unchained. Back to my conversation with Omar. So one other thing that I wanted to note here was um in I mean you had such great tweets kind of outlining what happened, but one of the points you made was you said there's no time lock, no multi-sig, and no delays. Um you know, which is how all this happened. I also saw uh this is very direct. Uh B Manny Maxi tweeted

quote "What makes this $280 million Drift hack so devastating is that it's not a smart contract exploit. We've seen flash loans breach similar platforms before. In this case, a dev was fished for an admin key. It's inconceivable that no risk factors are disclosed anywhere." And then he said, "If I lost my money in this, I'd be certainly lawyering up right now." So I'm just curious like when you kind of look at their setup, how would you say it differs from best practices?

I think there are a few ways. It's not just one, but um time lock is definitely one of them. And in this case, like having a time lock on when the transactions were signed and when it actually executed would have given a window of time uh for the team uh to potentially stop it. So that's number one. Um the reason for a time lock, yes, it's hacks and exploits, but it's just also to make sure that you're doing what you think that you're doing. So in lending markets, in derivative markets, when you're listing new assets, when you're changing parameters, and you're making changes that are sensitive to the system, it's very common that you'll have, you know, either time locks that are a few hours or even a day uh for the thing to go through, for more parties to kind of look at it, whether it's auditors, the

risk team, or the core team itself. So that's number one. Like if had even if everything had gone wrong with a time lock, it still would have given them an opportunity uh to potentially stop it. And definitely for all the 20-plus integrating partners uh to reduce and mitigate exposure. Um that's on the time lock. Um I can go more into time locks or speak about maybe the multi-sig setup um or some of the infrastructure. >> Anything you feel like Go for it. >> yeah, done better. Yes, I mean multi-sig two of five again, it's it's one step over a single key. Um so for something that houses so much TVL, you'd want to see um more. Uh three of five And ideally, you can use kind of things

like biometrics to ensure that the person uh who's signing is actually like who you think it is. And there's so much you can do there today of the signing itself. Um and then it's just alerting. Um all of these safeguards and admin privileges were compromised by the attacker, but all of this happened without any alerts uh to the core team and not to any of the teams that were integrating. So I think most of this news broke through Twitter. It took several hours. By the time the news was out there, the the the core Drift team had communicated. Um there's also nothing that the 20-plus integrators could do. And then similar to kind of the contagion with Morpho and USD that

we spoke about last week, it's also on integrating applications to understand the counterparty risk of whatever they're integrating and set up alerts, uh circuit breakers, and risk guards as well. Yeah, yeah. It's um I honestly like I so I don't know Drift. Um and I I don't want them to like [laughter] take what I'm saying as as um you know, being harsh at a time when they're sort of down bad, but you know, it just sort of uh looks like they weren't super paranoid. Like to me, that's how it you know, reads. Like and I'm not a security person, but I've obviously written about it a lot. Um so yeah, there was just like a sense to me like like yeah, it just wasn't paranoid

enough. Um but you started to talk about contagion, which definitely was an issue here. So explain, you know, how this hack started affecting the other money legos in the Solana ecosystem. Yeah. Um M- maybe just a a word like on the team before I jump into that. And and just for all teams, um I know uh some of the core contributors pretty well. Uh they they spend time uh in New York amongst other places that we frequent. And they're a super hard-working team. I've seen them work all hours of the day probably over the past few years.

Um so I don't know that they're not paranoid and we'll wait for the postmortem so much as um there's all of these audits and things that you should do in a web3 system. But again, all of these exploits that we're seeing are classic web2 opsec um kind of risk exploits. And there are systems like PagerDuty, but also CrowdStrike, Palo Alto Networks, all of these very big companies that they're literally built to do and help mitigate exactly these things. So I don't know about their security posture. We'll wait for the postmortem, but um my experience is that this is something that I've seen kind of um less prevalent amongst web3 teams in their understanding.

Okay, so the contagion. Yeah. The contagion. Um like you said this is a top 10 uh hack in terms of TVL and funds lost, correct? Yeah. Yeah so >> as of yesterday. I >> As of yesterday. >> Yeah, when I checked it yesterday. As of yesterday, and I think also every time that we check, it looks like the number uh in terms of funds lost has continued to increase as more exposure um is being kind of disclosed. I think this was number one in terms of discrete protocols that were affected with over 20. So I can pull up um the list here, but effectively the >> Yeah, you can also share it in the chat and the engineer can show it on screen.

Sure. Let me put it in chat. Sorry, this is the wrong one. >> [clears throat] >> It's actually on the Twitter thread um of the of Chaos Labs. So if you want to pull it up, we just published an article that um reviews everyone who was affected by this. I'll I'll drop the link in the chat. Okay. Yeah. There we go.

Now we can talk about the contagion itself. Um so roughly, you can break it down into three categories of applications that were um affected hit by it and as a result um have lost kind of user deposits in in one way or another. The first is the vaults. Um so Drift started as a pure perp DEX. Um they've extended uh the product to offer um uh the Drift vaults effectively. And a bunch of curators have created their own vaults on top. Um so there's a curator called Prime Number um that had over 10 million uh deposited into Drift um via their vault at the time of exploit.

Gauntlet had I think 6.4 million. Nitrade uh was three uh over 3 million as well. So this is kind of the first. Um and this is a direct parallel to kind of Morpho um and USD. The second is borrow lend integrations. So there are protocols like Pyth uh that uh that use Drift um Drift integration in their application to offer the full borrowing and lending stack. Um so here, their application was compromised via dependency on Drift as well. Uh the third is all of the emergence of these new yield products. Um so you have products like Reflect Money, Trade Neutral, Elemental that have all integrated Drift as their source for generating yield on behalf of their

users. Um so I think now we touch on nearly 10. There are another 10 uh that fall into the kind of these different buckets. But again here, by the time that all these teams understood what was happening due to the lack of kind of monitoring and alerting infrastructure, it was already too late. Wow. So let's now talk about the other kind of drama that was unfolding while this was going on, which is of course now the hackers have almost $300 million and they start moving it um you know, with the intention probably of laundering it uh and cashing out. So the community was incensed to say the least that Circle did nothing to stop the hackers.

ZackXBT tweeted and and here he noted that they were using Circle's cross-chain transfer protocol or CCTP um to uh you know, move the money. And he said quote "Six hours is how long Circle had to freeze stolen funds from the $280 million-plus Drift hack. Why does our industry allow them to stay silent?" And he even tagged the CEO Jeremy Allaire. He um tagged Circle. He tagged USDC. So why do you think Circle did nothing and generally does not do anything in these types of situations?

Yeah, I saw that tweet as well, and it's a good question. I don't think that or at least I haven't seen um Circle um fully publish what their exact position is on these things. What I do think and what I've seen based on their actions historically is that they're kind of reluctant to act when there's no unilateral legal cover uh where it's not coming from something that's mandated by the court. Um and it's upsetting, but on the other hand, I think the the counterpoint to that is it sets a precedent. And this one was it seemed more clear-cut than ones that we've seen previously. Um but there are other instances and perhaps where it's it's less clear. And then what is Circle's role? Should

Circle be monitoring for all hacks? I think some people would say that at their scale, there's legitimacy to that point, but others would say that it's not their role. Okay. Interesting. Well, so do you have an opinion on what would be a better way for Circle to to tackle these types of incidents? I think it's not it's not binary. It's not clear-cut in the sense that Look, Circle today does have the and they have historically blacklisted addresses. Um for addresses that are blacklisted, I think many of the bridges um will not allow for for transferring those those funds. But

again, those blacklists are usually derived from some like legal process. Um or some kind of very clear instruction they get from a different um law enforcement agency. So, I don't know who spoke to Circle. I don't know if anyone was able to reach them during the time of the attack. I don't know what information was available. Um and maybe in the postmortem that will become more clear. But um Yeah, I mean, if everything was clear, which it wasn't in hours leading up to the hack, at least not to us, but perhaps there was different information available to internal parties.

That that is something that could have stopped the funds from reaching Ethereum and later being mixed. But it looked like the attacker was actually pretty confident that um they wouldn't freeze because he moved into USDC and then used the CCTP protocol. So, they they may have kind of made the bet that it wouldn't be frozen without any of the requirements that we said earlier from a law enforcement agency perspective. Yeah. Yeah, and I think like the the um urge to potentially freeze with imperfect information isn't necessarily a bad one considering what I'm going to

ask you about next. Which is that many people observed that different elements of this attacked resembled the Bybit hack. And as most people should know, that was executed by North Korea. I know nothing's confirmed yet, but you know, I saw like for for instance, Diverge Sec tweeted about like multiple different parallels they saw. Um you know, when comparing this to previous hacks by Lazarus. So, like you know, when you look at it, do you also think that there are certain kind of like there's a certain fingerprint to this hack that leads you to believe it could be North Korea?

Um yes. So, I mean, there's a lot of documented attacks that have been attributed to them and we've seen some of the techniques they've used. Certainly like again, this wasn't a random dev that kind of stumbled upon these keys and decided that they would give it a go. This was very methodical. The similarities between this and Bybit for me are that it was a different kind of form factor and attack vector, but deceptive key signing. So, in Bybit, I think they even manipulated the UI on the machines that were signing and the signers were actually signing something that they thought was legitimate, although it was the transaction which transferred the funds to the rogue wallets. Here, so that's where it's

similar, but the difference here is they took it one step further. They didn't just sit on a transfer transaction. They literally controlled the protocol in that moment. So, there were a few more steps involved. Again, touching on the oracle, touching on the fake token that was created in the volumes that were running that pool. Another layer of sophistication. Yeah. Yeah, so what would need to happen for the community you know, or you know, I don't know who it is that kind of makes the judgment on these things, but what needs to happen for there to be a level of confidence in saying who the hacker was?

I think right now what most of the security teams that are in the Drift team itself and however they're working with in an attempt to recover the funds are doing are tracing the funds. They're probably seeing if it's associated with addresses that have either been blacklisted or are suspected of being tied to the North Korean regime. Um so there are many ways to kind of it's yet to be seen like how they're going to kind of get the funds off chain. Like ultimately like this is um or if they need to. So, I think these are the things that are going to happen now. I don't I don't recall DPRK claiming direct responsibility for any of these,

but there there are telltale signs. The techniques are it could be a copycat, but this is like the MO of some of the attacks they've been more successful with. Okay, so last question here is potentially a little controversial. I saw Hayden Adams of Uniswap tweeted, quote, People might accuse me of grave dancing for saying it, but we have to stop letting centralized things call themselves DeFi. Admin key can drain all funds, CeFi. Otherwise, DeFi means nothing and its brand is destroyed. No admin key can drain any version of Uniswap for any reason.

Um so, there's that view and then I'm going to ask you about one other one that was like kind of on the flip side. Hasu tweeted, Every DeFi protocol should have, number one, circuit breakers for deposit withdrawals and possibly other internal operations as well. Time locks for any change, which you mentioned. Third security security councils that can shut down protocols immediately. And then he said, we don't need insurance, we need to start doing the basics correctly. It's too early for this space to drive without any training wheels. I beg you, sacrifice a tiny bit of UX to gain a lot of peace of mind. The worst possible UX is losing your users' money.

So, yeah, what do you think of those two tweets side by side? I think they're both fair, right? And just start with Hasu. Like the the security council, the time locks, all the things that we've discussed today, these exist in a lot of applications. I was a formerly on the Arbitrum security council. Layer zero has a security council. Um Ave has the risk contributors led by us and other contributors that need to sign on sensitive transactions as well. So, these things do exist. It's not that they don't. Um and certainly it could have stopped what we saw yesterday.

Um so, it's it adds friction. I think it's a decision that the teams kind of like need to make. Um I think it's definitely like the right decision. Um and that's number one. Number two, for what Hayden was speaking of, look, this is Drift by no stretch of the imagination, even like Hyperliquid and some of the other perp decks, there are areas in the system that are more centralized than not, right? And I think every team, like when you're building, it's not that you're either DeFi or pure CeFi.

There's a spectrum that you sit on and I think teams make decisions based on the product that they're they want to go to market with and the customers and users they want to cater towards. So, I don't think there's anything like wrong with that, but if you are making those decisions, they need to be disclosed. You need to do them responsibly and you need to architect the system, do the risk audits, do the security audits such that you're doing everything in your power to prevent what we saw yesterday. Um and users can if those things are disclosed properly, they can decide do they want to be in a system that's law as code, it's 500 lines of code, um and what you see is what you get, or do you want to be in a system that has a better UX and is in the happy path more accessible

um to users. All right. Well, Omer, this has been super fun. You know, I Well, fun is maybe not the word. It's a sad day. But it's been really interesting learning how this all went down. Um thank you so much for sharing your insight on Unchained. Thank you, Laura, for having me. And thanks everyone to who joined this live stream. We will catch you tomorrow. Bye. >> [music]