Oracles Demystified: Models, Mechanisms, and Design Choices

Hello everyone. Today we have Bianca with us. Uh she's working at Chronicle and is also the founder of Devil Uni. Uh where she builds a community of devil professionals. And uh in this talk, Bianca will walk us through a framework that can help you in choosing or in deciding what oracle you want to use for your onchain projects.

And then uh besides the evaluation based on various criteria, she will also give advice I think on how to design a robust architecture around oracles. But before passing the mic to Bianca, I'll ask Simona to step in and maybe give a few details about the Kush conference and uh the opportunity to uh receive a ticket discount. So Simona. All right. Cool.

Thank you for the introduction, Alex. Um, so yes, as Alex has well pointed out, uh, we have set up a po as you probably you guys are familiar by now, we've started this initiative in the beginning of the year which is called road to ethl. So this is um an initiative meant to create anticipation and gather as many interested people as possible for our conference event which is end of June 26 to 28 this year. Uh what we're aiming with this is try to get people uh familiar with Ethereum technical um content as well. Uh gather as many people who are curious about this who want to join the conference and give them the the opportunity to to join with discounted tickets as well.

So, uh, at the end of the session, I'm going to share with you guys, um, QR code that everybody can mint and this comes with the 25% discount to conference tickets. And of course, you can accumulate that up to a free ticket. So, yeah, looking forward to having as many of you as as possible. And without further ado, I'm just going to pass the mic over to Bianca. Bianca, thank you so much for taking the time to joining us and sharing a bit of your knowledge.

Uh, you know, you're a super uh, knowledgeable person in terms of Oracle. So, please, you have the floor. Thank you. Thank you so much for the kind introduction, Simona, and hi everyone. Um, just checking I'm audible and my the screen sharing is fine, right?

Uh, yeah. So, thank you for for joining my my name is uh Bianca. I'm going to tell you a bit more in a second about myself. But kind of the uh the idea behind this uh workshop is to kind of give you an overview on what are oracles, why are oracles so important, why we should spend a bit more time as builders uh when it comes to choosing the the right oracles. And uh I would like to say that uh we are a cozy group here.

Um and I would love for you to ask any questions. Stop me um if you have any questions. I have to I would love to have a conversation rather to to have this uh as a lecture style. So yeah, please um stop me and ask any questions. Okay.

So a few words about uh myself. Uh my name is Bianca. I work at currently at Chronicle. This is the the team uh that built the very first Oracle in 2017. Used to be part of Maker Dow.

Then in 2023, it spun out of uh Maker Dow and since then it continues to power Maker Dow as well as um other protocols and projects in the web free ecosystem. In terms of um agenda for today, first I would love to to cover a bit a bit of an introduction on oracles. Then we're going to look at how to evaluate an oracles and what are the different uh oracle types as there uh then um we're going to have a a brief introduction on chronicle and then I would love to invite you to to see how easily you can uh get values from uh on an oracle. So, we're gonna have a bit of a um demo session, hands-on session if you want. Okay.

I see there are some something in the chat. Okay. All good. Yeah. So, I'm sure most of you are familiar with oracles, but for anyone that might want uh an introduction on oracles, I I like to make this analogy with uh mobile phones.

I think it's quite easy to understand if you're thinking about your mobile phone. Your mobile phone is powerful because it allows you to interact with uh different applications. But in order to interact with all these different application, there is an exchange of information. However, when you're thinking when you on board on a plane and you put your phone on plane mode, uh all of the sudden you you lose this transfer of information and your phone becomes pretty much useless. If you think you can't do much with a with a phone on uh plane mode, similar to that, if you're thinking about blockchains, uh blockchains are kind of a sandbox by themselves.

They don't know anything about the outside world. But in order to have meaningful applications, for example, in order to have DeFi applications, you need it um real world uh data and we're using oracles to kind of bridge and uh feed smart contracts and defy applications with this real world um data. So this is kind of a very high level description of um oracles. Now I would like to ask you uh I would like to to go a bit about what are the different considerations when um building an application and I'm sure uh some of you here are are builders and even if you're not um a builder maybe uh you're working on the product side or maybe you're interacting in other forms uh with your with the project I I just I would love to hear from you what are you considering when building u a let's say you want to build a defi application anyone's brave enough to to give it a go hey one question is it depends on what you would consider to build decentralizing would be leadership and or pop-up cities or you could build build a financial tool that's decentralized You could be building a a play to earn kind of game. Okay, let's say a lending protocol or some DeFi application to to make it more concrete.

We could consider the the chain uh the assets that you want to build with the gas is for the chain for sure. Um also where the niche is. If you're targeting big money probably you'll be layer one if not layer two um and so on. Technology it's also a chain consideration so that would be another you tell us you tell us more. Thank you so much Robert those are all spot on.

Anyone else wants to add something before I I reveal what I have on the slides? Some uh nonfunctional stuff like security and probably um optimization gas cost of the app. Um okay the place yeah but this also goes into the chain where where's there where there's enough liquidity you want to build your product on. Awesome. Thank you so much.

You you guys guessed um probably almost all all my all everything I had over here. So you need to find to think about about the chain which chain um on which chain your application will leave probably you're going to consider the gas fees not to be prohibitive for users to uh to use your application the user experience what else I put here the incentives you can think here both the incentives for the lending protocol itself for for the user for the uh borrowers and lenders but also when it comes to incentives different ecosystem when it comes to choosing building on ecosystem A versus ecosystem B liquidity as Alex said here and so on. There are many many considerations but unfortunately people forget to think about oracles and this kind of goes to my um initial presentation on on oracles. This is kind of a second thought. People usually assume, okay, I I I have all these choices to make.

Oracles are kind of a second thought, unfortunately. And in my opinion, I think part of the issue is the name itself. If you look at this definition, I put the screenshot from Miriam Webster. The name itself kind of implies, okay, this is an unquestionable source of truth. And uh discussions are kind of rare about oracles.

there is this misconception that they're all the same. However, in reality, neither all oracles are equal and nor infallible or as we're going to see. So, you can see here kind of the the top three type of uh exploits when it vulnerabilities when it comes to oracles. Those are flash attacks, market manipulation, and sale prices. I'm not going to go into uh details and this is not like to shame any any protocols.

That's why I even like grayed out the the names. It's more to give you an idea that Oracle vulnerability exists and um you should really put some some thoughts when it comes to deciding uh which Oracle solution to use and what's the best uh setup for your protocol. It shouldn't be an afterthought. So with that in mind uh I want to go now uh to over the the top three oracle uh models if you want. The first one is the the push model.

This one basically proactively delivers data to the smart contracts. So basically you have a certain condition. Let's say every five minutes I want a new price or a different condition might be when the difference between the previous price and the new price is more than z.1% or whatever value you might want to have there. I want the fresh data.

This is kind of the the proactive approach if you want. Now the lazy approach are the pool oracles and the pool oracles require the smart contracts to request the data um explicitly. So in this side in this um example there is the smart contracts who who goes to the oracle and says hey Oracle give me fresh data and then the oracle goes gathers the data passes it to the smart contract and then the third uh oracle flavor I wanted to talk a bit about is the optimistic oracle and this one similar to optimistic L2s basically assumes that the data has submitted is accurate unless actively disputed. This is like this type of oracle is relevant when you're um looking for gas optimizations basically. So you have the have a certain um dispute time and during that challenge time actually it's called and during that challenge time anyone can go and can say hey this data is not correct.

If the challenger is right, the challenger receives like a reward in it. The the price which is not correct of course gets uh removed and the validator who push that price gets u removed as well. So that's kind of a a mechanism to make sure that this um that no one is cheating the system if you want. Are there any questions so far before we go to types of data? How would you uh gain trust on an oracle?

Say you are doing a request and you wait for a response from the Oracle for that request. How would you trust that data? Uh we have for example I can talk in the in the in the case of uh Chronicle I can show you the dashboard the dashboard. Let's pick an Oracle let's say Ethereum and then EUSD. So in the case of chronicle you can go on the dashboard and you can see these are the validators basically and for each of the validators you see the the different data sources that have been used.

As you can see here it's a a combination of uh onchain and offchain data sources. You can verify in the browser that the message of the validator that the signatures match. this matches but if I uh modify it even slightly uh it's not going to like it. It's going to not going to match anymore. Similar uh we have for the schnore signature.

This is the actual data that gets pushed on chain. So basically um all these validators come together they put um they they gather the data and then there is a median of those values and one of them puts that uh onchain. This is the actual data that gets uh pushed on chain and similar you can verify the signature. And this is all for push types of oracles where the multiple sources can push a value and then if the error is too uh large then probably the the result will be discarded and only the proper one will win. Right.

Exactly. That's what does Chronicle do any other types of oracles like I'm requesting the data from a smart contract and then expect to be called back with some data from Yes. Yeah. So we only have the uh the push model. This is what we we've been optimized with because we we wanted to have everything on chain with the pool model.

This is kind of the onchain offchain and you also have this uh latency if you want. So we we very much prefer the the push model. We also have like the optimistic oracles for layer one in order to help um save uh gas because on layer one it's it's more um it's more relevant the gas uh saving is more relevant than on layer 2's. Uh sure. Okay.

If there are no more questions then uh maybe we can look at uh types of uh data. When it comes types of data uh we usually see uh crypto price data. These are kind of uh the real time prices for different uh cryptocurrencies and these are the most spread if you want out there. Then you have like non-crypto price data. They might have like pricing for uh currencies for um for stocks uh commodities etc.

And then another large uh category is a testable data. And here basically we're talking about any sort of verifiable verifiable piece of uh information. So this is more in the area of real world um assets and you might have um proof of funds, proof of ownership. These are quite popular uh right now especially with the rise of um real world assets. Now uh finally I have a question would um you know this no new type of zk systems like zk mail would you consider them an oracle because basically those are cryptographic proofs that can be pushed on chain directly.

Would you consider that an oracle? like I I receive an email and based on um an um a cryptographic um operation, I can just prove that I have received it from a given person or that uh that email for example has a specific con constant attesting that uh I have gained whatever amount of money or I have been approved to uh to do something. Uh I to be honest I don't know I haven't looked uh under the hood how a ZK email works. I know it's in the ZK area but like in terms of is it a noral uh I wouldn't say so I assume does it have any sort of validators? No, it's just like a ZK proof that basically says like okay it it's true.

This is true without revealing the actual information. So I would say not because the one of the main things for an oracle one of the main um properties if you want is to have like a validated network validator network which I don't think uh they do. I I would say yes and no. They they could be perceived as an oracle as in they will tell you the truth no matter what about the specific data that you are requesting to validate. Uh they are not an oracle in the sense of well the data if if the thing that you try to verify changes then you need to redeploy your verifier and build the circuit again for that specific other function.

Um so I would say yes and no. They are oracles as in they are telling the truth always uh but only for a specific problem. So no but yes and no. I I'll look more more in um more in depth into that. But yeah uh like one of the requirements for an actual oracle is to have like multiple uh validators.

Otherwise like if you rely on one um data source that's yeah I I would totally I would totally trust the verifier of a ZK proof always. Um so in in that regard I I dis I disagree. Um you don't need multiple places or multiple entities to verify the same thing. Yeah. If you have a ZK verifier, that's true.

But at the same time, you cannot guarantee that the data would be pushed. So there is no live livveness guarantee. What uh Bianca is referring to. Yes, there's no livveness guarantee because verifier only verifies that specific function that so only works for that specific circuit and the proof build upon that circuit. Um so yeah that it's very static.

Oh so so it's both yes and no could be. Okay. So depends. Yeah. Okay.

It depends again. Um okay. So going back to the to the framework I was referring at the beginning on how to evaluate um an oracle. These are kind of the six-step uh framework for for choosing an oracle. And I want to mention that the order it's not really relevant, but it's relevant.

It's kind of to go uh through each of these steps when you're assessing an Oracle solution. So the first one I put over here is a operational history. So when it comes to an oracle, you want to see for how long has the oracle been operating, if it had any incidents and of course here the longer it has been operating like the more longevity it has uh the better it is assuming nothing bad happened. Another uh consideration is TVS or total value secure. This is also considered kind of the the golden standard, the golden metric when it comes to uh oracles.

And this is basically a value that measures how much um how much value is secured by this oracle. So you can see on the right side there is a screenshot from uh D5 Lama about the different the top 10 oracles and their TVs and of course the more TVS the oracle secures and especially if if it has been securing over a long time uh the better it is. Uh number three I put here decentralization. So what I mean by that having multiple nodes those are also called uh validators. But it's not really enough to just have like a bunch of validators.

For example, if the team uh is operating these validators even if they have like sound uh sound intents even if they want to do good uh there might be errors or they might be subject to attacks. People find out okay like we that's the the weak link if you want. So what you want actually want to have is to have like different um different entities which are reputable and of course you want to have diverse uh data sources. You don't want to rely on uh one data source um in case something goes bad you um even if something goes bad with one of the data sources your oracle shouldn't be affected by that. Number four, I put here validators also called node operators and I know I touched briefly on those but given their um importance I think they deserve a standalone section.

So basically uh when it comes to validators you want to look okay who is running the network are those uh trusted independence independent validators uh which bring higher level of data integrity and network security and of course here the more high-profile validators you have they have a reputation to maintain so basically they have an extra incentive to make sure that the data they aggregate and sign is correct. I see I see a comment in the chat ranken coin. Okay, it's a protocol also interesting that solve the same problem of onchip price fruitfulness without oracles. Okay, thank you Robert. I'm going to have a look.

Uh number five, data sources. So what are the different uh data sources that the Oracle relies on? And here we're looking for reputable data sources which have a established credibility, higher liquidity, and a proven track record. And something to keep in mind here is that if you're looking uh for onchain data sources such as decentralized exchanges, you want at least two of those data sources to have to be on the same chain such that you allow me bots to do arbitrage and then uh you prevent price manipulation. And of course here traceability you want traceability and transparency across uh data sources.

So you want the user to be able to to go and see okay which data sources have been uh used by this uh validator and by this oracle and I show you uh the dashboard in our case where you can see those data sources. I talked about this. Uh so number six very important operating cost. So oracles are gas intensive is especially during periods of uh network congestion. One solution you might think about is okay we're just going to lower the update uh frequency but then you end up with stale data.

So this is not really the the solution to go for. Instead, what should be what you should be looking for is um our mechanism to reduce gas cost but without compromising the data freshness. For example, in our case, we use signatures to kind of bundle together multiple signatures into one super signature. And because of this, we're able to achieve up to uh 80% in gas cause reduction. So these are kind this is kind of the the the framework I wanted to present and the idea that not oracles are um equal to put some proper thinking before choosing an oracle and I I'm leaving you with this acronym no d to kind of um make it easy to to remember the different um considerations when creating an oracle and this stands for node operators.

operational history, uh, decentralization, data sources, operational costs and, um, TVs. So, this was kind of the the first um section if you want of uh, this presentation. Are there any questions so far? Is there a difference from chronicle to chain link which basically does the same? Yes, actually this is covered in uh this part that I want to part number two that I want to cover.

I'm going to I'm going to save it for this part the question. If you still have a question the question after I finish this part then we we go back to it. Awesome. Um I have one. So uh you said that it's good to have so if you rely on two onchain price data sources you want to or if you rely on onchain price data sources is you want to have at least two sources.

Why uh how would you do to make sure would you just I don't know do a mean between values provided by each of the source or what would be a good tech technique to do that? Uh it's more about the idea that you want uh to enable me bots to do arbitrage. So in case of the liquidity shift in one of them that's that's the idea behind but this really it's not usually like the the oracle takes care of this but um this is something to consider you as a customer of the oracle let's say maybe you have like a you want like an oracle for a new asset and you go to the oracle it's something to keep in mind that if you're using onchain data sources you should have at least two on the same chain. Okay. Got it.

So, so it's deliberately um enabling arbitrage. Okay. Got it. Yes. That Yeah.

To prevent price manipulation. Yeah. Okay. Thanks. Anyone else?

Okay. If not then we can go to a brief overview on Chronicle that hopefully will answer Robert's question on how it differentiates from other um Oracle uh solutions out there. So as I mentioned at the beginning, Chronicle has been around since June 2017. Initially part of Maker Ding in 2023, it span out and now it continues to power maker DA now known as Sky ecosystem but also other projects in the web 3 ecosystem. Currently it secures around 10 billion of assets.

Uh it has it uses uh scribe. This is a gas efficient oracle that uses aggregated Schnore signatures. Schnore signatures have been around for a while in the web free space. They've been uh first introduced um with Bitcoin, but this is kind of the first time they're used in the context of web free oracles. Now, what sets it apart from other oracles?

ers decentralization, verifiability and scalability and I'm going to take them one by one. The first one uses a decentralized network of validators and you can see that there these are reputable protocols in the space. Other uh Oracle solutions out there this is a unique approach to uh to chronicle other Oracle solutions out there uh don't really have this. uh then verifiability you have like end to end verifiability of data and I showed you here on the on the dashboard uh basically how you can see the different validators uh the different data sources um used and the um aggregation for each of these uh this is the verifiability kind of the same process that I explained and then uh scalability because um of using signature aggregation were able to reduce up to 60% gas fees on layer 1 and 68 on layer 2. So those are kind of the the three pillars that differentiate from other Oracle solutions.

And for the last one for the scalability basically um because of this we're able to not only minimize the gas cost per update but I think what is more important here is that you are able to decouple the Oracle update uh gas cost from the number of validators. So what does it mean is that essentially you can add more validators without inflating the um gas cost per update which is very important for on Oracle network because the more validators you have the more reliable the network is. Does this answer your question Robert? Do I understand correctly that the optimization coming from is just because there are less signatures to check in a way? Yeah, basically a bunch of signatures are b bundled together.

One of the validators puts it on chain and because of that yeah technically you have like less signatures on chain because of this bundle. And how do the validators communicate coordinate with each other? There are uh they use there are two uh communication channels. Uh one is through li to li to be li to li to bit to and the other one is through chain. Isn't that centralizing?

Me as a validator must coordinate with the others so I'm not by myself. I how how would I say to someone your information is incorrect? How would I challenge that if everybody works together? So uh as um I showed you on the on the dashboard uh you have the the aggregation and then like you have the the median which basically removes uh any sort of um outliers out there and if you're referring to optimistic oracles on on layer one those have like the challenge period and anyone basically can run a challenger and if you find one such data that you think okay this data is not correct. Uh you can submit a challenge and then you have like the onchain verification.

Um and this basically compares the values and if your challenge is correct, you get a a reward. The value gets dropped and the validator gets removed permanently. So you can't really mess around here. And if it's not correct then yeah um the the the the challenge period uh finalizes and the the value the value is considered u finalized. Okay.

Okay. Demo part. The demo part. What did I get over here? [Music] Um, let's see.

Uh, if we go one second to change my screen. Okay. So if we go to the documentation portal and then uh developers you have like different uh guides different uh sections but what is probably the most interesting uh guide the the most used guide to say so is the the following consuming Oracle data and here basically it shows how to read an Oracle data we have this button to try it on remix. Of course, for production, remix um is not really a solution, but it's nice to to do such workshops and to test things out. So, basically what we're doing over here, we have a an oracle reader, a contract oracle reader.

Then we're declaring an an instance um chronicle and we're passing the address of the oracle we want to read from. So if we're going to the dashboard, where's the dashboard here to oracles and um maybe I should mention that um yeah this this is actually relevant on testnet um reading from the oracles is permissionless which means that anyone can read uh from the oracle. However on mainet you need to be uh whitelisted in in order to read from the oracle. So you need to come to us and ask hey I want access to this oracle and yeah there is a the process usually like um either the chain or the protocols pays like a fee and then they get access to the oracle. So going back to to test net which is permissionless uh for for this demo you can go to the dashboard select the chain that you want let's say Ethereum uh test net so this will be sepoleia and then we're looking at one of the price feeds let's say we want uh to know the price of bitcoin in USD we're copying the value of the oracle and we are going to uh replace it Here you can see in the comment basically u that uh this is like the address of the EQUSD.

Now I replace with Bitcoin USD. So this will be essentially Bitcoin USD and then the network is uh Sepolia. Similarly, we have like an instance here self-kisser. Um, and this is uh we have this contracts called self-kisser that basically allows users to whitelist in order to read from the oracle. So you can pass an address to the uh self kisser and the selfisser will whitelist will grant you access to that oracle.

So if we're looking at the same tutorial here on the top of the page, we have like the address of the self-kisser on different chains. And in our case, since we're on Ethereum Superolia, we will use the address on Ethereum obviously, but we already have it here just for the sake of it is the same address. And then the construction constructor in the constructor we whitelist um our address for uh this oracle for the chronical oracle that we define here and then we have a read function and the read function returns two values. The first value is the actual uh value returned by the oracle. So in our case since we put uh the Bitcoin USD oracle we will return the price of Bitcoin and the second parameter is the age.

This basically uh mentions in Unix a Unix time stamp and this represents uh the time since the last the time of the last update basically and here I just copied the I chronicle uh interface and I self kisser the the functions that are relevant. So really uh nothing complicated over there but quite easily uh we can compile and then uh we're going to use injected provider. We're gonna make sure that we select the actual smart contract, not the interface and okay. Yeah, I'm connected and I can deploy. And we should see our um Oracle reader instance over here.

And um yeah, if we read, we're going to have the two values. The first value is the value returned by um the oracle with 18 decimal places. We didn't get Bitcoin so so high. It's just like the the additional decimal places and then the the unix time stamp. So very very easy uh to do.

So maybe to to keep in mind if you're using another network, of course, make sure to get the the self kisser of that uh network instead of the seapoleia. This is like a common mistake. People forget to replace the the proper um address for that chain. And also make sure to have um a bit of uh funds on that chain for the whit listing process since it's a right operation. So it needs some a little bit of gas on that chain.

Are there any questions on this process or regarding anything else? This was kind of the the last bit of the presentation. Piana, I think there's one on on the group chat. Oh, I think so is asking like if you guess. Okay.

So, um there is this difference. So for for test basically you need like the the whitelisting process. This is just like to to enable uh the access. But for mainet and I assume your question is about mainet like what does it take in order to use an oracle there are kind of two different scenarios. Um number one scenario number one and probably the most um common one is like you have like the the oracle has some sort of partnership with the chain and then based on that partnership it enables a certain number of projects to to use the oracles for a given num given amount of time or scenario number two when there is no such partnership um in place you have like the protocols going directly to the oracle and establishing this sort of uh partnership and saying okay we want these oracles build us these oracles and this is like um the oracle then gives like a kind of a contract with okay this is what what's going to uh cost you like to have these oracles.

So in that case there is an integration fee and then yes you you pay like the gas monthly monthly gas Can anyone become a validator on Chronicle and how is that profitable? No. Let me go back to that slide at the moment and actually this is kind of a key differentiator. Uh with other Oracle providers, we only on board reputable protocols in the in the space. And the main idea is that these protocols, they're kind of staking their reputation if you want.

So basically they have uh no incentives to do something bad. FTX wanted reputation and then well everybody knows FTX. Yeah. I mean this is like one thing to have like reputable project. we we don't have FDX and we didn't have FTX but we there are also like the mechanism in the protocol itself that I explained earlier like if a if a validator tries like to push a bad price uh it get it gets detected and uh it gets removed as a validator.

This is on the technical side. So there if you want two levels of security and maybe I'm the I'm sorry sorry sorry no I was just reading the next question but maybe you go first before uh I I do put like power to the people where people can be uh the validator so the Oracle push data uh source um and maybe not all of us have the power of the ones that you listed. Um how could we the people build the trust with Chronicle to become a validator? So at the moment the the process it's only open uh for this entities like reputable projects and to kind of give you the the thought behind it is like uh first yeah this project have the reputation but then there is a when you have like individual regular um regular uh people uh running this is more uh risky like you need certain standards of um reliability. You need like to make sure that the the the validator is running uh properly and yeah it's it's harder to to coordinate this with uh with just individuals basically.

I would disagree. Again, probably lots of developers or people that know how to run services with 99.99 uptime uh could probably do as good of a job as Infura or other, but it's just me. I have a question for Robert. So, Hman.

So uh my question is okay let's say you want to decentralize it completely and make it fully um how do you see it um yeah so totally open access any anyone can become a validator what rules what mathematical rules or what type of um techniques would you use to ensure the security of data you and look at how ETH2 is doing with everybody is a validator that has 32 ETH and if you are caught cheating then you're getting slushed the same thing could be in in this situation if everybody puts in some value locks in some value saying well I I'm not going to lie and if you can show me another x amount of validators that say differently then sure I'm lying and you can slash me um otherwise how why why would I trust infury saver when you have when you have I have a small parenthesis here when you have like proof of stake or oracles then basically if if the value that if the value of the stake is less than the value secured by the oracle then if you're looking at it from a game theory perspective, you have like an incentive to okay like okay I'm going to get stash but like I'm going to get slash but then I can uh manipulate basically manipulate. Yeah, exactly. So it doesn't proof of stake uh to oracles it doesn't play very well. Well, for sure there's there's a mathematical way of uh getting them into like a better economic situation where there is no gain from misleading too much. Um so I I would say I would still say that probably a more decentralized kind of oracle would be better.

chain link does it. So what do you mean by decentral you can have like uh it's not I only put this these val here but there are more validators than this right the difference is then in chain link if the demand for some kind of oracle arises then people put in some link and anybody can choose to be the validator for that oracle knowing that everybody else would play by the rules. And if they see you cheating, then you unless you have a lot of validators that are your friends in crime, then you cannot cheat the system with with this bunch of Yes. Uh centralized services. This might be happening.

Theoretically, it indeed sounds like a solution, but you don't know what the truth is. Actually, you don't know who's cheating, who if someone is cheating or not. So, uh it's one to apply slashing to uh let's say Ethereum validators who uh can be very easily caught cheating because you just verify a signature, right? that it's something else to apply it to an number an arbitrary number like 102,000 whatever number of dollars is Bitcoin now right and what's the source its market what where's the source for example for prices do you consider Binance being a good price unis swap or for sure all of them because the market is everything uh I would say if you have a 100 decentralized uh validators of people that are doing the same kind of push of data. You have to be 51 people from those 100 to be able to slash somebody else or to lie to the system.

It powers in the numbers and of course if you have only two validators then sure if you have one is the same problem. How can you trust that data? You're on chain and you cannot verify anywhere else. Yeah. And if also you could think of if some validator is choosing to mislead with different information.

Uh the protocol or the onchain thing that is used like the lending protocol that would be using that validator would provide the necessary arbitrage for the for all the people in the market to profit out of that. um misleading data. So yeah, so it's a kind of a discussion here. Yeah. So so it's still an a problem with solutions that are evolving.

We'll see. I mean there are different Yeah. Uh there are different models out there in terms of like who is allowed to to be a validators. As I mentioned in our case it's only reputable protocols as you say robot other solutions are there have a a different approach but I think there is there is room for for both approaches. I don't think there is a one one size fits all.

Yeah for sure use multiple oracle protocols at once. For sure. Guys, just uh another question from from the chat that I think we skipped a little bit. If uh if I may. Uh so so is asking what happens if credit for protocol using the oracle runs out.

I think this kind of refers to the um the question before like okay, how do you pay for the service? Who pays for the service? um etc. uh you you get from from the beginning kind of based on the u gas costs on that chain you kind of get an estimate. Okay, like if you purchase this, this is going to last x amount of time and of course there is a um there is quite a a clear understanding of how how long uh will that um service that you purchased uh last and when you're getting like closing to the end, you're going to uh you're going to get uh like reminded by by the Oracle provider and you're going to have like a chance to decide, okay, am I keeping this uh service, am I discontinuing it?

Um, etc. So, it's not like one day like you you run out of it and boom, you you run offline. That's not going to happen. Yes, I can share the slides. I can Yeah.

Uh either way, guys, the meeting as it is recorded will be uploaded uh as customary on our YouTube channel and we're probably probably going to share it with you in the next few days. Just bear with us while we we do that. Okay. But yeah, definitely share the slides, Bianca. It's it's really good content and good information that you present here and very interesting discussions.

Yeah, thank you so much for for the questions, for the discussions, for having me and looking forward uh to the next sessions and it clue is very very exciting that the Romanian Ethereum uh scene is expanding. Thank you so much. Uh yeah, as I said before, you're always welcome in our sessions. Uh we love the content that you put out there and the effort and looking forward maybe to having you with every uni as well. I'm sure there are many people who would be very interested into learning a bit more about that.

So yeah, we'll uh we'll see. Let's keep in touch on that. Uh any more questions guys? Uh just uh a bit conscious of the time as well. If if there's more uh if there are more questions please let us know now.

If not, we can we can go to the exciting uh po that we've got prepared for you guys. So, yeah, I'm just going to walk everyone through it once once again. Uh so, we've prepared a road to eat po. This is part of our initiative which is uh aiming to encourage people to attend the meetings, be curious and ask questions and hopefully uh see seeing everyone at the seeing everyone at the conference in June. We're trying to make that easy for for everyone to attend.

So, if you I'm going to share my screen and if you'd like to to mint the PO app, this comes with also a 25% discount which can be accumulated up to a free ticket. So, let me just share my screen. Uh you let me know when you can see it. Okay. Is it all right?

Am I uh or not yet? It was visible. Okay, let's do that again. Is it working? Yes.

Yep. Cool. So everyone just take a minute uh scan the QR code for this session and in order to claim just make sure you join our telegram channel and you know like send us the proof that you have the poor po every meeting. So four po that means free ticket to eat clue. Curious to see who redeemed it first.

Nobody w uh yet redeemed it, but I I guess we're now approaching the moment where uh we expect challengers, let's say. Okay, let's take a few seconds. Let me know if uh if everyone can mint it and it's all good. If you have any trouble minting it, just, you know, let me know. Everyone's good.

Take that as a Yes. Yes. Cool. Nice. All right.

Cool. I think uh I think there's somebody in the chat who just got his fourth uh bow up, but let's see. Looking forward to seeing it on the Telegram. All right. Yep.

Cool, guys. I'm going to stop screen sharing now. [Music] And yeah, thank you again for joining us, Bianca, taking the time to chat us through what is actually been a workshop a little bit. I really enjoyed it. So u looking forward to doing that again.

I think the energy was quite cool and actually that's what that's what we want to do is uh everyone to you know pitch in and learn like hands-on right as much as possible. Thanks once again everyone for attending and looking forward to seeing you to our next sessions and to be announced soon. Thank you so much everyone. Thank you. Bye.

Bye. Thank you. Have a nice evening. Bye. Bye.