All right. Yeah. So, um my name is Brenda. I'm with Teller and today I'll be talking about systemic risk in DeFi and how we can be or we should be addressing it globally. Um oftent times uh in DeFi we're we're faced with a with a choice of either using really fast data that can be more or have a higher risk of manipulation or waiting for more robust information and then run the risk of settling on stale information.
And oftent times we choose speed and that can lead to unintended consequences. So, a couple of weeks ago, a trade was executed on Ethereum on an Ethereum curve pool uh for 210K for DUSD that caused a really cost enough of a change that it triggered an Oracle update on this asset on Avalanche and that led to 532K in liquidations there. But before we go into what happened here, let's first first talk about the data flow of this um process. So for oiler to be able to use this information or to settle those or for those liquidations to happen, they first have to get their data and the way that they get their data is the you know the oracles going collected aggregated and this aggregation is generally affected by uh the aggregation method the sources and obviously the everchanging liquidity. Then this information is aggregated.
The oracle takes this, puts it on chain either on their contracts or directly on the protocols contract so that they can do something with it. And then after that they they can execute on on this information. If you uh the circle around here represents the things that happen onchain versus the things that happen offchain. And so let's talk a little bit about the things that went wrong in this uh scenario. one, we know that this was a highly high high risk asset with low liquidity because it only took 210K to move the markets.
Um, there were no monitors available because nobody did anything when this happened except the hacker. Once he found out he could be he could benefit, he went ahead and and executed. Um, the Oracle was actually really good at providing the information very quickly. We s down the first graph. The price only went up very quickly and then came down.
But the oracle caught it and provided the information uh relayed the information very fast. Then the D5 protocol um had this liquidation. So they didn't have any fallbacks to address the fact that this asset uh who I don't know the whole uh story about it, but maybe it had better liquidity when they first listed it or when they first opened the market and now it didn't. And so they treated the same as they would have treated maybe a blue ship asset. So there were no fallbacks.
Uh some of the fallbacks that they could have used um include limiting the change on the asset especially they know there is limited liquidity. Um I know a lot of people don't like to cap this because it can lead to caps of gains and loss gains as well as losses. um they could have used an oracle delay uh slow down the withdrawals and or change the conditions based on the liquidity or based on the fact that some of their assumptions could have changed from the point that they listed this asset and now um one thing that I want to note that didn't happen in this specific attack but the majority of these attacks happen by people using flash loans and so you need to make sure that within your protocol you build some resilience to this and this could be as simple as requiring ing a collater collateral lack of period or just slowing down your withdrawals and for governance as well um snapshot voting or otherwise that can also be affected with flash loans. All right, going back to our example, other things that could have been done better, uh, monitors. Obviously, the assumptions can change over time, especially because liquidity for each asset can be different depending on, you know, what's happening on the market or just specific to that asset.
Um, and like I said, if you don't know the cost of attack of your system, an attacker will calculate it for you. And so uh other things that you could do is obviously having more robust aggregation methods. All of these uh portion of uh getting information collected happens offchain and calculation and computation is very cheap. So you can get very sophisticated on your aggregation methods, um on your outlier detection and just other random uh checks like making sure your APIs are working properly and are and the data that they are pulling in is formatted properly. And I know that that sounds simple or far-fetched, but synthetics a couple of years back uh they actually had a case where uh there were a bunch of liquidations that happened because they were using one API as their oracle and their API started somebody was testing something started reporting an extra three zeros there and lucky for them the majority of the liquidations were caught by a bot and the pe the the owner was nice enough to give them back the That might not happen to everybody.
That was uh but anyway to put it all together, the seven layers of security that you need to actually implement uh your Oracle properly and securely include having a robust data definition, having monitors so that if your assumptions change, you can act on them. Um choosing your oracle wisely and implementing it properly within your protocol, make sure it goes through your audits. Um and then obviously having fallbacks for when you get stale data, no data or bad data into your system as well as no matter what um chain you decide to deploy on, you are inheriting their their risk as well. As we saw with Black Thursday, um Oracle prices or Oracle updates can be affected by congestion on the chain and that was uh something that happened on Ethereum on Black Thursday for Maker uh with a bunch of liquidations. Um and then your last your your last resort is going to be obviously your social layer.
Even if you can program some of the things on chain for having like an onchain governance, uh if all else fails, at least you should have a way to to organize your community and make sure that you come up with a plan if something just goes haywire. Um we saw this in Hyperlquid, right? Um they had a hack where somebody went and manipulated the price of jelly. uh it's a it's an asset and ended up sort of making it so they could tap into the protocol's uh vault and they stood to lose about 260 million and then they decided to um basically revert it and overwrite the Oracle update and it was really controversial because they actually made money off of it. And then on top of that, um, a couple of months before there had been an issue where, uh, North Koreans ran away with about $100 million and they went through hyperlquid and they did nothing.
And then in this case, you know, now they're choosing winners and losers and they went in and they actually made some money off of it. Um, and that's super controversial, not just because of the way that they handle it, but because it opens up um, a lot of questions and a lot of uh, it undermines or it could undermine and and I say this like as I talk about making sure that you have fallbacks, you need to have a balance between your fallbacks, your social layer and your credible neutrality because once you start censoring in your system, then there is no reason why a government cannot come and tell you censor this for me or do this or do that for And once you lose that then you're undermining the very premise of actually using decentralized systems um in crypto which is censorship resistance. Um these are a couple of significant events that have happened in crypto that you can use to go uh my framework to go back through them and see how they um had some failures due due to the fact that they didn't have all of these security layers in place. I have 20 seconds. I think one of the most interesting ones uh that I I I I didn't think I was going to have time to talk about is the USDC DEG because that would had nothing to do with something on chain but with um with banks in the US that I uh Silvergate and um uh Silicon Valley Bank they they were shut down and uh that caused and triggered a bunch of changes on USDC just because they were holding like 300 or three million or 200 million I don't know something something very insignificant but it cascaded into changing die and and fracks were all affected because they were holding USDC in their in their collateral or their reserves.
But with that thank you everybody. Um yeah [Applause]
Automatic transcript — names and jargon may be misspelled.