Loading summary
Transcript49 lines
- [00:00]
A
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. There needs to be an error correction mechanism and that that is not necessarily incompatible with decentralization. The standard should be different for an application versus a a blockchain.
- [00:18]
B
Code is not law. Law is ambiguous by design. Ambiguity is built into legal code. For cases that are subjective, code is. Yeah, it's just. Code is not law.
- [00:28]
C
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 are Isaac Patka, certifications lead at Security alliance, and Mike Sulagazi, CEO of EtherFi. Welcome, Isaac and Mike, thanks for having me.
- [00:49]
A
Good to be here.
- [00:50]
C
So if you're on crypto Twitter a lot, you probably know that this week Emmanuel Arroz, 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 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 maker Dowen Compound. And in response, Open Zeppelin tweeted, quote, recent posts do not reflect Open Zeppelin'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 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?
- [02:04]
A
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. 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. You know, this is obviously a, you know, common pattern.
- [02:38]
C
And so you could say so, 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.
- [02:51]
A
Yeah, it depends on the method. Something like ach. Yeah, there's chargebacks, something like a swift transfer. For the most part, no, that money is gone. 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 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 DeFi. Obviously, proportionally, you know, it's different, different scale, but there's billions and billions of dollars that, 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 chasing it. 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, where does it compare in terms of the level of safety that you get to TradFi? 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 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 all the risks that you're taking in DeFi, 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 on a gut check, that feels about right. So what we need is to do a combination of one, improve yields 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 custodied crypto wallet or multisig, 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 Vietnam is, is high risk is correct. I think that that's fundamentally wrong and it puts a very naive sort of amount of faith into. In TradFi.
- [05:21]
C
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 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?
- [05:52]
B
I certainly don't agree that, that all defi 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, given all of the superpowered AI coding agents, they haven't actually found a ton of long tail math issues, rounding errors, bugs. Those happen once in a while. But 90% or more of the time, the failures are pretty embarrassing, easy to avoid. Things that I think now that there's just more and more attention on these longer tail protocols with smaller TVL or the weak point of the big blue chip defi 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, a lot of defi 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 these are just weak points that were going to get shaken out at some point 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 because the superpowered 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, the amount that the attackers are able to pursue the like really easy to contain stuff that should have been contained all along.
- [07:29]
C
Yeah, yeah, so we'll, 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 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 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 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 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 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 Unch 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 OneCard 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 defi issues are due to Codebase. It's mostly bad parameter configuration, collateral blowup 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 McFarlane of Keyring posted, you're actually combining credit risk with hack risk. Two different risks. For example AAVE 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.
- [10:32]
B
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 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, 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 victims of something going wrong on your like TypeScripts SDK that could like redirect user funds. Like that's like where the 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 AAVE and Kelp and, 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, 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 and like 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 talked to teams that are managing like 50 or 100 multi SIGs for like a massive defi 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, you know, adding too many zeros onto a parameter when you're doing something on chain, like if when we, I like to, you know, if we think about like what happened with PayPal on their stablecoin accidentally minting $300 trillion, like that's the type of human error mistake that I think is more likely than a code error at this point.
- [12:41]
A
Yeah, I mean, I certainly agree with, with all that, the operational stuff. I mean, empirically, if you just look at all the biggest hacks, right, The Bybit hack, it was 100%, you know, operational, even RSC, right. That was a, that was a function of how the, the layer zero bridge was, was configured drift. Basically every hack, basically so far those of significance was, I call it an opsec failure. So that's something that we care about quite a bit at Etherfry and spend a lot of time pardoning. The other thing, I would say, and this may be a controversial thing to say, which maybe Laurel, you'll like, but I think that there is a different level of decentralization that is appropriate for a blockchain versus an application 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 multisig, always retain the ability to upgrade the contracts. That's true of pretty much every protocol with the exception of Uniswap and maybe Morpho 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 in 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 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 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 saf safe as tradfi. Because it's frankly not that hard to detect when a billion dollars of your tokens have been minted or moved. It's not that hard to have monitoring in place for transactions that enter the mempool that clearly violates some crazy invariant and have the ability to immediately lock things down and prevent an attacker from draining a liquidity pool or doing something else that's, that's dangerous. And I think that is the responsibility of every protocol to do that to safeguard their users assets. You can't just throw up your hand and say oh decentralization. Well it's like, well you have the ability to upgrade the contract so you can retain all the non custodial ness and benefits of decentralization insofar as it's appropriate for a defi protocol while ensuring that you're there to protect your users. And that's something that Etherfries is going to continue to focus on.
- [16:26]
C
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?
- [16:38]
B
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 multisigs 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 multisig 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 multisigs which are delegated to three parties and it should be clear what their delegations are. One is a very fast emergency pre freeze multisig that can, with a relatively low threshold act quickly. It can also be one that has protections in place from like a higher level multisig to prevent griefing like taking that privilege away from it, but you should at least have one very low threshold emergency pause multisig that, that you can distribute the rights to various people that are going to be guardians of your protocol.
- [17:38]
C
And I'm sorry, is that you said three signers. So is that like three of five or just three of three? Or like what?
- [17:43]
B
No, I mean three different multisigs altogether. And so that one could have like, that one could have like it could be a 1 of 3, it could be 2 of 3, 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 multisig you need to. A second multisig 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 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 multisig 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 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, wrapstake eth holders can or like stake these 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, if you want to get out of there. So that's like not anti Decentralization, that's just like responsible design.
- [19:54]
A
Yeah, I would 100% agree with the, with everything that Isaac is saying. Like, 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. 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, the contracts, whether or not they have good protections in place against that. But it does make their users unsafe. I think not having a hard, big red button pause function is irresponsible. Basically.
- [20:32]
B
You.
- [20:33]
A
Every serious protocol needs to have that. That ability with the appropriate protections that Isaac mentioned.
- [20:40]
C
One notice. Oh, go ahead.
- [20:42]
B
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, doxxed 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, 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 Arbitram 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.
- [22:07]
C
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. 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, to prevent that, or do you feel like some people are still asleep at the wheel?
- [23:00]
A
Yeah, I mean, 100%. I mean, certainly ether 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 aspect of this concern, I guess, that maybe not appreciated. It works both ways. Yes, the attacker can run stuff through an AI model to identify vulnerabilities, but the defenders 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. I don't think, you know, the DPRK is getting access to Mythos anytime soon. Yeah, maybe they have access to Claude or ChatGPT, but my guess is actually their OPSEC is probably quite poor because they don't have the ability to access, you know, CrowdStrike or Okta 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 I actually think the defenders are at a significant advantage, which is why generally the path that they choose is 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.
- [24:31]
B
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 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 that, 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 of just relying on your auditing firm. Like, they're realizing, okay, we are. Even though we're a D5 protocol, we need a CISO 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, like, 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 armed race, but I'm confident in the defensive side as well.
- [25:46]
C
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, 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 a somewhat scarier threat just because humans are much more fallible than machines, you know, or really it's more like there is 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, hearkens back to the sim swap attacks, which, by the way, still. Still happens. So I don't know why I use the phrase harkens back, because that's still going on. But, you know, the. The weak link there was the human customer service representative 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 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?
- [27:28]
B
Yeah, I don't, like, just the. The social engineering, like, Training sessions which are just like, oh, we like, like sent you a phishing 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 job. 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't 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, 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 of 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. Like, I think that maybe 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, we're all like, going to make mistakes. Yeah. So we just need to define, make the systems tolerant to those mistakes.
- [29:02]
A
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, they target the lowest level employees. Like what they, 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, it's, that's probably a very hard path to take. But if they go after support agent or after, you know, someone more, more junior, less experienced, 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, we talk about this as though this is like some crazy new thing that, you know, we're figuring out. I mean, this is standard practice. 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 insofar as, you know, a data compromise, data breach allows blackmail and all kinds of ways of monetizing it. So this is 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 embarrassing. And putting in normal, healthy protections against social engineering and basic OPSEC 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 have, 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 then saved, I think it was $75 million, pulled those assets from the attackers and were able to give it back to the victims. I think there needs to be a robust mechanism to just do that when it's necessary. That shouldn't be that controversial. I'm not saying that there should be one button that says take this wallet's money, but there should be a robust process with a 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 is 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 etherfi. And I think that will make or that has already in many ways made us the safest way to stake and deploy assets in defi.
- [32:16]
B
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.
- [32:27]
C
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 too in their heads and like don't just think in this 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 briefly.
- [33:12]
B
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, 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, to actually file because there's, 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
- [33:41]
C
or it is just ignoring the reality of the system.
- [33:45]
A
Yeah. And, 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 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 and it's not that big a deal. 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, 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 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.
- [34:45]
C
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 projects are moving over to Chainlink. Something else that was kind of interesting was aliyah of a 16Z was on the show talking about how privacy chains are going to be emote 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, that uses a bridge.
- [36:09]
B
Yeah, for me, I think that if you're on, if you're like running a defi 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 meant like what the borrow cap should be for this asset. It's like, that's idiotic. Like, like obviously the risk of, of an asset going wrong is not just like a deep egg. 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. 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 level point would be a bit more paranoid, but it's just. Yeah, it's terrible.
- [37:32]
A
Yeah. I mean, I think the best practices when designing a DEFI protocol, and this is certainly the way we operate at etherprise, to assume that any component, any service that you depend on is possible. It's possible that it 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 rate 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. It 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. 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 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 put a stop to it pretty quickly. So I think 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 that goes beyond just audits, that goes into the opsec and parameters and everything that's involved in ensuring users don't lose their assets.
- [40:04]
B
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 that level of redundancy is useful and it helps people feel safer. And I appreciate the lead in to talk about potentially certifications.
- [40:25]
C
Yeah, we'll do that in a moment. So I did want to circle back to something we briefly touched on earlier, which was about credit risk. So we talked about kelp dao layer 0 and as has been said numerous times already, the fallout from that really happened mostly on aave. We had Paul Frambo of Morpho on 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 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.
- [41:07]
B
I mean obviously like able to be parameterized in that way, right? Like you could have isolated markets. I, I mean yes, Morpho is great, but I also think that like just because AAVE has the ability to like have 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. Just easy to say in hindsight. But yeah, it's not, I think one way or the other you don't have to pick one like you can do that type of asset isolation on an AAVE lending market.
- [41:44]
C
Paul or Sorry, Mike.
- [41:46]
A
Yeah, I mean I agree with that. I think, you know, so Ether actually has our own, we call it a debt manager. It's not, it's not a proper lending market for, but, 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, is, it's challenging. I mean it's possible to build it on that, but it's, it's, it's chall. So again to reiterate what Isaac said, like there's benefits to a system like AAVE and it needs to be set up correctly. I mean there's a lot of different parameters that can be said that I think to be more forgiving. I mean I think a lot of stuff that happens in Defi where we see people taking 10, 20, 30x leverage are appropriate for gambling, not appropriate for a robust financial.
- [42:46]
C
Okay, so just in the interest of time, why don't we have you now just talk about kind of you know, Ether Fi's architecture because you know I, I'm sure that you're very focused on 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 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 site types of defenses that you have instituted.
- [43:15]
A
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 at any point to this kind of CALP attack is because we did as Ethereum 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 0 bridge was configured with I think in most cases a three of three rather than a one of one for you know, 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, you know, to use another staking protocol as an example. I think Lido does a phenomenal job on the, on the OPSEC and security front. 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 Defi 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, you know, 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 defi composability, you know, concretely the ability to pause the system for 24 hours and then have that sort of ratified with a, you know, broader community security council vote, having the ability to again lock things down and then make a decision kind of like arbitrum made to, to pull funds from, you know, a North Korean actor, for example. This, 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 in the Ethereum beacon chain deposit contract, which limits the potential risk to just the amount that's in the liquidity buffer pool. So I think that doing those things allows ETHERFI to, I think very credibly be in fact safer than keeping your assets in for example a centralized exchange which could be encumbered in a bankruptcy or you know, or worse such that with etherfi, if you keep your assets either self custody it or put it in a custodian, you have all the benefits of transparency and self custody while getting the benefits of best in class protection in case there is something crazy that happens in the, you know, in defi.
- [46:43]
C
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.
- [47:00]
B
Yeah, it's really hard for like if you're retail users to go to go to a website or just look at like a contract on either scan and figure out like, is this contract operationally safe? There are some good tools I've seen like some nice like, like L2B 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 users to be like, okay, before I put my money into this thing to get whatever like 3, 4 or 5%, I'm going to do like an OPSEC 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 multisig is managed. Check to see how they manage all of their 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, working with, there's 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 multisig threshold is for every like defi protocol they use.
- [48:31]
A
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, 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 defi protocols, of which there's probably like 10 or 15 in DeFi. So just don't touch anything that is relatively new again, unless you have expertise or you're willing to lose those funds.
- [49:38]
C
All right, you guys, well, this was such a great conversation. Thank you so much for coming on Unchained.
- [49:42]
B
Thank you, thank you.
- [49:43]
C
All right, and thanks to all of you for watching. We will catch you next week. Bye for now.