Is All of DeFi Unsafe? What OpenZeppelin’s Co-Founder Got Right and Wrong

Transcript

Hi everyone. Welcome to Unchained. Your no hype resource for all things crypto. I'm your host, Laura Shin. [music] Thanks for joining this live stream. Today's topic is whether all of DeFi is unsafe. [music] Here to discuss are Isaac Patka, certifications lead at Security Alliance, and Mike Silagadze, CEO of EtherFi. Welcome Isaac and Mike. >> Yes, thanks for having me. >> So, if you're on crypto Twitter a lot, you probably know that this week Manuel Aráoz, I don't know if I'm saying that correctly, um a co-founder of OpenZeppelin, who I need to note left the company in 2019, he set off a little firestorm in CT this week with a tweet saying, quote, "I now

consider all of DeFi unsafe. Coding agents are superhuman at finding vulnerabilities, and smart contract security is too asymmetric. Defenders need to fix every bug while attackers need just one exploit to steal funds." He even said that he had urged friends friends and family to leave positions in blue chip DeFi protocols like Aave, MakerDAO, and Compound. And >> [laughter] >> in response, OpenZeppelin tweeted, quote, "Recent posts do not reflect OpenZeppelin's position. Manuel left the company in 2019."

Manuel himself also clarified that he meant not only code, but also, quote, "parameter configuration, mechanism design, and opsec." So, um I was curious, Mike and Isaac, if you agree or disagree with him that all of DeFi is safe unsafe, sorry, and you know, whatever your position is, why or why not, and why don't we start with Mike? >> Um Look, I think in some ways you could say the same thing about TradFi right?

Like you could say that any attacker like if if an attacker comes and gets access to your account, your bank account, and sends a wire transfer from that account, um, you know, we like to think that the the banking system is the super centralized protected bubble, but the reality is if they do that, if they manage to get a wire transfer out, like that money's gone. You're not You're not getting it back. Obviously, you know, common uh, pattern. Um, and so you could say >> to So, maybe I'm This is just something I don't know about wire transfers, but um, you know, because we're used to like chargebacks being you know, being held by banks. Like they

won't they won't >> depends on the method. Something like ACH, yeah, there's chargebacks. Something like a SWIFT transfer, for the most part, no, that that money is gone. Um, so TradFi has a lot of these same characteristics, and you could say, "Look, an attacker just needs to get access to your password or 2FA or, you know, social engineer their way into your account once." And to some extent, that's true, right? There's billions and billions of dollars. I mean, there's a lot more money stolen in TradFi than in in DeFi, obviously, proportionally. You know, it's different different scale, but there's billions and billions of dollars that that are stolen pretty regularly. Um, but there's mechanisms to to deal with

that. There's insurance, there's there are ways of tracing money, you know, back and then chasing it. Um, so the question isn't is DeFi perfectly safe? Is it is it possible for it to be absolutely safe? Because the answer is, of course, no, it's not perfectly safe. The question is, you know, how where does it compare in terms of the level of safety that you get to TradFi? And and the answer is, look, there's some level of risk that you have of your money getting seized, your your getting frozen, or bank just blocking your your accounts.

And so how do you weigh that risk versus the risk of you know smart contract hacks. I think there was an analysis that was done pretty recently, which is that today if you were to get paid for you know all the risk that you're you're taking in DeFi, based on the the number of vulnerabilities or the hacks that that occur, the interest rate should be around 12%. So you you should be getting around 12% yield on your assets. So um which which sounds reasonable. Like on a you know gut check that that feels about right. So what we need is to do a combination of one improve yields in in DeFi by bringing in more real world economic activity rather than just gambling. And then reduce the risk. And

there's lots of things that I think people can do to reduce the risk. I mean I think if you have a well protected self custody um you know crypto wallet or multi-sig, I mean I think that can be safer than than holding your assets in in TradFi. So I don't think a blanket statement that you know everything in DeFi is is high risk is correct. I think that's fundamentally wrong and it it puts a very naive sort of amount of faith into in TradFi.

>> Yeah, and for listeners who are interested, we did do a show with Tom Dunleavy who is the one who did that analysis saying that he felt that like the proper amount of interest that you should be paid for the risk if you're lending would be 12%. But Adrian of Steakhouse Financial took the other side and and a number of commentators said like basically the market is setting the rate. So anyway, so if you're curious to listen to that, you should check that show out. Isaac, what about you? Do you agree that all of DeFi is unsafe? Why or why not?

>> I certainly don't agree that all that all DeFi is unsafe. Um, think that uh it's embarrassing the level of like operational security failures that keep happening that um are leading to a lot of these hacks. Um, for me like it's given all of like the, you know, superpowered AI coding agents, they haven't actually found a ton of, you know, uh long-tail math issues or rounding errors, bugs. Like those happen once in a while, but like 90% or more of the time the failures are like pretty embarrassing, easy to avoid things that I think now that there's just more and more attention um on these like longer-tail protocols with smaller TVL um or like the the uh weak points of the big blue chip uh D5 protocols,

whether that's the people that are in charge of setting parameters or people that are in charge of risk adjustment and stuff like that. Like the failures that are happening are because of like really dumb mistakes. Um, and we're I think as an industry getting enough attention on that that people are hopefully going back and checking all of those things. I know that um a lot a lot of D5 protocols are now thinking like, okay, we actually need to go back through and make sure we have, you know, proper multi-sigs and time locks and parameters and and cross-checking. Like um these are just weak points that were going to get shaken out at some point. Um, and we're fixing them, right? But we we haven't seen some crazy wave of like, oh my god, we realized that like the the math underlying Uniswap was wrong cuz

the superpowered AI figured out a way to break uh the invariant there. Like that's not really happening. It's really just like amplifying the number the the amount that the attackers are able to pursue um the like really easy to contain stuff that should have been contained all along. >> Yeah. Yeah, so we'll we'll talk a little bit more about that because that is um I think the really disheartening takeaway. Um, but first we're going to take a quick word from the sponsors who make the show possible. Is my crypto working as hard as I am? Honestly, that's the question that got me into staking in in first place. I work hard for my money.

It should be working hard for me, too. Now, you can boost your earnings this Coinbase One member month. Until May 31st, any newly staked assets will get a 40% boost for 60 days. That's extra passive income. Coinbase One is the ultimate membership to make the most of your money. As you know, this is how I make the most of my money. Zero crypto trading fees, 3.5% APY on USDC, boosted staking and lending rewards, and up to 4% Bitcoin back with the Coinbase One card. Plus, this massive 40% staking boost. This is your last chance to take advantage of the 3% deposit boost, your share of five Bitcoin if you out predict pro basketball coach Lethal Shooter, plus a chance at a private shooting

session, a $50 Bitcoin bonus when you spend $100 on a new Coinbase One card in the first 30 days, and the 20% discount on the first year of annual plans all end in just a few days. Score your boost before May 31st at coinbase.com/unchained. Head over to coinbase.com/unchained. Last chance to join at coinbase.com/unchained before member month ends. No purchase necessary. See rules and other ways to enter. Terms apply to other offers.

Futures swaps via Coinbase Financial Markets. Risk of 100% loss. Payouts event-based. Not investment advice. Not available in Nevada. Coinbase One card is offered through Coinbase Inc. and Cardless Inc. Cards issued by First Electronic Bank. Bitcoin back rates are based on card holders assets on Coinbase. Back to my conversation with Isaac and Mike. So, as we mentioned, cuz you guys also disagreed with Manuel. Um a lot of people disagreed with him. But, one of the most common refrains that I saw was that smart contract risk is actually pretty low compared to the other kinds of hacks that we've been seeing.

So, for instance, Mark Zeller, who, you know, is always very colorful when he talks [laughter] he wrote, "What a moronic thing to say? Less than 10% of past year DeFi issues are due to code base. It's mostly bad parameter configuration, collateral blow-up, and poor opsec." Fiddy Research tweeted, "If AI tools are so good, all of DeFi would have been hacked already, which means a lot of things that didn't get hacked are actually quite secure." And Alex McFarland of Keyring posted, "You're actually combining credit risk with hack risk, two different risks. For example, Ave did get hacked recently, a collateral bridge did."

So, when you guys think about kind of like the landscape of risks in DeFi right now, what are all the ones that like what are all the categories that you think about, and which ones do you feel are a little bit more important or prominent right now? And either one of you can start. >> Uh I'd be happy to just start just based on like, you know, when when we when we go in and one of the things that we do like working with protocols is is help them build out what's called like a threat model of like, you know, what are all the things that could go wrong and what and how would they go wrong. And so, for for those, um a lot of the time I just like at this point assume if they're, you know, using pretty standard, you know, code libraries and

math and like once in a while, yeah, there's like a rounding error like in a in a math library that causes some issue, but most of the time I'm pointing out things like, hey, your victim your your users could become uh victims of something going wrong on your like TypeScript SDKs that could like redirect user funds. Like, that's like where the a weakness might be. Or on the on-chain side, I think less about like the actual core um smart contract code and more about like, you know, contagion. If we if we think about what happened with like Ave and Kelp and and the bridges there and stuff, I think that that type of risk is probably the most uncontained and and and misunderstood in the space right now.

Um thinking about like how properly contained uh uh various protocols are from like one type of collateral asset um having some sort of issue or bridge error that leads to a contagion that infects the rest of the ecosystem. That's what I'm most concerned about and then so for protocols encouraging them to introduce proper circuit breakers and rate limits and anomaly monitoring and and pausing all of this type of stuff. Um looking for that type of risk. Uh it I'm much more concerned about that type of stuff and then you know social and like uh social engineering or just like it's really hard to understand what types of transactions you're doing when you're updating you know the risk parameters of your protocol. Like I

talked to teams that are managing like 50 or 100 multi-sigs for like a massive D5 protocol and they have this like you know patched together way of making sure that they're not going to make any mistakes but that's another thing that I worry about is like you know uh um adding too many zeros onto a parameter when you're doing something on chain. Um like if when we I like to you know if we think about like what happened with PayPal and their stablecoin accidentally minting 300 trillion dollars. Like that's the type of human error mistake that I think is more likely than a code error at this point. >> Yeah I mean I'd certainly agree with the with all of that. The the operational stuff um I mean empirically if you just look at all the biggest hacks right the buybit hack uh that was 100% uh you know operational

um even our receipt right that was a that was a function of how the uh the layer zero bridge was was configured um drift obviously every hack basically so far that the those of significance was um I call it an opsec failure. So that's something that we we care about uh quite a bit at etherfi and have spent spent a lot of time um um uh hardening. Um the other thing I would say and this is um uh, this may be a controversial thing to to say which you may be lower you you'll like but um uh, I think that there [clears throat] is a different level of decentralization

that is appropriate for a blockchain versus an application. Um, and I think a lot of applications in in DeFi engage in uh, what I would describe as decentralization theater meaning um, the team, community, whatever, the the members of the multi-sig always retain the ability to upgrade the contracts. Uh, that that's true of pretty much every protocol with the exception of of Uniswap and maybe Morpheus to to some degree. Um, and so um, that that option is always there.

Um, the option to to pause contracts in one way or another is generally there. Um, but teams put uh, barriers in the way such that their ability to use these uh, these tools to protect users are hampered and so you get something where there's really not this extreme degree of decentralization that you would expect or that you have let's say in Ethereum or Bitcoin where objectively it's not physically possible to force upgrade the the network. Um, um, but at the same time we you don't get that benefit but at the same time you also don't get the ability to protect users in case something goes wrong. And so one of the decisions that we we have made at at EtherFi is to stop playing this game, to stop

playing the sort of decentralization theater and introduce things like like blacklists, introduce things like the ability to pause contracts in an emergency situation and that in turn it doesn't give any attacker the ability to cause harm but it does give the ability to uh the the team and the you know the systems that are monitoring the the protocol to prevent harm from from taking place. Um Um and so that's something I think that I think protocols in DeFi ought to uh ought to embrace more broadly and I actually think that that is probably the

only way that ultimately DeFi becomes as uh safe as as TradFi because it's frankly not that hard to detect when you know billion dollars of your tokens have been minted or moved. Like it's not that hard to have monitoring in place, you know, for transactions that enter the the mempool that clearly violate some you know some crazy invariant um and have the ability to immediately lock things down and prevent an attacker from uh you know draining a liquidity pool or doing something else that's that's dangerous and I think that is the responsibility of every protocol to to do that to safeguard their their users' assets. You can't just throw up your hands and say oh decentralization.

What's like well you have the ability to upgrade the contract so you can retain all the non-custodialness and benefits of uh you know of decentralization as in so far as it's appropriate for a DeFi protocol while ensuring that you're there to protect your users. So and that's something that EtherFi is is going to be uh is going to continue to focus on. >> And before we move on to specific risks, I did want to ask for Isaac's response to that. Do you agree that like you know an app having those capabilities is only protective and not a risk in itself?

>> So I think that there's a right way of setting it up and I actually don't think that it's necessarily against the principles of decentralization to have certain privileged keys that can do things to protect users. There's ways of setting it up properly. One thing is like you shouldn't just have one multi-sig with no time locks that can instantly upgrade your contracts and change the behavior. That's not just a decentralization issue, that's a user safety issue. So, I think that like typically a protocol should have unless it's they go the the route of having completely immutable unchangeable contracts, they should have at least three different multi-sigs which are delegated to three parties and it should be clear what their delegations are. One is a very fast emergency pre freeze multi-sig that can with a relatively low

threshold act quickly. Um it can also be one that has protections in place from like a higher level multi-sig to prevent griefing like taking that privilege away from it. But, you should at least have one very low threshold emergency pause multi-sig that that you can distribute the rights to various people that are going to be guardians of your protocol. A second >> I'm sorry, is that you said three signers? So, is that like three of five or just three of three or like what >> No, I mean three different multi-sigs all together. And so, that one could have like that one could have like it could be a one of three. It could be a two of three. It could be whatever. It could be in other protocols there's certain there's certain architectures where you give like one-time pause rights to a bunch of addresses and then if they use it they

can't use it again. Just to prevent So, you need to have an emergency pause multi-sig. You need to have a second multi-sig you have is typically a DeFi protocol has some, you know, relatively quicker updates that need to happen for parameter adjustments, risk ratings, and stuff. That should all that should go through at least a brief time lock though. There should never be a case where you need to make an immediate parameter update that that takes place and can immediately be used in the same block. If we think about like adding a new type of asset to a a new type of collateral asset to a lending market, you should never there's never a case where you should be able to add a new type of collateral asset and deposit that asset and borrow against that asset in the same block. It's not ever needed. So, that should always at

least be behind like a one or two hour delay if not like a multi-day delay. And then a third type of multi-sig is in charge of actually upgrading your contracts. And that should be behind something that's like a two week delay. That gives your users time to leave your protocol if they don't like the direction that it's happening. You should never need to upgrade your protocol immediately. If something really bad happened, you pause and then you upgrade. Like if teams are trying to upgrade quickly like to because they don't want you to know that there's an issue, um that's a problem. But like uh to stop the bleeding, you have a fast freeze. To update parameters, you have a short time lock. To upgrade your contracts, you have a long time lock.

And those should all be spelled out in a way where it's like, "Hey users, like you have rights to leave this ecosystem." Um like I think Lido just introduced dual governance last year which basically makes it so that um like, you know, wrapped staked ETH holders can or like staked ETH holders have certain governance rights to like that doesn't make them less decentralized. It's like if we're about to do a big upgrade, we're going to give you a two week uh heads up and you can leave before that if if you want to get out of there. So that's like not anti-decentralization. That's just like responsible design.

>> Yeah. >> Yeah, I would 100% agree with the with everything that Isaac is is saying. Um um And like and I guess I'll I'll maybe re-emphasize the point that a lot of protocols choose not to do these things in the name of decentralization. Uh and my point of view is that this is like performative, basically. It doesn't actually uh improve the decentralization of their protocol because ultimately they do retain the ability to upgrade uh the uh the contracts um whether or not they have good protections in place against that. Uh but it does make their users unsafe. I think not having a hard big red button pause function is irresponsible, basically. You you every serious protocol needs to have that uh

uh that ability with the appropriate protections that, you know, that Isaac uh mentioned. >> One thing that I uh go ahead. I said the one thing that I'm that I concerned about that sometimes comes up in talking to protocols is like the role of what of the security council. It's become kind of like a very like poorly defined term. Like in some ecosystems the security council is in charge is like these people that are, you know, docs and voted on and like and and like accepted by the community to be able to take certain actions like, you know, reviewing a contract upgrade. What I'm a protocols that are trying to put like subjective like subjective decision-making onto these security councils around things like blacklisting and freezing. I think

that is I know that you you've probably talked about this after the whole like Arbitrum thing already but like I see some protocols saying like, oh well, we don't want to be in charge of making the decision on freezing funds. We'll put that on the security council and it's like that's not a security council that I want you to add me to. It's like a security council should have very specific rules around like you're just making sure that we're not introducing bugs or doing things wrong. Not like so I think that there's still like questionable like does the protocol want to take on the responsibility of that blacklisting role? I think that's like a bit more a bit harder to nail down like for for protocols on who who retains those rights and do they want those or do they want to give those to somebody else?

I know you've already talked about, you know, Circle and Arbitrum and all this stuff but like that's that's like looming to me in the back of my mind of like other things that are like more complicated conversation. >> Yeah. Yeah, the Circle thing definitely was something a lot of people were up in arms about including me. Let's talk about the AI issue because Manuel actually specifically called that one out. And you know, we saw that April was horrendous for hacks and May you know, continues to see a lot of hacks thankfully not as you know, big dollar amounts.

But I wondered like generally do you think the AI threat is just getting started or do you feel like the industry has already kind of started wising up and begun kind of you know patching things or shoring up defenses. Like what what are you seeing like do you cuz basically you know we're sort of in this arms race where AI is just going to get better and better. So do you feel like teams know right now like they need to use AI to to prevent that or do you feel like some people are still asleep at the wheel?

>> Yeah I mean 100% I mean certainly every team is using it and I mean every serious team I know is aggressively running their code through you know Claude and Codex to find all the issues that are identifiable. So I mean that's the the aspect of the this um concern I guess that maybe not appreciated that like but what works both ways like yes the attacker can run stuff through an AI model to identify vulnerabilities but the the defenders you know are there first right there there there before they ship the code and they can run it through the the same in fact better AI models like I don't

think you know the DPRK is getting access to Mythos anytime soon. Yeah maybe they have access to Claude or Chad GPT but I actually um my guess is actually their opsec is probably quite poor because they don't have the ability to access you know CrowdStrike or Octa or you know other sort of industry practice tools that allow you to to lock things down to some degree from an opsec standpoint. So so I actually think the defenders are at a significant advantage which is why you're generally the path that they choose is these sort of social engineering

uh tricks where they send you a fake Zoom invite or whatever in order to get to access to people's machines and they're generally going after quite low-hanging fruit. >> Yeah, I'd agree that they're targeting the long tail of of like smaller TVL protocols or maybe like devs that have like a figuring out a dev who has like a a key to do an upgrade but like the the types of hacks that are happening there, you know, not withstanding like the really big ones that we saw in April like I I think those are happening a lot to a lot of like smaller smaller protocols.

But I think that like a lot of the large protocols are rising up to it. I know that a lot of protocols are you know trying to bring more security work rather than just like the old days of just relying on your auditing firm. Like they're realizing, okay, we are even though we're a DeFi protocol, we need a CISO and we need somebody that's like making sure that like we have very robust practices for using all of these AI tools for our defense. I think that like all the security researchers I I talk to you are so heavily using all of these various AI tools both to help them like just serve more protocols but help find different types of bugs.

I'm more encouraged by that I think than I am scared of the attackers having access to those tools. I think that the security researcher community is using them just as well and yeah, it's an arms race but I I'm confident in the side as well. >> Okay, well that's that's really good because yeah, just in April it sort of felt like oh no, like the AI thing is just getting started. Is this just going to get worse and worse? Um but okay, so because Mike brought this up or not just because but you know, it's good segue. We should definitely talk about the human element because the social engineering threat does feel like that's really maybe in some way

somewhat scarier threat just because humans are much more fallible than machines, you know, or really it's more like there's such a range of humans that you know, any one person could be less paranoid basically and that could cause a problem, you know, the drift hack really I think sent shockwaves throughout the system because you know, they did that over such a long period of time and it was done in person and you know, it in a way it like harkens back to the SIM swap attacks, which by the way still still happens. So I don't know why you use the phrase harkens back because that's still going on, but you know, the the weak link there was the

human customer service representatives at the mobile carriers. So basically it's kind of like the same model here and so I was wondering are you seeing that teams are getting smarter about you know, training all the employees to kind of recognize that sort of thing or you know, adopting behaviors to prevent against that just yeah, what what do you think kind of is if there any changes that are happening in the industry to prevent against that like do you do you feel like the industry is also getting stronger against that type of threat?

>> Yeah, I don't like just the the social engineering like training sessions which are just like oh we like like sent you a fishing email got you like don't click on things in the future cuz social engineering is just too good. It's going to get you eventually and so the right defense like yes, we should educate people on defending against social engineering against like the obvious cases, but the right defenses are not just like make everybody like make everybody so paranoid all the time that they can't do their jobs. The right defenses are putting in the guardrails on the protocol and code side and the machine side assuming that the human factor is fallible. So that uh you put in rate limits or you put in little delays, you make it so that the system can't get completely messed up in an instant because you'll assume that

people can that people are are fallible. And so if you're like in charge of a big treasury for for a protocol, assume that like you are all targeted targets for social engineering and therefore you should not be able to send your entire life like I don't know like hundreds of millions of dollars in a single transaction because it is possible. And so it's a matter like segmenting things and and putting in like policies and controls in place on the machine side assuming that the humans are going to be compromised because the social engineering is just too good. Like I think that maybe in a matter of like I mean it's probably happening right now that like it it's just at this point the AI tools for social engineering are

making it so that like we're we're all like uh going to make mistakes. Yes, we just need to define make the systems tolerant to those mistakes. >> Yeah, 100% agree. I mean Like it happens all the time. I mean and usually from what we've observed the at least some of these attackers and they target the lowest level employees. Like what they they know that I mean generally they know that they if they you know send me an email or send one of the other executive team members you know a sketchy email or some other attempt at compromise.

You know we get this stuff so often that like at this point it's it's that's probably a very hard path to to take. But if they go after a support agent or after you know some more more junior less experienced they're much more likely to to have success. And so every company needs to have processes and controls in place to ensure that in case that there is uh you know a compromise that there's no way to sort of escalate privileges and you know take down the the system. And I think like this is what we talk about this as though this is like some crazy new thing that you know we're we're figuring out. I mean this is standard practice in in a lot of

any well-run industry, this is standard practice. I mean maybe you can't steal a billion dollars in one shot, but you know large companies are very much a target as far as you know a data compromise, a data breach allows you know blackmail on all kinds of ways of you know monetizing it. So so this isn't new. I mean this is really again going back to the point that I think Isaac was was making that most of the attacks that we're seeing are actually quite um embarrassing and putting in normal healthy protections against social engineering and basic offset practices

will make attackers' lives much much harder. And again going back to I guess what I was saying, stopping with a lot of the decentralization theater and putting in mechanisms in place that if an attack does take place, you can immediately lock it down. Um To make it more concrete, I think what Arbitrum did where they locked down and then saved I what I think it was $75 pulled that those assets from the attackers and were able to you know give it back to the the victims. I think there needs to be a robust mechanism to just do that when it's necessary.

It's not um that's not that shouldn't be that controversial. I'm not saying that there should be one button that says you know take you know take this wallet's money, but there should be a robust process with sufficiently decentralized sufficiently decentralized mechanism to be able to make these types of decisions. I think um this principle that you code is law and like you wrote the code wrong so [ __ ] you is just stupid. Like that's just not how human organizations operate. There needs to be a an error correction mechanism.

Um And that [snorts] that is not necessarily incompatible with decentralization. And and again the standard should be different for an application versus a a blockchain. Um And we're we're really taking that to heart that either find it that I think that will make or that has already in many ways made us the safest way to to stake and deploy assets and in D5. >> Yeah, code is not code is not law. Law is ambiguous by design. Ambiguity is built into legal code for cases that are subjective. Code yeah, it's just code is not law.

>> [laughter] >> Yeah, yeah, I agree. Um and the other thing is like uh I you know, I said this before about the Arbitrum security council decision. There's kind of like almost like a moral sense or so or some kind of intuitive sense that humans have about right and wrong. And I think if you follow that like you're never going to have a problem. And I think that's where Circle really went wrong is like the lawyers who maybe are like too in their heads and like don't just think in the simple like what's right and wrong way. Like I think that's kind of how yeah, they get so much criticism because they're clearly doing things that like most people just don't agree with, but they're doing it almost like out of fear

about you know, the legal system. But anyway, let's let's move to >> One briefly, I don't think Circle it did is doing things necessarily wrong. I think that like their legal position of we respond to court orders is a is a legitimate position. And the answer is not like evade court orders and do whatever you want, the answer is make court orders easier to to actually file because there's there's courts that run 24 hours a day, 7 days a week. If their policy is we respond to court orders, we need to coordinate better with law enforcement to get court orders down to like a 10-minute process.

>> Okay, well that's just ignoring the reality of the system. >> Yeah, and but I think it doesn't have to be one or the other. I think again, but I don't think there have been too many examples of Tether arbitrarily freezing people's assets and you know, blocking people. So, I think Tether is much closer to the the right approach to to this where they have the ability to act quickly and if they do something incorrectly, if they make a mistake, which of course is is going to happen, they can reverse that and it's not that that big a deal.

You know, one in a hundred times locking up assets incorrectly temporarily is a very reasonable price to pay for being able to actually recover funds when whether it's North Koreans or otherwise get get access to them. And again, that can be done I mean, in the case of Circle and Tether, obviously these are highly centralized, but I think you know, in a in a decentralized stablecoin model or liquid staking token or whatever, there's a way to do this that is still very much compatible with self-custody and decentralization.

>> Yeah, I mean, the Circle thing is like they let $280 million just get you know, laundered through their platform and it happened over the course of several hours. They could have easily frozen it. And yeah, just the court system at this moment in time and probably not for a long time is ever going to respond in blockchain time, so Anyway, okay, let's talk about bridges because obviously, you know, we're seeing a lot in that regard. Like even after the Kelp Layer Zero attack, now we're seeing just a lot of you know, chains or or projects are moving over to chain link. Um something else that was kind of interesting was Ali Yahya of A16Z was on the show talking about how privacy chains are

going to be a moat because he said that once a user or an institution puts their funds in a privacy chain for them to move to another chain kind of necessitates that there's some risk of data leakage. And so basically like once you kind of get that user they probably are not really going to leave or or at least if they do it'll be something that they think about way more than they would now. So I was wondering like you know how you think about the risk from bridges and um what questions it is that either teams themselves should ask when they're integrating a bridge or questions that users should ask if they're you know

like trying to transact on a project that that uses a bridge. >> Yeah, for me I think that if you're on if you were like running a D5 protocol on using bridged assets you absolutely need to consider the risk of bridge compromise when you're thinking about the risk ratings and the and like the borrow limits and stuff. I saw a blog post after after one of the recent attacks where like the agency that was in charge of doing the risk rating for this bridged asset said, "Well, our statement of work didn't say that we were supposed to consider bridge risk when we were thinking about how like what the borrow cap should be for this asset." Like that's idiotic like like obviously the risk of of an asset going wrong is not just like a de-peg, it's also like what if there's an infinite mint due to a

bridge issue. If they had spent like 5 minutes looking at the bridge and they saw that it was like a one of one system that should have like that asset should not have been allowed to be borrowed against. So I think that like if you have bridges and you have to look at the potential of the bridge being compromised as much as possible of course prioritize like you know native assets over over bridged assets. But yeah, it's just bridges have always been a huge like weak link here. Like the amount of times there's been like an incredibly embarrassing bridge attack where it's like, "Oh, yeah, we forgot that we did an upgrade where we could just go and ask the bridge to give us however much money we want and it gave us however much money we want or mint however much money we want or upgrade

the bridge so that we could mint whatever we want." Like, you'd think that people doing bridges at this point would be a bit more paranoid, but it's just yeah, it's terrible. >> Yeah, I mean, I think um the best practices when designing a DeFi protocol and this certainly the way we operate at any surprise to assume that any component, any uh service that you depend on is possible. It's possible that it would be compromised and and fail.

And to just design for that. So, in the case of bridges there's a couple of very obvious things that one should do. One, rate limits. You have to have rate limits on everything. Transfers from one you know, one chain to another, transfers from you know, L1 to to L2. Just have rate limits on on everything. You know, we've every once in a while users complain that they can't transfer you know, a large number of assets you know, from one place to another with with either fine. We sort of say, "Look, I I know it sucks, but it also protects you and makes sure that like the losses are going to be very limited in case not even a bridge gets compromised, in case an L2 gets compromised. In case

like we built our stuff with the assumption that an L2 could be fully compromised. Like someone completely takes over the nodes and can start just producing arbitrary blocks and changing state. And in that scenario, we want to make sure that there's not going to be contagion across layer one or you know, our other other systems. Um Having active monitoring in place, I think is uh is is critical. So, that again, if some invariant is violated, you have the ability to go in and you know, put a stop to it pretty quickly. So, I think that that level of paranoia is um essential and is um again, standard practice in other industries. Like when people in

let's say aviation, we don't even need to go into the finance space. So, when people design an airplane, um every system has two or three layers of redundancy. You you assume that a system is going to break at some point and you want to make sure that the plane doesn't crash into the ground. And the equivalent of that in in DeFi is uh make sure that the assets are are not lost. And so, you have to have layers of redundancy and multiple protections in case one layer gets compromised because at some point it will be. Um So, this is this just needs to become standard practice. Um there needs to be um almost an expectation of a certification process that people can actually trust that goes beyond just audits. Um that goes into

the the opsec and uh um um the parameters and everything that's involved in ensuring users don't uh don't lose their assets. >> Yeah, I heard a fun anecdote about when elevators were developed and one of the people that invented elevators, everyone was too scared to use it. And so, he went up and he would take people in the elevator and cut the cable and show how the emergency braking arresting system worked. And like that level of like redundancy is useful and it helps people feel safer. And I appreciate the lead into talk about potentially certifications.

>> Um yeah, we'll we'll do that in a moment. Um so, I did want to circle back to something we briefly touched on earlier, which was about credit risk. Um so, we talked about, you know, Kelp DAO layer zero and um, as has been said you know, numerous times already, the fallout from that really happened mostly on Aave. Um, we had Paul Frambo of Morpho on the show talking about how Morpho's designed to have this isolated market structure, which is kind of like walling off individual assets and risk parameters so that the silos are more self-contained. And I wondered if you thought that would be the future of lending protocols or just generally, you know, how you think about limiting contagion when it comes to these types

of situations? >> I mean, obviously pre- like able to be parameterized in that way, right? Like you could have isolated markets. I I mean, yes, Morpho's great, but I also think that like just because Aave um, has the ability to like have un- non-isolated markets, it's not necessarily a bad thing. Um, it's like it's useful to be able to do that and like it is fully you can per- like set the parameters for what you want to be isolated, not isolated. I think these parameters might have not been set correctly in this case. Um, just easy to say in hindsight. Um, but yeah, it's not I think one way or the other it's it's it's you don't have to pick one. Like you can do that type of asset isolation on an Aave lending market.

>> Paul, or uh, sorry, Mike. >> Um, yeah, I mean, I I agree with that. I think um, you know, as so Eezer actually has our own um, we call it a debt manager. It's not it's not a proper lending market for but but that's used for our our cash uh, you know, card product um, and um, we're looking at migrating to a proper lending market that's, you know, preview of some things to to come. Um, and a system like Morpho is is uh, it's challenging. I mean, it's possible to build it on that, but it's it's it's challenging. So, uh, again to reiterate what what Isaac said, like there's benefits to um, to a system like Aave and uh, it

just needs to be set up correctly. Um Um I mean there's there's a a lot of different parameters that uh can be said that I think can be um Um more forgiving. Uh I mean I think a lot of stuff that happens in DeFi where we see people taking you know 10, 20, 30 x leverage um are um appropriate for gambling, not appropriate for um you know a robust uh uh financial uh products. >> Okay. So, um just in the interest of time, why don't we have you now just talk about kind of you know EtherFi's architecture because you know I I'm sure that you're very focused on um you know trying to to keep your users safe and

you know I do see you guys are the largest restaker in DeFi. So, like clearly um you know you don't you don't get to that size without thinking about these things. So, yeah, just talk about you know the types of defenses that you have um instituted. >> Yeah, well, uh maybe I'll focus on the stuff that we've done um um uh to harden things. Um Actually no, well well I'll talk about more more generally. Well, so there's certain things that the reason that we were not vulnerable you know at any point to this kind of kelp attack is because we we we did as EtherFi make uh a lot of decisions that to us seem kind of self-evident. Um Um uh

that I guess made us a much much harder uh uh target to to go after. And those decisions include things like rate limits across you know any bridging um um any oracles, there's rate limits in terms of how much the oracle uh price can can can change at any given uh time. Um off-chain monitoring to ensure that if some invariant is violated that that there's the ability to uh to lock things down uh pretty pretty quickly. Uh you know obviously the layer zero bridge was configured with a I think in most cases it was a three of three uh rather than a one of one. Um uh for you know, for messages and again even if that was compromised somehow, the rate limits would uh would

kick in uh pretty quickly. Um and the damage would be contained to worst a few million dollars. So, there's just a lot of those basic types of uh these decisions that we uh that we made that a lot of other protocols I think you know, to choose another staking protocol as an example. I think Lido does a phenomenal job on the on the opsec and and security uh front. Um uh the the thing that we're doing now that I think is going a step uh uh above and beyond and I I I would argue makes us the safest way to to stake and and hold your assets in in DeFi is to stop with the decentralization theater [ __ ] and put in mechanisms that uh allow us to um when appropriate to lock

things down, pause things, um uh uh to to cancel uh cancel vote uh to be able to pull attacker funds if if they end up in the you know, in the wrong hands. Um put in the mechanisms that actually allow us to ensure user assets are safe while still giving uh people the power of self-custody and DeFi uh composability. You know, concretely the ability to pause the system for 24 hours and then have that sort of ratified with a you know, a broader community uh uh security council uh vote. So, having the ability to again lock things down and then uh make a decision kind of like Arbitrum uh made to uh to pull funds from you

know, a North Korean uh actor uh for example. Um this this all goes um on top of the fact speaking specifically about uh staked assets that uh one of the benefits is that those assets are not actually sitting in our contracts. You know, they are staked on the you know, in the Ethereum Beacon Chain deposit contracts which limits the you know, the potential risk to just the amount that's sort of in the liquidity buffer pool. So, um Uh I I think that doing those things allows Lido to I think very credibly be in in fact safer than keeping your assets in for example, a centralized exchange which could be encumbered in a bankruptcy or

uh you know, or worse. Um Um where it's such that with Lido, if you keep your assets either self-custodied or put in a uh custodian, uh you have all the benefits of transparency and and self-custody while getting the benefits of um uh best-in-class uh protection in case uh uh in case there is something crazy that happens in the uh uh you know, in the in DeFi. >> Okay. So, in the interest of time cuz we're running a little bit over, why don't we end on like tips that you would give to users um that are on chain or you know, what information they should look up um to just give them some peace of mind?

>> Yeah, it's really hard for like if you're retail users to go to the go to a website or just look at it like a contract on Etherscan and figure out like is this uh contract operationally safe? Um there are some good tools. I've seen like some nice like like L2BEAT has some tools around like visualizing control structures. There's a cool block explorer that I saw called Herd that helps you kind of like visualize control structures. But, that's not like I think that like an expectation that we can put on um on on on users to be like, "Okay, before I put my money into this thing whatever like 3, 4, 5% I'm going to do like an opsec audit of everything that I can see on chain." That's just not possible. Um something that we're trying to surface with the certifications initiative at the Security Alliance is

just make it so that those types of things are more visible um so that like you can have at least some assurance that some firm went in and checked to see how the team's multi-sig is managed, check to see how they manage all of their like parameters and risk and DNS and devops and SDKs and stuff like that. Um trying to make that at surface that as publicly as people expect for um like security audits uh for smart contracts. Um so yeah, working with like uh there's like five or six auditing firms now kind of working towards that standard. They'll be able to issue seal certification. So hopefully as a user, you'll be able to go to a protocol and see okay, somebody has at least looked at this and they're um meeting a minimum or a pretty high level of like operational maturity. Um I think that's

a better direction for users than expecting users to like go in and check what the multi-sig threshold is um for every like DeFi protocol they use. >> Like Uh yeah, those those are all uh great tips. I mean I would say low-hanging fruit uh something that maybe is very actionable for an average user is uh don't use hot wallets. Use hardware wallets for anything that you're not willing to lose. Um that will solve uh you know, I don't know, 75% of your problems is just make sure any assets that you don't want to lose, you use a hardware wallet uh or a a large trusted uh custodian if you if you want to go down that path. I prefer hardware wallets, but

uh you know, uh I think a trusted custodian is a is a viable option. Uh and then frankly just don't interact with protocols that are uh new unless you are uh power user doesn't even I think uh uh describe it appropriately. Unless you are an extreme power user, you should only be interacting with blue chip uh DeFi protocols um of which there's probably like 10 or 15 in DeFi. Um so uh just don't don't touch anything that uh uh that is relatively new. Um again, unless you're you know, unless you have expertise or you're willing to lose those those funds.

>> All right, you guys. Well, this was such a great conversation. Thank you so much for coming on Unchained. >> Thank you. >> Thank you. >> All right, and thanks to all of you for watching. We will catch you next week. >> [music] >> Bye for now. Nothing you hear 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. >> [music]