DAPPCON 2025: Scaling Oracles for L2s and Beyond - Brenda Loya

Transcript

Thank you. Well, hello everybody. I'm Brenda. I'm one of the co-founders of Teller and today I'm going to be talking to you about how to bring oracles to L2s and beyond. Uh the two takeaways from my talk should be that to scale oracles we need to implement layer security and also we need to find a balance between the fallbacks for those layer security uh aspect your social layer and credible neutrality. So over the last several years we have been scaling through diversification and we've seen a lot of ecosystems pop up you know even u you know we see

avalanche we see cosmos with salana and even bitcoin is jumping into the game and so as uh teller as we started seeing this this trend we wanted to make sure that we would be able to support all of this and although we've done um great strides and we still have a lot of work to do But ultimately we have been able to connect and do a lot of um uh connect a lot of chains in general. We still need to work on interoperability but I think it's more in optimizations than like than actually figuring them out.

Um, and to illustrate this point, um, I want to talk about this example that just happened a couple of weeks ago where a trade was executed on Ethereum on a curve pool that caused a bunch of liquidations in Avalanche. Um, and rapidly, you know, people went off to say like it's the oracle's fault, which I don't agree with because if we look very closely to this example, we see that the liquidity for the 24-hour liquidity liquidity was actually really low. Also, um, there's not a lot of sources for the information in general.

And whenever you have a scenario where the cost to manipulate the asset or manipulate or the cost of attack is so much lower than the actual gains, you're going to end up with something like this. So I went ahead and uh uh took away their original post blaming the oracle and I just said, you know, if when the cost of to manipulate an asset is less than the gain, this is bound to happen. But here we can see very clearly that the actual crosschain communication happened very efficiently. It just led to unintended consequences. And that's where I'm going back to why we need to implement different layers of security to make sure that our oracles work properly because more often than not

we're facing these uh two choices, right? We want really fast data, but it can be more or can be um more likely to be manipulated or in terms of assets. But if we wait for more robust um data or different more aggregations or more time, then we're risking settling with stale prices. So it's uh this uh tradeoff that as in the DeFi community we know very well. Um and because of that uh we need to continue to optimize but also understand the the implications of those optimizations along with and use that to also

implement those layer securities layer of security. um Teller, I'm going to tell you a little bit of my about my story or our story because as the the industry continues to evolve and all of these new ecosystems continue to emerge, you're going to run into very similar problems, especially if you started off as as as far along as as we did. Um we initially started as uh smart contracts on Ethereum. It just made sense. Ethereum had the majority of DeFi and it made sense for us to just deploy there and become an oracle there. And at the time we actually had a system where all of our validator data reporters had to be staked and then um because uh the

way that we would come to the official value um that was reported. It was the first five values that came in got some minted rewards and the medium became the official value and then anybody could dispute the validity of the data h for 10% of the stake and if they won the dispute they they would take the whole stake otherwise um the data provider would get some money for the the the fee for their travels for being wrongly accused and so all of this has been was been done in on chain and it worked I I think uh just fine when we were only in one chain. The problem that we then were facing was okay, we want to support all of these ecosystems that are emerging

and all of these new chains and every it seemed like every week there was another chain that popped up and for us to be able to go and support them. One of the things that we needed to have was an actual bridge for our token so that people can go and stake and and dispute and tip um the the data reporter so they would know that they needed the information. So we had to make sure the only way that we could expand is making sure that there was a a token branch that we could trust. And then once we did deploy into all of these different ecosystems, we were obviously faced with fragmented liquidity because everybody had to bridge their token and we didn't have the same amount of security of that

we had in in Ethereum. And one of the ways that we adjusted for that was basically when you go to another chain, you assume their risk. you you have to change maybe your parameters to be able to um to gain the same level of security as you do in other chains. For us that meant changing some of our variables to to adjust them to the speed of the chain. So for us one of our security um aspects is the the whole staking thing. And so because and that's based uh as a that's a function of the speed of the chain of how quickly a new uh a new value a new price or pricing information

or whatever other information can be replaced with with good data. So if somebody uh provides bad data how quickly it can be replaced. And so for us that meant um adjusting some of our variables even though we were deploying the same exact system that was fine for EVM. We had to change some of those parameters to be able to have or aim for the same security that we were getting on Ethereum. And that, you know, could only take us so so so much for could only get our security uh as close to Ethereum so much because um even though um we could adjust these variables at the end of the

day if there isn't as uh broad enough network as it was on Ethereum when people ramped up the demand we wouldn't have the exact or all the network that we needed to be available. So with that in mind, we set out to build our own app chain. And one of the things that we really wanted to make sure that we had one, we wanted to have a easier way to expand. So no more reliance on on bridges and also um an easier way to deploy on different ecosystems with different languages. So instead of rewriting the whole system in a new language, we would just rewrite the like client bridge and then we can reach over

data. And one of the main aspects that we wanted to have as well was a social layer. Um I don't advocate for forking all the time obviously or you know that's a last resort type of thing that you that you may hopefully never have to do. But we wanted to have that social layer as more of a credible threat to hackers that if we need to, we will use it. Um, granted, we hope we never have to, but we wanted in. And then we we gained some efficiencies and and we went ahead and we created this whole other, you know, we have our our own chain and our own way of coming to consensus. But the takeaway from this is that no matter

what oracle you use and what um how they come to consensus, whether they're a peer-to-peer network or they have their own chain, um you're not going to get away from the fact that you have all of this risk offchain risk. If you don't have a proper definition for the assets or the information that you're requesting, you're actually have a lot of trust boundaries that you have to address in different ways than just saying it's the oracle's uh responsibility. When you have a market of of something of an asset that has really low liquidity, you're accepting that that responsibility. Um so you have to come up with creative ways to come up with more robust definitions for that.

You're also making you're also trusting that the APIs are not going to come down and that you're going to be able to collect the data efficiently and as fast as you need it for your protocol. Um, but with creating our own system, we came, you know, even though we gained some efficiencies, we have a social layer. Uh, we don't have to rely on the speed of Ethereum anymore to dictate how fast we can be or can't be. um we do have to to also take other risk. So now we have a different set of risk than before that you know like if there is 66% malicious validators on any chain not just on on teller or a pure pure network then that means that they can

control the information that or the things that happen within it or the state that happens within the chain. um 33% can probably stop 33% plus one can stop it or can can stop the chain basically. And so those risk you assume in this ecosystem where it's so diverse uh anytime that you're interacting with another chain that's something that you have to deal with. And so aside from the the risks that we already know that come with oracles and the external part like the the ones on chain and the ones off chain, now you have to deal with this extra risk. And so this is where the point comes of um having to when you want to expand into all of these

different ecosystems, you actually have to think about it in security in in layers. So the first layer of security for any Oracle to be implemented properly is going to be your data definition and you can work with the oracle to come up with something that makes sense for your market. Even if it's something that is low liquidity, you're just going to have to have more rails or more guardrails within your infrastructure, your architecture to be able to handle that. And so that's the first layer of security that you have to address. Then the second obviously choosing your Oracle and making sure that you implement them correctly. We all work a little bit different and there's a lot of flavors of us from very decentralized to a lot more centralized and it is up to what you are doing that

makes it the correct decision and but once you do know what you're doing and what you choose you have to implement them properly right um and don't leave it to be the last thing after you do the audit. it should be part of your audit. And then after that, the the next um layer of security is making sure that you have fallbacks within your system. You want to make sure that you can either freeze the system or you might want to do caps on um on on on withdrawals or limits different just different ways of handling what happens if you don't get any data from your Oracle. What happens if you get bad data from your oracle and what happens if you

get stale data from your oracle and then obviously any chain that you deploy on you're taking on the risk that come with that from OEV me and uh chain congestion that is something that you should be taking into consideration. Um, we've all saw what happened with Black Thursday. And then within your own ecosystem, when something goes really bad, you also have to have some sort of governance or some sort of rules that determine what happens if everything goes wrong. How do you make it right for your for your community? Um so a couple of weeks ago uh there was this hack sedto is an exchange on on sooie and they got hacked

or they could have been hacked for about 230 or 260 million and they basically stopped the bleeding by all the validators from Suie decided to ignore the attackers transactions and you know I'm I'm not condemning or or saying I'm not saying that this is was right or wrong but This is something that they were able to do. Um, hyperlid liquid is another example of um a you know of hyperlquid taking over or making it right or I don't know there's a lot of controversy on what happened with in hyperlquid. Um, there was also it was an asset manipulation type of hack and then uh the hyperlquid team basically

overrode the oracle information and they ended up making money off of it and I think that's why it was uh very controversial. Also the the fact that they did it for this one hack and not for another one that involves North Korea u was also very controversial. And these two ca or these two examples actually I want to illustrate my point of you do need layer security but you also need to have a balance between the fallbacks that you implement your social layer and your credible neutrality because you don't want to undermine the very premise of why why decentraliz decentralized systems and networks exist

and why they came about. um the main premise is actually censorship resistance. So if you throw out credible neutrality and you're just going to control your system, there are better ways to do that, you know, and better and more efficient ways. There's databases. We've been using those for many many years. So that that's where you have to strike a balance. And I know it's very difficult sometimes because you you know I cannot condemn the the previous um teams from do doing what they did because one I wasn't in their place and two it has to be such a tremendous amount of pressure to either do things one way or the other that it's just very difficult but they both still

have a users. So if their community was fine with what they did maybe credible neutrality for them means exactly that. keeping you their community safe and that's okay. Um, I guess it could be a little bit different, but I think with uh with Ethereum, right, if you deploy there and you get hacked, more than likely there's not going to be a fork and and and that's fine. Like that's something that you're opting into, especially if you're doing um a rollup with them. But with that, I um want to go back to my takeaways. Obviously uh yes we have the capability to to communicate between chains. We have a

lot of different um ways of doing it. Some ways are continuing to be improved upon. CK proves, you know, I think once they get be faster, um, it's gonna, you know, it's they're going to be part of that as well. And they already are in some cases, but we're waiting for them to be a little bit faster. And because we already have that, I think we want we need to focus a lot on how to also handle unintended consequences of these um interoperability and composibility that we're going to be gaining as we see base rollups and native rollups and CK proofs becoming better better and better and faster and actually being

implemented for some of these. And then between the fallbacks, the social layer and the credible neutrality, I am a firm believer that um crypto is not just a technology. It is a movement and we need to be able to to hold or or to to stand for for that ethos because ultimately I know that a lot of people don't care when things are going well but when things don't go well this is this is technology that is absolutely necessary and you don't want to um say you know if you can do this for you and you can be choosing winners and losers then there's no reason why a state actor

can come and ask you to do something for them. And I think that that's it's imperative that we give that the importance that it needs to be given. And with that, I'll take any questions if you guys have any. Thank you so much. Yes. Let's go for questions. Right. No questions. I don't see ends. No.

Oh, there's one here. So, what was the biggest challenge from you guys moving them deploying contracts on different chains to having your own chain and people staking on your chain but still connected to all the others? Is there any challenge you guys are facing in this new model versus the older model? Um I'm I'm I'm thinking like I guess it's a very big optimization for us. Um I guess the biggest challenge is actually the risk that every other chain

is facing especially when you're a smaller a smaller chain. it's the the risk the cost of attack is lower right so that 33% um it's lower than a 33% of like Ethereum network so that is definitely going to be a challenge and that's why I think it's also important that we have all of those layers of security but most importantly that we admit it because I think that a lot of the industry has just gone uh through uh we've gone through a lot DeFi and we continue to go through DeFi hacks that involve generally a flash loan um and then you know some asset manipulation

and liquidations and then they run away with the money and we don't have all of these these things in place for people to to be able to have better guard rails and it for their own users. So um yeah in terms of if of of us I think it just made it so much easier. I I don't think that that's the biggest thing is the the security within the 30 the that 33% and 66% and that's something that we're all facing and I think as you see more app chains pop up um we're all going to be facing these uh yeah different scenarios or assumptions in security maybe base rollups and all of that fixes everything but until

they're here we're going to have to work with what we have. Yeah.