Scaling Oracles for L2s and Beyond: Ensuring Secure and Efficient Cross Chain Data Feeds

Well, hello everybody, I'm Brenda, I'm one of the co-founders of Teler, and today I'm going to be talking to you about how to bring oracles to L2s and beyond. 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 aspects, the social layer, and credible neutrality. So over the last several years, we have been scaling to diversification, and we've seen a lot of ecosystems pop up, you know, we see Avalanche, we see Cosmos, we see Solana, and even Bitcoin is jumping into the game. And so as Teler, as we started seeing this trend, we wanted to make sure that we would be able to support all of this. And although we've done great strides, we still have a lot of work to do, but ultimately, we have been able to connect and do a lot of – connect a lot of chains in general.

We still need to work on interoperability, but I think it's more in optimizations than actually figuring them out. And to illustrate this point, I want to talk about this example that just happened a couple weeks ago, where a trade was executed on Ethereum on a curve pool that caused a bunch of liquidations in Avalanche. 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, the 24-hour liquidity was actually really low. Also, 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 took away their original post, blaming the Oracle, and I just said, you know, when the cost to manipulate an asset is less than the gain, this is bound to happen.

But here, we can see very clearly that the actual cross-chain 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 two choices, right? We want really fast data, but it can be more likely to be manipulated in terms of assets.

But if we wait for more robust data or aggregations or more time, then we're risking settling with sale prices. So it's this trade-off that, in the DeFi community, we know very well. And because of that, we need to continue to optimize, but also understand the implications of those optimizations and use that to also implement those layers of security. Taylor, I'm going to tell you a little bit about my story, or our story, because as 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 far along as we did. We initially started as 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 validators, our data reporters, had to be staked. And then, because the way that we would come to the official value 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 for 10% of the stake, and if they won the dispute, they would take the whole stake.

Otherwise, the data provider would get the fee for their troubles, for being wrongly accused. And so, all of this was being done on-chain. And it worked, I think, just fine when we were only in one chain. The problem that we were facing was, okay, we want to support all of these ecosystems that are emerging and all of these new chains, and 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 dispute and tip the data reporters so they would know that they needed the information.

So we had to make sure... The only way that we could explain is making sure that there was a token bridge 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 that we had 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 have to change maybe your parameters to be able to gain the same level of security as you do in other chains.

For us, that meant changing some of our variables to adjust them to the speed of the chain. So for us, one of our security aspects is the whole staking thing. And so because... And that's based... That's a function of the speed of the chain, of how quickly a new value, a new price or pricing information or whatever other information can be replaced with good data.

So if somebody provides bad data, how quickly it can be replaced. And so for us, that meant 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 our security as close to Ethereum so much because even though we could adjust these variables, at the end of the day, if there isn't a 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 an easier way to expand so no more reliance on bridges and also 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 live 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. I don't advocate for forking all the time, obviously, or, you know, that's a last resort type of thing that you may hopefully never have to do, but we wanted to have that social thread to hackers that if we need to, we will use it. Granted, we hope we never have to, but we want to. And then we gained some efficiencies and we went ahead and we created this whole other, you know, we have our own chain, our own way of coming to consensus.

But the takeaway from this is that no matter what Oracle you use and how they come to consensus, whether they're a peer-to-peer network or they have their own chain, you're not going to get away from the fact that you have all of this risk, off-chain 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 responsibility. When you have a market of something, of an asset that has really low liquidity, you're accepting that responsibility. So, you have to come up with creative ways to come up with more robust definitions for that. 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.

But with creating our own system, we came, you know, even though we gained some efficiencies, we have a social layer, we don't have to rely on the speed of Ethereum anymore to dictate how fast we can be or can't be. We do have to also take other risks. So now we have a different set of risks than before. If there is 66% malicious validators on any chain, not just on Teller or a peer-to-peer or the things that happen within it or the state that happens within the chain, 33% can probably stop, 33% plus one can stop it or can stop the chain basically. And so those risks you assume in this ecosystem where it's so diverse, anytime that you're interacting with another chain, that's something that you have to deal with.

And so aside from the risks that we already know that come with Oracle's and the external part, 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 having to, when you want to expand into all of these different ecosystems, you actually have to think about it, security in layers. So the first layer of security for any Oracle to be implemented properly, it's 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 and 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. But once you do know what you're doing and what you choose, you have to implement them properly. 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 next 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 withdrawals or limits. 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 OEB, MEV and chain congestion, that is something that you should be taking into consideration. We've all thought 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 community? OK.

So a couple of weeks ago, there was this hack, CEDOS is an exchange on SUI 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 SUI decided to ignore the attacker's transactions. And, you know, I'm not condemning or saying I'm not saying that this was right or wrong, but this is something that they were able to do. Hyper liquid is another example of a, you know, of hyper liquid taking over or making it right. Or I don't know, there's a lot of controversy on what happened in hyper liquid.

It was also an it was an asset manipulation type of hack. And then the hyper liquid team basically overwrote the Oracle information and they ended up making money off of it. And I think that's why it was very controversial. Also, the fact that they did it for this one hack and not for another one that involved North Korea was also very controversial. And these two examples, actually, what 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 decentralized systems and networks exist and why they came about.

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's where you have to strike a balance.

And I know it's very difficult sometimes because, you know, I cannot condemn the previous teams for 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 is just very difficult. But they both still have a user. So if their community was fine with what they did, maybe credible neutrality for them means exactly that, keeping their community safe. And that's OK.

I guess it could be a little bit different. But I think with Ethereum, right, if you deploy there and you get hacked, more than likely there's not going to be a fork. And that's fine. Like that's something that you're opting into, especially if you're doing a roll up with them. But with that, I want to go back to my takeaways.

Obviously, yes, we have the capability to communicate between chains. We have a lot of different ways of doing it. Some ways are continuing to be improved upon. CK proves, you know, I think once it gets faster, 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 need to focus a lot on how to also handle unintended consequences of these interoperability and composability that we're going to be gaining as we see base rollouts and native rollouts and CK proves becoming 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'm a firm believer that crypto is not just a technology, it is a movement. And we need to be able to hold or to stand 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 say, you know, if you can do this for 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 it's imperative that we give that the importance that 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. No questions. I don't know. Up here. So what was the biggest challenge from you guys moving them, deploying contracts on different chains, having your own chain and people taking 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? I'm thinking like it's a very big optimization for us. I guess the biggest challenge is actually the risk that every other chain is facing, especially when you're a smaller chain, the risk, the cost of attack is lower, right? So that 33 percent, it's lower than a 32 percent 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 through, we've gone through a lot of DeFi and we continue to go through DeFi hacks that involve generally a flash loan and then some asset manipulation and liquidations and then they run away with the money. And we don't have all of these things in place for people to be able to have better guardrails for their own users. So, yeah, in terms of us, I think it just made it so much easier. I don't think that's the biggest thing is the security within that 33 percent and 66 percent.

And that's something that we're all facing. And I think as you see more app chains pop up, we're all going to be facing these different scenarios and assumptions in security. Maybe base rollouts and all of that fixes everything. But until they're here, we're going to have to work with what we have.