# Long-Tail Asset Oracles: Enabling Collateral Diversity in DeFi​ - Brenda Loya | Tellor - Speakers: Brenda Loya - Channel: [ETH Belgrade Community](https://streameth.org/eth-belgrade-community) - Date: 2025-10-07 - Duration: 23:13 - Topics: People & Blogs - Watch: https://streameth.org/watch/yt-nPA__5Kc8xk - YouTube: https://www.youtube.com/watch?v=nPA__5Kc8xk ## Description Long-Tail Asset Oracles: Enabling Collateral Diversity in DeFi​ - Brenda Loya | Tellor ## Transcript Well, good morning everybody. Thank you for coming and getting up after proof of Rakia last night. Um, but yeah, so I'm Brenda. I'm one of the co-founders of Teller and today I'm going to be talking to you about longtail assets, why they're important, and how we can use them responsibly. Um, a lot of these blue chip assets that we see today, they were able to evolve in a state where um, where the whole ecosystem was small enough to support them or their growth as everything improve, everything grow grew. And so as we implement new longtail assets or new um assets, created assets, new shitcoins or whatever you want to call them, um we have to create this mechanism for them to also grow. We need to nourish them. Otherwise, we're going to end up with like three or four very centralized stable coins or very um very few assets which go against everything that we set out to do, right? We want to have diversification. We want to have decentralization and that includes the assets and the things that we create within the ecosystem. And I want to talk a little bit of something that just happened last week with um Avalanche Oiler. There was apparently um a manipulation of the asset and people, you know, immediately most of the time they blame the oracles. We're an Oracle and we we deal with this all the time, right? As Oracle providers, it is important to understand that there is a there are different layers of what you we're trying to provide and how we can make it secure. Um there are so many things with what is discussed here. Uh for starters, uh I want to dissect a little bit of what happened. Um, somebody put in or Jared from Subway apparently put in a trade in a curve pool for 210K USDT for D uh to buy DUSD and they ended up moving the price that ended up triggering an update to the oracle that Oracle pushed around to different networks and then um that led to liquidating about 534K in assets. And to me that is the biggest problem right the problem here is that the cost of attack was way lower than the gain of the attack. So no matter what you're doing if that's the case you're going to have a hack or an attack you're gonna you're going to experience this no matter how you do it how you how you structure things. Um, and so as a protocol and as a user of a protocol, when you use them, you're actually agreeing to the risk of these markets. And so if you cannot calculate the cost of attack, I can guarantee you there is a hacker out there that is calculating it for you. So in this case the guy went on on discussing I forget his name uh Omar Goldberg on discussing like what happened but he doesn't actually go back to the actual problem underlying problem and this is like it's the the market for deusd within a curve pool There is no magical thing that any oracle can do to prevent asset manipulation when this is the market that you created. This market is so small too. If you look at the volume, it's very small. It's going to it's ripe for somebody to to come in and take advantage of it. And so blaming the Oracle for this is I think one unjust and also a little bit irresponsible. It's sort of like scapegoating and just choosing the oracle. But let's talk a little bit more about how we can actually create or use these assets in a more secure way. We have to first understand that there are several layers of security that come in anytime that you want to use any type of asset. But specifically for longtail assets or low TVL or low liquidity, you have to make sure that you have all of these layers in place so that you can protect your users. Um I don't know how many of you guys have ever uh designed your own protocol or helped design with design, but I can guarantee you no matter at what level of your protocol you're in, if there is a hack, you will be affected. If there is a hack, it's always um uh you know, it's not just the company that suffers, but all of its employees might even end up without jobs. So, it's all of our all of our jobs to make sure that everything is as secure as possible. Um the first layer of security for any type of asset that you're using is actually coming up with a definition of what you want to use in your protocol. Um many times people come to us and they're just like uh well you know I need the price of Ethereum or I need the price of Bitcoin. It's like cool but the most important thing is how are you actually using it? Which price do you need? How do you want it aggregated? Um how does this affect your protocol directly? And so a lot of times when people um just want to use something that is out there maybe you know I know we push some prices um on chain that people can use without really requesting them and chain link does the same thing and other oracles do the same thing and people decide to use these price feeds even though um they don't really understand what's the underlying mechanism that is being used to aggregate or provide this information. So the very first thing that we that you need to do is as a protocol what is the proper definition? Is there enough liquidity for this asset to create a market that can support it? Um if there isn't is there a type of aggregation that can improve my security and data sources obviously they come from where is this asset listed? And you know, you might have like uh 10 supposeded data sources um from like market cap or uh coin gecko. Uh but they're if they're all coming from the same one pool, people are going to know that that is the the weakest link and the point the best point of attack. So that is the very first layer that you have to address as a protocol. No matter what oracle you choose, you're going to have to be able to provide this information and they're going to hopefully, you know, they're asking you these questions. And then after that, the Oracle rarely, very rarely, unless it's a bad implementation of the actual Oracle gets hacked. I've looked for I looked through uh WCT website through different hacks that had happened at least uh for all of 2023 and 2024. The majority of the hacks do not happen at the Oracle protocol level. They happen at the asset manipulation level. That's why it's so important and that's why honestly at this point I feel like you have such a broad range of oracles that they can do the job of providing the information. Um you can also use CK for some of this stuff. But the third level of of security falls within your protocol and how you use information, right? or how you use this information, how you settle. Um, some protocols um have long implemented fallbacks like freezing the system when something goes haywire uh or using a delay to actually use the the incoming information. There's and but all of these um things you have to think about when you're designing your system. If once the hack happens, if you don't have all of these things in place, it doesn't matter what you do. So that's the fourth um the fourth layer of securities, what are your system fallbacks? You have to be able to address an Oracle failure, an Oracle dying. Maybe they disappear. You don't get any information or you get bad data. All of these fallbacks have to be within your system only because ultimately if you get hacked, you're going to be the one that's going to be responsible and going to have to go and do a postmortem afterwards. You want to make sure that your users are as secure as possible. Also with all of these different ecosystem growing, you anytime you know you go and deploy maybe um on Cosmos or on um Ethereum or or some other L2 or some other ecosystem that you decided fits your needs, you are also taking on the risk of that of that chain or of that ecosystem. One uh odd hack that happened uh last year was the Levana protocol. They are deployed on Osmosis chain and um if you guys remember Black Thursday uh when Ethereum crashed and everybody was trying to liquidate their positions and there was a huge congestion in in on Ethereum gas costs were really really high. So so the oracles couldn't update the information as fast as possible and so then a bunch of liquidations ended up happening. that happened in 2023. Uh 2023 or no 2020 anyway 2020 I think. Um and then in 2024 they recreated that same attack but on osmosis chain on the Levana protocol and the attackers they basically created the congestion. So they knew when the Oracle updates were going to happen and they were able to make money off of it. So when you are deploying wherever it is that you're deploying you are also taking the risk of that ecosystem. So you have to make sure that you build for it because it can happen and like I said it's happened to Levana protocol. It's going to happen to other protocols I'm sure in the future. But also if you decide to do your own DOC chain how do you handle these these changes? Are you going to build lanes for certain type of transactions? These are all questions that you have to address before you actually deploy and it's part of this layered approach to security. And then the last resort I think um it's always your social layer. You have to be able to if everything falls, you know, it something happens and um you're lucky enough that you do have a pause button, then how do you go back and make things right? Do you have a governance system behind it? you just fork the chain and you know update your chain and update uh address um balances. How are you going to approach this within your own community? Because whenever at least um in my experience whenever we design a system you design it to do whatever you think you know the community wants and and then you have all these disclosures. This is how this works. this is how the risk that you're that you're taking on when you're using this protocol. When an attacker comes, they basically break the rules, right? That's not what you intended to do. So, how do you make sure that your community says, "Okay, this is the way and the path that we're going to go from now on." So, all of those layers of security are what what's going to keep you secured. Um, one of the most recent uh examples of that is Hyperlid. um they had um also like a hack and they went back and they're like, "Nope, uh we're gonna update our Oracle." And I think they even made money off of it. But I can guarantee you they're not going to get hacked anytime soon because they know that they're not going to make as much money as they think they could. Um but with that said basically um for longtail assets you know right now we've we've built an ecosystem that very much supports very most blue chip for collateral and it's not going to allow us to expand and experiment if that is the only only type of collateral that we're able to use. We need to create an environment where other collateral can also grow to become as strong as some of the ones that we already have. And for that obviously we have to implement oracles properly and implement these layers of security that guarantee the safety of our users. Um oracles are super important because we we want to provide prices as fast as possible but we also don't want to provide prices in a way that they can be manipulated. So they're very difficult. Um, and you know there's you know they they're the ones that drive liquidation. Like basically if you get a bad oracle price you can have a really bad effect on your system. I'm not going to go through liquidation example because I'm running out of time but uh this is the example of um Black Thursday with a flash crash uh with a with a crash on Ethereum. This is an example where maybe we would have been, you know, we we really wanted to update prices as quickly as possible. We didn't want to use stale prices and but because of the congestion of the system, we ended up having this um this bad outcome. This is actually um an example of when we actually probably could have been okay with slower updates because you know we had the USDC DPEG that came from something that wasn't even happening on on on on the crypto world right it came from um the Silicon Valley bank and Silvergate and all of these banks that in the US basic were basically our Afrs um they were being shut down basically basically. And so that caused a little bit of a chaos in terms of of of people thinking they needed to get out of these positions into more uh into other assets because they maybe couldn't take the money out. And even though it was an only I think only 8% of USDC USD for USDC was in one of these banks, it ended up having a a really big effect. I think it went down to 88 cents or something like that. uh uh USDC. So this is the choice that we face generally where we want really fast oracles because we don't want stale prices but then we don't want um assets that can be easily manipulated and so where do we find the balance or we just have to determine what are the trade-offs that are that we are willing to make and we need to stop pretending that there are no oracle risk. um you know everything from um you know the liquidity of the assets to the smart contracts being able to fail and not being able to or to to to really drive whether you know all the time completely be sure that we need a fast oracle or a slow oracle and you know for DeFi to stay competitive we have to find better ways to collateralize we're already you know very capital inefficient in comparison with TRFine. Um but low liquidity um low uh longtail assets are really tough no matter how you you know how how you put them. But it's also you know a very good example of why we need to move forward from how we have been treating uh these these assets as somebody else's problem. you come to the oracle and you're like, well, you know, I need this and we just are supposed to be magical and make liquidity appear for an asset that doesn't have it. It's not going to happen, right? So, even if you do a traditional oracle, a traditional oracle does not address this this problem. Uh, native pricing with AMMs or TWAPS, you know, you're going to either have a stale price or you're going to have a highly manipulable asset um or feed. um alternate designs, you know, you either put uh the users at uh I guess they get to decide what they want to do or you just, you know, set the price of USDC to one. It's also not ideal because think can depend. So we need to really start thinking about how do we address this as a as a whole instead of you know this is compartmentalized in in this one area. The oracle does not guarantee that the asset will not be manipulated. And if you do have an asset that can be manipulated, then you do have to address it within your own ecosystem. Otherwise, we're not providing an environment for all of these assets to actually grow to become those blue chip that we do want to have and that we have want to have as diversified um assets as as possible and continue to grow as an industry. Otherwise, we're going to hit a top and then that's going to be it. um we need space to to actually experiment. Um there are a few things that you can do within your own protocol. You can you know do some volume limits. You can do some auto liquidation models. You can do um depending on how you're using the prices you you might actually instead of using the average you might for some for some type of liquidations you might want to use the highest price seen on the market versus lowest price seen on the market. Um, you can get very creative with these things, but it has to go back to, you know, a lot of like um, you know, Athena or Morpho. They're great, but they're really just blue as blue chip asset, right? Because they're not designed to be able to handle these high-risk markets with with better um, better better fallbacks. So yeah, you could uh for morpho use anything any RC20, but is it designed to actually use it? I don't think so. You know, I it's it's designed for for things that are a little bit more quote unquote stable. And so we need to do better if we wanted to if we want to actually grow and expand as an industry as a whole. And for longtail assets, that means actually providing an environment where they can actually grow over time with us. And that's the end of my time, but if anybody has any questions, happy to. >> Okay, let's give Brenda a big applause. >> Uh, we can start a Q&A session. So, if anybody has a question, please raise your hand. We have a question right over there. Thanks. That was a great talk. Um I'm wondering whether some of the problems you described could be found with economic simulations. For instance, you could see if you know have a very small pool then something bad will happen. >> Um you're talking like just like running simulations before you actually feed the price. Yeah, I just try to experiment like if I have a small pool and something bad happens, how the prices are going up or down, what who loses the money? >> Yeah, I mean um you should definitely Yeah, you should be able you should be able to run those simulations in in essence um that is part of knowing what is the cost of attack of your system or the asset that you are providing a market for. Um, does it completely address it? I I don't know. It I think it depends on how you structure your your system. Like if you know that something is really ripe for manipulation because low TVL or low liquidity, maybe what you want to do is for that specific market, you have limits. You know, you have some um some caps for changes or some caps for losses and gains. uh and I and that could potentially take you know the attackers like okay maybe it's not enough money it's not worth the hassle but ultimately it has to go back to you you can do all of these simulations offchain and even if you before you feed the price or or something but ultimately you're going to end up like are you going to be is the price going to be stale after you go run all these simulations and then uh you submitting a bad or an older price than necessary or is your system fine with taking that trade-off and that is fine too because once you disclose it to users they know what risk they're taking and I think that that is the fairest thing that you can do as long as they know their risk they know what they're signing up for um and I say this you know very very lightly I know that a lot of users don't really know what the hell is going on in the protocol to be honest and don't really care they just you know heard from their friend that they made money and then they're trying to follow their strategy Y and you're you know and then they lose money and everybody complains and then you go and ask them but did you actually no they they don't care. Um as a company I think it makes it very very difficult because you have to like make all of these disclosures and tell them like this is your risk and this is what's happening behind the curtains and they still may not listen and then they go and do a big splash when something happens. But I think as a community, because most of us here are builders, if we address it with all of these layers where we're taking everything into consideration from the def data definition, which seems a lot of times unimportant um but it is so important um to how you handle the actual attack or an a aftermath of an attack then you actually have a secure system, a fully secure system. It doesn't make it unbreakable, but at least you have a plan. >> Sounds good. >> Okay, any other questions? >> Then let's give a big applause. >> Thank you.