Welcome to East to E to E to E to E. Wonderful. Up next, we have Bianca talking about the builder's guide to using oracles. Thank you. All right.
Thank you very much. Hi everyone. Hope you enjoy the first day of the conference. I definitely did. This is my second uh IDAM and I always come here with uh great pleasure.
Today we will be talking about the builder's guide to choosing oracles. Oops, this is a bit low. So basically my goal for this session is that you walk away with a clear understanding and a clear framework on how to assess different Oracle solutions. Before we do that, a few words about uh myself. So my name is Bianca Buzz.
I'm head of deell at Chronicle. The team at Chronicle is the team behind the very first oracle on Ethereum uh back at Maker Dao in 2017. In 2023, it spun out of Maker Dao and since then it continues to power Maker Dao as long um as well as other protocols and ecosystems in the web free space. Now I have a little story uh that I would like to share uh with you and uh I want to tell you today the story of Niko. Nikico is a DeFi builder and he wants to build a lending protocol.
So essentially he wants like people to be able to come deposit some collateral in some tokens and then take a loan against uh that. Now you might wonder okay what are the different considerations that Nico should have in mind when he wants to create these uh lending protocols and I'm going to give you a spoiler there a lot uh one such consideration is the liquidity he needs to make sure that the protocol will have enough liquidity for users another considerations are gas fees this is important because it shouldn't be prohibitive uh for people um the the gas fees shouldn't be prohibitive uh for users. Then he needs to decide on the chain which chain does he wants uh his protocol to live on. Maybe he can use um several chains and in order uh to choose the chain he's going to probably assess the gas fees. He's going to assess the ecosystem the the competition on that chain and so on.
There are a lot of different uh things that uh needs to be decided. Similarly, uh incentives. He needs to make sure that there are proper incentives both for depositors but also for borrowers. And to wrap things up, he needs to make sure that there is a great user experience for uh his users when they use the the protocol. And these are only some of the considerations when building such a uh DeFi um app.
But it's finally launch day and Nikico and his team, they made it. They succeeded. Everyone is happy. And now after so many nights when he's been working uh on his protocol, he's finally able to go to sleep and have some welldeserved rest. He goes to bed and he has his phone on sleep mode and he starts receiving notifications.
Initially uh some messages congratulating him for uh the launch but soon enough uh these messages start to have uh start to be mixed. Let's say by the time Nikico wakes up he realized it's wildfire out there something has gone completely uh bad. So what do you think uh Nico forgot? You're very close. he forgot to consider about oracles and the security of oracles.
So what happened basically is that Nikico's protocol uh has been subject to a flash loan attack. So basically a bad actor detected a potential v vulnerability. uh the oracle wasn't using um enough data sources for one of the assets and basically the bad actor exploited this vulnerability um artificially inflated the price of that asset then took a loan against that um asset in another uh coin and then he was able to run off with the borrowed assets while the collateral of the initial asset inevitably went down. Now I know you you're going to think like okay this is very bad this is very threatening and what are we going to do? Oracles at the end of the day are a key piece of any um any defi applications but there are some good news and the good news um is that all this could have been avoided.
It's perfectly possible to have decentralized verifiable uh Oracle setup which is reliable and that doesn't get you into trouble and let's see how does that look like but in order to to have that and in order to achieve that uh there is one extra step that every uh D5 builder should do and that's to assess the proper Oracle setup that they need and to assess the different solutions. ions oracle solutions out there. Now in my opinion opinion and a lot will agree with me. Um the bad part is that there isn't enough discussion about oracles out there. Discussions about oracles are kind of rare and personally I believe that part of the pro problem is the name itself.
You can see on the right side the definition from Miriam Webster and basically this can be quite misleading. It implies that this is an unquestionable source of truth. There's this misconception that all oracles are the same. In reality, not all oracles are equal and nor infalluable. So now that we establish this, I would like to present you a sixdimensional framework for choosing the right uh Oracle solution for your protocol.
And I want to mention from the beginning that the order you go through it's not really that important. What is really important it's uh that you go end to end for all these six steps. Okay. The first one I put over here it's uh operated operational history. So when assessing an oracle you should look for how long has the oracle been operating?
if there has been any incidents with that oracle and if you have these two if the oracle has been operating for a long time without any incidents this sort of uh longevity signals reliability so this is a good sign I put over here it's total value secured or TVs this is kind of the the golden standard if you want when it comes to oracles and it basically establishes how much what's the value secured by that oracle And here when you have like high DVS uh this means that the the oracle has been battle tested especially when you couple this with the uh previous one with the operational history. You can see on the right side uh you have a screenshot from D5 lama with top 10 oracles by TVS. So if you want to have an understanding okay what's the TVS for each of the oracles you can go there. Number three is decentralization. So the more nodes uh you have for for an oracle the the better the more robust the oracle solution it is.
But just having a bunch of nodes is not enough. You want those nodes to be run by independent validators. And also you want to have diverse data sources. And now to kind of give you an understanding what happens when you don't uh have this. For example, if you have the nodes run by one entity, let's say the team or most of the nodes, then even if the intentions are sound, a lot of things can go wrong wrong.
You can have um different mistakes uh done uh by the team, you can have then this becoming um a honeypot if you want for attacks, a source for for attacks. So, you don't want to go that uh direction. You really want to have independent distributed validators. Uh number four I put here validators or uh node operators. You can use these terms interchangeably.
So when you assess an Oracle solution, you should really look okay who is running this network. Are those trusted independence uh validators? Because uh such validators bring higher level uh of data integrity and network security. And also something uh to consider here is that if you have uh validators that have a high profile, they have an additional incentive to make sure uh that their reputation is maintained. So they want to make sure that the data they sign and they put on chain um is the right data.
Now number five, I put here data sources. So you should also look into what are the data sources that the Oracle uh network relies on. Of course, here you want uh tier one reputable data sources with established uh credibility, high liquidity, and a proven track record. Uh and something to keep in mind is that if you're using any sort of uh onchain data sources such as dexes, you want at least two of those uh data sources to be on the same chain such that you can enable the MEV bots to do arbitrage and prevent price manipulation. Also very important when we're talking about uh data sources is that we have uh traceability and transparency across data sources.
For example, in the case of Chronicle, you can see uh here the Chronicle dashboard and you can see on the dashboard all the validators. Uh you can see uh we are using reputable validators run by entities such as uh Ether Scan, Maker Dao, Block Analytica. And for each of those um you can check the data sources that they're using. Um here it's a combination of uh onchain and off-chain data sources. Now finally uh operating costs.
Oracles are gas intensive especially during periods uh with network congestion and you might think okay what what can I do? One potential solution is to lower the update frequency but you don't really want to go in that direction because you might end up with stale data. What in what instead you should do uh you should find mechanism to reduce the gas costs without compromising the data freshness. Again in the case of chronicle here to give you an example we're using signatures to bundle multiple signatures into one super signature one bigger signature and this allows us to save gas up to over 80%. Now I want to leave you with some closing thoughts.
Please keep in mind that not all oracles are equal. Please put the the effort and the due diligence if you want into the proper oracle solution. And I want to also leave you with this acronym and in order to remember the the six steps to assess an oracle node doot uh which stands for node operators, operational history, decentralization, data sources, operating costs and TVs. Thank you very much. Um, I'll be around today and uh this weekend if you have any questions about oracles or if you need support uh how to integrate an Oracle or you're considering an Oracle solution, I'm always uh more than happy to discuss with builders.
Thank you. Are there any questions for Bianca? I've got one. Um, how is there much difference between different oracles and their livveness and their freshness? Are there some oracles who are super live fresh data and some who are like our data is maybe 10 minutes old but it means that we can avoid any like flashbot price manipulations because we've got 10 minutes to kind of assess whether that behavior was nefarious.
uh you you can definitely have different uh sort of Oracle implementations and uh a lot of the time it's the user to kind of decides okay how fresh do I want the data what's the update threshold if you want so it's the user who can uh go and um implement that yeah okay so that's a parameter the user gets to interesting nice yeah thank you anybody else thank you very much really appreciate
Automatic transcript — names and jargon may be misspelled.
