Unchained - Is 'All of DeFi Unsafe'? What You Need to Know About Holding Assets Onchain

Episode Date: May 29, 2026

A co-founder of OpenZeppelin said he’s urging friends to exit blue chip DeFi. Isaac Patka and Mike Silagadze explain what he got right, what he got wrong, and what needs to change. ======================================================== Thank you to our sponsor! ⁠⁠⁠⁠⁠Coinbase One⁠⁠⁠⁠⁠: Get 20% off the first year of your Coinbase One annual plan at ⁠⁠⁠⁠⁠coinbase.com/unchained⁠⁠⁠⁠⁠. ======================================================== A co-founder of OpenZeppelin set off a firestorm on Crypto Twitter this week by declaring that he now considers all of DeFi unsafe, citing superhuman AI coding agents and the asymmetry between attackers and defenders.  Isaac Patka, certifications lead at Security Alliance, and Mike Silagadze, CEO of Ether.Fi, join Laura Shin to push back on that framing — and to make the case that the real problem isn’t AI finding sophisticated zero-days, it’s that 90% of hacks are still embarrassing opsec failures.  They cover the full threat taxonomy: opsec and parameter mistakes, contagion from bridge failures, AI-enabled social engineering, and the decentralization theater that leaves protocols unable to protect their own users.  Mike makes a pointed argument for why every serious DeFi protocol needs a hard pause button and a blacklist mechanism, while Isaac explains the three-multisig architecture that should be the minimum standard. Plus, both lay out the practical question every user should ask before putting money into any protocol. Host: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Laura Shin⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠, Host / Unchained Guests: ⁠⁠⁠⁠Isaac Patka (@isaacpatka) — Certifications Lead at Security Alliance & Co-founder of Shield3 ⁠⁠⁠⁠Mike Silagadze (@MikeSilagadze) — CEO of Ether.Fi Learn more about your ad choices. Visit megaphone.fm/adchoices

I think this principle that code is law and you wrote the code wrong, so fuck you, is just stupid. Like, that's just not how human organizations operate. So there needs to be an error correction mechanism. And that is not necessarily incompatible with decentralization. And the standard should be different for an application versus a blockchain. 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. 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. Today's topic is whether all of Defi is unsafe. Here to discuss our Isaac Packpack Certifications Lead at Security Alliance and Mike Siligazzi, CEO of Etherfi. Welcome Isaac and Mike. Thanks for having me. Good to be here. So if you're on crypto Twitter a lot, you probably know

this week, Manuel Aros. I don't know if I'm saying that correctly. A co-founder of Open Zeppelin. 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 defy 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 and family to leave positions in blue-chip

defy protocols like Ave Makerdown and compound and in response Open Zeppelin tweeted quote recent posts do not reflect Open Zeppelin's physician 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 I was curious Mike and Isaac if you agree or disagree with him that all of defy is safe unsafe sorry and whatever your position is, why or why not? And why don't we start with Mike? Look, I think in some ways you could say the same thing about tradfai, right?

Like you could say that any attacker, like if an attacker comes and gets access to your account, your bank account and sends a wire transfer from that account, you know, we like to think that the banking system is the super centralized protected bubble. But the reality is if they do that, managed to get a wire transfer out, like that money's gone. You're not, you're not getting it back. You know, this obviously, you know, a common pattern. And so you could seriously. So maybe this is just something I don't know about wire transfers, but, you know, because we're used to like chargebacks being, you know, like they won't, they won't. Yeah, depends on the method. Something like ACH. Yeah, there's chargebacks. Something like a swift transfer, a,

For the most part, no, that money is gone. So Trantfy 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, or 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 DFI. Obviously, proportionally, you know, it's different scale.

But there's billions and billions of dollars that are stolen. pretty regularly. But there's mechanisms to deal with that. There's insurance. There's, there are ways of tracing money, you know, back and then chasing it. So the question isn't, is Defi perfectly safe? 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, where is it compare in terms of the level of safety that you get to Tradfai? And the answer is, look, there's some level of risk that you have of your money getting seized, your money getting frozen, or the bank just blocking 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 risks that you're taking in defied, based on the number of vulnerabilities or hacks that occur, The interest rate should be around 12%. So you should be getting around 12% yield on your assets, which sounds reasonable. Like on a gut check, that deals about right. So what we need is to do a combination of, one, improve yields in D5 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-custodied, you know, crypto wallet or a multisig, I mean, I think that can be safer than holding your assets in TradFi. So I don't think a blanket statement that, you know, everything in D is high risk is correct. I think that that's fundamentally wrong. And it puts a very naive sort of amount of faith in Tradfai. Yeah. And for listeners who are interested, we did do a show with Tom done.

Levy, 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 your lending would be 12%. But Adrian of Stakehouse Financial took the other side 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 defy is unsafe. I think that it's embarrassing the level of like operational security failures that keep happening that are leading to a lot of these hacks. 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, long tail math issues, 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 on these like longer tail protocols with smaller TVL or like the the weak points of the big blue chip DFI 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. 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 a lot of DFI protocols are now. thinking like, okay, we actually need to go back through and make sure we have, you know, proper multisigs and time locks and parameters and cross-checking. Like, these are just weak points that we're going to get shaken out at some point. And we're fixing them, right? But we haven't seen some crazy wave of like, oh, my God, we realized that like the, the math underlying uniswap was wrong because the superpower AI figured out a way to break the invariant there.

Like, that's not really happening. It's really just like amplifying the number, the amount that the attack. are able to pursue the, like, really easy to contain stuff that should have been contained all along. Yeah, yeah. So we'll talk a little bit more about that because that is, I think, the really disheartening takeaway. But first, we're going to take a quick word from the sponsors to make this show possible. Is my crypto working as hard as I am? Honestly, that's the question that got me into staking in the first place. I work hard for my money. It should be working hard for me too. Now, you can boost your earnings this Coinbase 1 member month. Until May 31st, any newly

staked assets will get a 40% boost for 60 days. That's extra passive income. Coinbase 1 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 1 card. Plus, this massive 40% staking boost. This is your last chance to take advantage of the 3% deposit boost, your share of 5 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 1 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 slash unchained. Head over to Coinbase.com slash unchained. Last chance to join at Coinbase.com slash 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. Base 1 card is offered through Coinbase Inc and Cardless Inc. Cards issued by First Electronic Bank. Bitcoin back rates are based on cardholders' assets on Coinbase. Back to my conversation with Isaac and Mike. So as we mentioned, because you guys also disagreed with Manuel, 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. He wrote, what a moronic thing to say. Less than 10% of past year defy issues are due to codebase. It's mostly bad parameter configuration, collateral blowup, and poor OPSEC. Fitty 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 McFarlane of Keyring posted, you're actually combining credit risk with hack risk. Two different risks.

For example, Avei didn't 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 you feel are a little bit more important or prominent right now? And either one of you can start. I'd be happy to just start just based on like, you know, when we go in and one of the things that we do like working with protocols is help them build down. 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, 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 math library that causes some issue. But most of the time I'm pointing out things like, hey, your users could become victims of something going wrong on your type scripts SDK that could redirect user funds. Like that's like where a weakness might be. Or on the on chain side, I think less about like the actual core smart contract code and more about like, you know, contagion.

If we if we think about what happened with like ABE and Kelp and the bridges there and stuff, I think that that type of risk is probably the most uncontained and misunderstood in the space right now. Thinking about like how properly contained various protocols are from like one type of collateral asset, 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 pausing, all of this type of stuff, looking for that

type of risk, I'm much more concerned about that type of stuff. And then, you know, 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. I talk to teams that are managing like 50 or 100 multi-sigs for like a massive D5 protocol. And they have this like, you know, patch 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, adding too many zeros onto a parameter when you're doing something on chain.

Like if when we, I like the, you know, if we think about like what happened with PayPal on their stable coin accidentally minting $300 trillion, like that's the type of human an error mistake that I think is more likely than a code error at this point. Yeah, I mean, I'd certainly agree with all that. The operational stuff, I mean, empirically, if you just look at all the biggest hacks, right? The by bit hack, it was 100% operational, even RSETH, right? That was a function of how the layer zero bridge was configured. Drift, obviously.

Every hack basically so far that those of significance was, I call it an OPSEC a failure. So that's something that we care about quite a bit at EtherFri and have spent a lot of time pardoning. The other thing I would say, and this may be a controversial thing to say, which maybe Laura, you'll like, but I think that there is a different level of decentralization that is appropriate for a blockchain versus an application. And I think a lot of applications in Defi engage in what I would describe as decentralization theater, meaning the team, community, whatever, the members of the MaldiSig, always retain the ability to upgrade the contracts.

That's true of pretty much every protocol, maybe with the exception of Uniswap and maybe Morfo to some degree. And so that option is always there. The option to pause contracts in one way or another is generally there. But teams put barriers in the way such that their ability to use 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, an Ethereum or Bitcoin where objectively it's not physically possible to force upgrade the network. But at the same time, 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 have made at EtherFi is to stop playing this game, to stop playing the sort of decentralization theater and introduce things like Blacklitz, 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 the team and the systems that are monitoring the protocol to prevent harm from taking place. And so that's something I think that I think protocols in Defi ought to embrace more broadly. And I actually think that that is probably the only way that ultimately Defi becomes as safe as Tradfai. it's frankly not that hard to detect when, you know,

a 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 MMPL that clearly violates some, you know, some crazy invariant and have the ability to immediately lock things down and prevent an attacker from, you know, draining a liquidity pool or doing something else that's dangerous. And I think that is the responsibility of every protocol to do that, safeguard their users' assets. You can't just throw up your hands and say, oh, decentralization.

Well, it's like, well, you have the ability to upgrade the contract. So you can retain all the non-custodialness and benefits of decentralization as so far as it's appropriate for a defy protocol while ensuring that you're there to protect your users. And that's something that Etheri is going to be, 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 to things 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 decentralized 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 multisigs, which are delegated to three parties. And it should be clear what their delegations are. One is a very fast emergency freeze, a multi-sig that can with a relatively low threshold,

act quickly. 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. from it, but you should at least have one very low threshold emergency pause multi-sig that you can distribute the rights to various people that are going to be guardians of your protocol. And I'm sorry, is that you said three sign or so, is that like three of five or just three of three or like what?

No, I mean three different multisigs 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 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 a second multi-sig you have is typically a DFI 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 takes place and can immediately be used in the same block. if we think about like adding a new type of asset to a cloud 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. And 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, because they don't want you to know that there's an issue, that's a problem. But like, 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.

Like I think Lido just introduced dual governance last year, which basically makes it so that, like, you know, rap steak teeth holders can or like stake deeth 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 heads up. And you can leave before that if you want to get out of there. So that's like not anti-decentralization. That's just like responsible design. Yeah, I would 100% agree with the. with everything that Isaac is saying.

And I guess I'll maybe reemphasize the point that a lot of protocols choose not to do these things in the name of decentralization. And my perspective is this is like performative, basically. It doesn't actually improve the decentralization of their protocol because ultimately they do retain the ability to upgrade the contracts,

whether or not they have good protections of place against that. but it does make their users unsafe. I think not having a hard big red button pause function is irresponsible, basically. Every serious protocol needs to have that ability with the appropriate protections that Isaac mentioned. Yeah, I've noticed, oh, go ahead. The one thing that I'm 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 chart, is like these people that are, you know, doxed and voted on and like, and like accepted by the community to be able to take certain actions like, you know, reviewing a contract upgrade.

What I'm a bit concerned about, though, is like some 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've probably talked about this after the whole like arbitram 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 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 Arvichum 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 a 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 wonder, 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 are you seeing? Like, do you, because 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 prevent that? Or do you feel like some people are still asleep at the wheel? Yeah, I mean, 100%. I mean, certainly either probably isn't 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 concern, I guess, that maybe not appreciated. It works both ways. Like, yes, the attacker can run stuff through an AI model to identify vulnerabilities,

but the defenders, you know, are there first, right? They're there before they ship the code and they can run it through the same, in fact, better AI models. Like, I don't think, you know, the DPRK is getting access to Mythos anytime soon. And yeah, maybe they have access to Claude or Chad GPT. But my guess is actually their OPSEC is probably quite poor because they don't have the ability to access, you know, crowd strike or octa or, you know, other sort of industry practice tools that allow you to lock things down to some degree from an OPSEC standpoint. So I actually think the defenders are at a significant advantage, which is why you're generally the path that they choose as these sort of social engineering tricks where they send you a fake Zoom invite or whatever in order to get 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 like smaller TVL protocols or maybe like devs that have like a figuring out a dev who has like a key to do an upgrade. But like the types of hacks that are happening there, you know, notwithstanding like the really big ones that we saw in April, like, 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 wising up to it. I know that a lot of protocols are, you know, trying to bring more security work in-house rather than just like the old days. They're just relying on your auditing firm. Like they're realizing, okay, we are, even though we're a defy protocol, we need a C-So and we need somebody that's like making sure that like we, have very robust practices for using all these AI tools for our defense. I think that all the security researchers I talk to 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 armverse, but I'm confident in the defensive side as well. Oh, okay. Well, 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? But, okay, so because Mike brought this up, or not just because, but, you know, that'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 a somewhat scarier threat just because humans are much more fallible than machines, you know, or really it's more like there's just 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, since shock waste 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, in a way, it, like, harkens back to the sim swap attacks, which, by the way, still happens. So I don't know why I use the phrase harkens back because that's still going on. But, you know, 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 do you think kind of if there are 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, sent you a fishing email, got you. Like, don't click on things in the future. Because, 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 you put in rate limits or you put in delays, you make it so that the system can. get completely messed up in an instant because you'll assume that people can that people 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 like 200 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 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. I think that may be in a matter of, like, I mean, it's probably happening right now, that like it's just at this point, the AI tools for social engineering are making it so that like we're all like going to make mistakes.

Yeah, so 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 know, I mean, generally, they know that 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, that's probably a very hard path to take. But if they go after a sport agent or after, you know, some more junior list experience, they're much more likely to have success. And so every company needs to have processes and controls in place to ensure that in case that there is, you know, a compromise that there's no way to sort of escalate privileges and, you know,

take down the system. And I think like this is, what we talk about this is though this is like some crazy new thing that, you know, we're figuring out. I mean, this is standard practice. And 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 large companies are very much a target insofar as data compromise, data breach, allows, you know, blackmail on all kinds of ways of monetizing it. So this isn't new.

I mean, this is really, again, going back to the point that, I think Isaac was making, that most of the attacks that we're seeing are actually quite embarrassing and putting in normal, healthy protections against social engineering and basic obsec practices will make attackers' lives 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. To make it more concrete, I think what Arbitrum did, where they locked down and saved, I think it was $75 million, pulled those assets from the attackers and were able to,

you know, give them back to the victims. I think there needs to be a robust mechanism to just do that when it's necessary. It's not, 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 mechanism to be able to make these types of decisions. I think this principle that code is law and you wrote the code wrong, so fuck you, it's just stupid. That's just not how human organizations operate. There needs to be an error correction mechanism.

And that is not necessarily incompatible with decentralization. And again, the standard should be different for an application versus a blockchain. And we're really taking that to heart at etherfine. I think that will make, or that has already in many ways made us the safest way to stake and deploy assets in DFI. Yeah, 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.

Yeah, yeah, I agree. And the other thing is like, 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 two in their heads and like don't just think in this simple like what's right and wrong way. 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. Anyway, let's move to briefly. I don't think charcoal it is doing things necessarily wrong. I think that like their legal position of we respond to court orders 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 actually file because there's courts that run 24 hours a day, seven 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, but that's just ignoring the reality of the court system. Yeah, but I think it doesn't have to be one or the other. I think, again, look, I don't think there have been too many examples of Tether arbitrarily freezing people's assets and, you know, and blocking people. So I think tether is much closer to the right approach 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 going to happen, they can reverse that end.

It's not 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, whether it's North Koreans or otherwise, get out. 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 decentralized stable coin 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.

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 projects are moving over to chain link. Something else that was kind of interesting was Aliyaa 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 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 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 uses a bridge. Yeah. For me, I think that if you're on, if you're like running a defy 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 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 meant, like, what the borrow cap should be for this asset. It's like that's idiotic. Like, like, obviously, the risk of, uh, of an asset going wrong is not just like a DPEG. It's also like, what if there's an infinite mint due to a bridge issue? If they had spent like five 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. Um, 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 the best practices when designing a defy protocol, and it's certainly the way we

operate at Etherpry is to assume that any component, any service that you depend on is possible. It's possible that would be compromised 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 rates limits on everything. Transfers from one, you know, one chain to another, transfers from L1 to L2, just have rate limits 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 etherfi. And we sort of say, look, I know it sucks, but it also protects you and make 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 consider 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, or other systems. Having active monitoring in place, I think, 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 essential. It is, 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, every system has two or three layers of redundancy. You assume that a system is going to break at some point. and you want to make sure the plane doesn't crash into the ground. And the equivalent of that in DeFi is make sure that the assets are not lost. And so you have to have layers of redundancy and multiple protections in case one layer is compromised, because at some point it will be. So this just needs to become standard practice.

There needs to be almost an expectation of a certification process that people can actually trust. It goes beyond just audits that goes into the, the OPSEC and parameters and everything that's involved in ensuring users 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 breaking arresting system worked. And like, that level of redundancy is useful and it helps people feel safer. And I appreciate the lead in to talk about potentially certification.

Yeah, we'll do that in a moment. So I did want to circle back to something we briefly touched in earlier, which was about credit risk. So we talked about, you know, Kelp Dow layer zero. And as has been said, you know, numerous times already, the fallout from that really happened mostly on ABE. We had Paul Frambo of Morfo in the show talking about how Morpho is designed to have this isolated market structure, which is kind of like walling off individual assets and risk parameters. So that. 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 tricks of situations. I mean, AVE is fully like able to be parameterized in that way, right? Like you could have isolated markets. I mean, yes, Morpho is great. But I also think that like just because Avey has the ability to like have a non-isolated markets,

it's not necessarily a bad thing. it's like it's useful to be able to do that and like it is fully you can like set the parameters for what you want to be isolated not isolated. I think those parameters might have not been set correctly in this case, which is easy to stay in hindsight. 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 Avey lending market. Paul or sorry, Mike. Yeah, I mean I agree with that. I think you know, So Etherpry actually has our own, we call it a debt manager. It's not a proper lending market, but that's used for our cash, you know, card product.

And we're looking at migrating to a proper lending market that's, you know, preview of some things to come. And a system like Morpho is, it's challenging. I mean, it's possible to build it on that, but it's challenging. So again, to reiterate what Isaac said, like there's benefits to, to a system like Ave and it needs to be set up correctly. I mean, there's a lot of different parameters that can be said that I think can be more forgiving. I mean, I think a lot of stuff that happens in DeFi where we see people taking,

you know, 10, 20, 30x leverage are appropriate for gambling, not appropriate for, you know, a robust financial products. Okay. So 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 am sure that you're very focused on, you know, trying to keep your user safe. And, you know, I do see you guys are the largest restaker in Defi. So like clearly, you know, 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 instituted.

Yeah, well, maybe I'll focus on the stuff that we've done to harden things. Actually, I'll talk about more generally. So there's certain things that the reason that we were not vulnerable, you know, at any point to this kind of kelp is because we did, is either going to make a lot of decisions that to us seem kind of self-evident. That I guess made us a much, much harder target to go after. And those decisions include things like rate limits across, you know, any bridging, any oracles. There's read limits in terms of how much the Oracle price can change at any given time. Off-chain monitoring to ensure that if some invariant is violated, there's the ability

to lock things down pretty quickly. You know, obviously the layer zero bridge was configured with, I think, in most cases, there's a three of three rather than a one of one. for messages. And again, even if that was compromised somehow, the rate limits would kick in pretty quickly. And the damage would be contained to worst a few million dollars. So there's just a lot of those basic types of these decisions that we made that a lot of other protocols. I think to use another staking protocol as an example, I think Lido does a phenomenal job on the obsec and security front.

But the thing that we're doing now that I think is going a step above and beyond, and I would argue makes us the safest way to stake and hold your assets in DFI, is to stop with the decentralization theater bullshit and put in mechanisms that allow us to, when appropriate, to lock things down, pause things, council vote to be able to pull attacker funds if they end up in the wrong hands, put in the mechanisms that actually allow us to ensure user assets are safe, while still giving people the power of self-custody and defy composability. You know, concretely, the ability to pause the system for 24 hours

and then have that sort of ratified with a broader community, security council vote, to having the ability to, again, lock things down and then make a decision kind of like Arbitrum made to pull funds from a North Korean actor, for example. This all goes on top of the fact, speaking specifically about estate assets, that one of the benefits is that those assets are not actually sitting in our contracts. 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 I think that doing those things allows EtherPy to, I think, very credibly be, in fact, safer than keeping your assets. And for example, a centralized exchange, which could be encumbered in a bankruptcy or worse, such that with Etherify, if you keep your assets, either self-custodied or put it in a custodian, you have all the amounts of transparency. and self-custody while getting the benefits of best in class protection in case

in case there is something crazy that happens in the, you know, in the in D5. Okay. So in the interest of time, because we're running a little bit over, why don't we end on like tips that you would give to users, either in terms of like questions they should be asking before they transact on chain or, you know, what information they should look up to just give them some peace of mind. Yeah. It's really hard for, like, if you're retail users to go to a website or just look at it, like, a contract on ether scan and figure out, like, is this contract operationally safe?

There are some good tools. I've seen, like, some nice, like, L2B has some tools around, like, visualizing control structures. There's a cool block explore 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 users to be like, okay, before I put my money into this thing to get whatever, for like three, four, five percent. I'm going to do like an Opsic audit of everything that I can see on chain. That's just not possible. 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 so that like you can have at least some assurance that some firm went in and check to see how the team's multi-sigas managed, check to see how they manage all of their like parameters and risk and DNS and DevOps and SDKs and stuff like that. Trying to make that surface that as publicly as people expect. for security audits for smart contracts. So, yeah, I'm working with like, 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 meeting a minimum or a pretty high level of like operational maturity. I think that's a better direction for users

than expecting users to like go in and check what the multi-sig threshold is for every like D5 protocol they use. Like, yeah, those are all great tips. I mean, I would say low-hanging fruit, something that maybe is very actionable for an average user is don't use hot wallets, use hardware wallets for anything that you're not willing to lose. That will solve, 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 or a large trusted custodian if you want to go down that path. I prefer hardware wallets, but I think a trusted custodian is a viable option. And then frankly, just don't interact with protocols that are new unless you are, power user doesn't even, I think, describe it appropriately.

Unless you are an extreme power user, you should only be interacting with blue chip defy protocols, of which there's probably like 10 or 15 in defy. so just don't touch anything that is relatively new. Again, unless you have expertise or you're willing to lose 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. Bye for now.