 So, the accuracy of the Oracle may be off when the network is congested, and you know, the Oracle may be not as resilient, right? Maybe you don't even get enough transactions through to achieve quantum, right? And so, this really doesn't scale all that well, right? And it's pretty expensive to run. So, when you're trying to come up with something like a multi-collateral diver, you're going to have many different kinds of collateral, right? Many, many, many oracles. This kind of architecture is just not going to work. So, there's also one huge criticism that people usually give us, and it's why, if you know, we claim that these are decentralized oracles, why or can we not use on-chain price sources? You know, why aren't we using Uniswap? Why aren't we using Oasis-to-Ex? Why aren't we using Kyra? And the big reason is liquidity, right? So, off-chain liquidity is in general much, much higher than on-chain liquidity. So, it's much easier to manipulate an order book on-chain than it is to manipulate an order book off-chain, right? So, if you don't have a lot of liquidity, the order book is very thin. You can spend a very small amount of money to manipulate the price. A very kind of good story that illustrates this is, earlier this year, BitMEX effectively got played. And so, for those of you who don't know what happened, BitMEX pulls its prices by taking the average of Coinbase and Bitstamp. So, Bitstamp tends to have about six times less volume than Coinbase. So, what the attacker did was they opened the giant levered short position on BitMEX. They then bought enough BTC on Bitstamp, which crashed the price, which caused the BitMEX Oracle right to read a super low value, and I think millions and millions and millions of dollars. So, that was not good. But there's a much, much bigger problem with on-chain price sources. And that is, if you can imagine, for example, a contract, a contract can do a lot of different things. So, if you tell your contract to do a series, like a sequence of different actions, you can actually gain these on-chain price sources with very, very, very little risk. So, this leads me to a very big point that I want everyone to realize. Dex as an Oracle is a huge anti-pattern. So, effectively, an attacker can atomically execute a series of transactions in a single block to manipulate the price of Dex, and all they're going to do is pay gas fees and they take zero risk. Absolutely none. So, there's a guy called Sam CZ Sun last week who released a paper, but I was kind of really in awe. Before this paper was even published, back in February, Uniswap tweeted this about themselves, and yet people still went ahead and did it. So, you can read the attack on the tweet itself. Effectively, the attacker will just make a huge trade on Uniswap. That will either drop or raise the price. They will poke whatever thing they're trying to compromise to check the price from Uniswap. They will then use that manipulated price to do some kind of profitable action, and then in the same transaction, they'll go and they'll sell all the stuff they bought on Uniswap or sold right back. So, they effectively just lose the gas fees for that transaction as risk-free. So, in this paper that Sam CZ Sun published, effectively what he showed was that you can compromise Dex and BZX, which allowed you to, well, in Dex's case, create a huge leverage position, and BZX's case is just kind of borrowed against collateral. So, if you can make your collateral a super, super high price, then you can borrow a ton of dye that can liquidate that dye and make the profit there. And so, I'm just going to read this quote from him because he can say it a lot better than I could reword it, but effectively, at Dex and BZX, assume that Uniswap and Kyber would be a source of accurate price data. However, an accurate rate for a Dex just means that a trade can be made at that rate while an accurate rate for a DeFi project means that it's actually close to the fair market value. Okay, so let's talk about Oracle's V2. This is what we are going to be using for MCD and has been used by a couple of select partners since back in February, I believe. So, our main goals with Oracle's V2 was we want to make them scalable, we want to reduce the costs considerably, we want to make them more reliable, and we want to reduce latency. So, one of the key kind of technologies that we're using in Oracle's V2 is Secure Scalabla. So, a Secure Scalabla is a peer-to-peer gossip network. You can kind of think of it like Twitter, in a sense, where every peer is a Twitter user, and they post a message and that message goes on their feed, and anyone following that Twitter user will repost that on their feed. So, this is kind of how all these messages kind of propagate along in this gossip network. It's actually very similar to a blockchain in that everything is hash linked. So, in that sense, it's immutable. You can't go back and change a message, you can't go back and delete a message. Okay, so there's a lot of stuff on the slide, but let's take this a little bit slow. So, the feeds are no longer pushing their prices to a price feed contract, right? If you look at the two kind of sections of this, I've kind of cordoned off this off-chain process and the on-chain process. The off-chain process has gotten considerably larger, and the on-chain process has gotten considerably shorter. So, effectively, now feeds will just push their price updates to a settlement, and since the cost of that is effectively free, the feeds can now kind of push prices at a much, much lower sensitivity, right? So, the oracle is going to be much, much more accurate, because it has much, much more kind of recent data to work with. So, effectively then, relayers is a new concept. A relayer is a bot that anyone can effectively run any individual, any third party, you know, you could run a relayer. And what these relayers do is they pick a bunch of these price feed messages, and then they sort them. And then they push one transaction through the Medianizer contract. So, instead of having N feeds doing N transactions, now can have N feeds, and all you do is one transaction, no matter how many feeds you have. So, in terms of scalability, that's a huge improvement. And effectively, the way that we do this, you know, how do you make sure that these prices are legit is that the feeds are effectively using their Ethereum private key to sign the price data. So, they sign a message essentially saying, this is the price of this asset at this time. And in the Medianizer contract, you can use a Solidity function called ECRecover that will then be able to check all of that data and make sure it was signed by any legitimate feed. Another thing here is that the number of S store operations has been reduced considerably. So, for those of you who don't know, an S store is just, you know, writing a value to storage. And it's a very, very, very, yes, intensive operation. So, the less S stores you can do, the cheaper your transactions are going to be. So, we got it from scaling from two times the number of feeds to just two. And another thing I want to point out is that this architecture is fairly blockchain agnostic. So, if you look, most of the pieces are off-chain. So, if you want to import this architecture to a different blockchain, the only thing you have to do really is recreate the Medianizer contract on that other blockchain and then you just point your relayers to that other blockchain. Another thing is, since Scubblebot messages are just JSON, you can handle all kinds of data, it's not just pricing data. You can handle many, many, many more types of data. So, it's very, very dynamic. Okay, so let's talk about feeds. So, in Orville's v1, we only had one kind of feed. And we're going to label those types of feeds dark feeds. So, what dark feeds are is they're kind of these pseudonymous individuals and organizations that submit this pricing data. And, you know, one of the big criticisms we get, is why are these people anonymous? I don't know if I trust them. Is it just a bunch of maker insiders or whales or whatever? But the thing is, they need to be announced by necessity. So, if you are having public identity, it's very easy to target you. So, blackmailing you, extort you, coerce you. It's also very easy for a state actor to kind of hunt you down. By having this anonymity, you kind of protect yourself from that. But the downside here is, as we said, there's no civil resistance. You don't know if all of these feeds are actually just one person. And people seem to really distrust that kind of idea. So, what we're introducing in Orville's v2 is this concept of a light feed. So, light feed is going to be a feed that has a public identity. So, the best types of light feeds are actually going to be ones run by organizations. Because organizations are groups of people. They're much harder to kind of coerce in blackmail. They have more resources. And on top of that, they have their reputation at stake. So, in that sense, if you have a system that has much light feeds, users are going to inherently maybe trust that system more. Because, oh, so-and-so is running a light feed and I trust that. Right, this bank is running a light feed and I trust that. Coinbase is running a light feed and I trust Coinbase. And so, essentially what it comes down to is you don't want to have just dark feeds. And you don't want to have just light feeds. They both have kind of disadvantages. But there's this kind of sweet middle where this hybrid model is kind of optimal. Where you kind of preserve the hardest properties of dark feeds. But you benefit from the reputation of the light feeds. Okay, so let's talk about governance. So, in Oracle's V2, effectively governance takes over end-to-end ownership and management of every aspect of the Oracles. And so, actually, as of this morning, when I was on a flight to Osaka here, we passed four different Oracle proposals. So, as of this morning, these are all official. I can now talk to you about them without any risk of saying something that's not true. So, what we passed was, and I'll get into these a little more in a little bit, the D5 public feed proposal, the Oracle incentives restructuring proposal, the responsible Oracle migration proposal, and the Oracle team mandate proposal. So, first one, the D5 light feed proposal. Okay. So, we are going to be adding dydx, 0x, maker, set protocol, and gnosis as the first light feeds. So, that's going to be super exciting. This is just the first wave. There's going to be a bunch more. But it's really cool to have these guys on board. Okay, number two, the Oracle incentives restructuring proposal. So, we all like to talk about decentralized systems in terms of, for example, like the DAO being self-governed. But I think a key point that a lot of people miss is that these systems, if they're going to succeed, they need to be self-sustainable. So, in this diagram on the right, you kind of see this incentive kind of alignment that I've come up with. And essentially, what's going to happen is that feeds are going to be paid in die every month by maker token holders. And this is a payment for the valuable service they provide and kind of an incentive to not be a malicious fee. In turn, the Oracles are going to have a whitelist added to them. So, you need to be on the whitelist in order to access the prices. So, the data consumers are going to have to pay monthly in die to MKR token holders in order to access the Oracle prices. And so, the amount of die that's going to be paid to the fees, the amount of die that's going to be charged by MKR token holders, this is all defined by governance. So, this is not set by like the Maker Foundation. And the last proposal that I want to cover today is the responsible Oracle migration proposal. So, Oracles v1 has kind of proliferated all around DeFi. And I think that's super, super cool, right? We built something and everyone can use it and everyone's building really cool stuff on top of it. But we don't actually know how many people are actually using this thing. And it's actually kind of scary when you think about it. So, you know, some people are open about it and you can read in their documentation that they use it, right? Some people have come up to me at conferences and say, oh, you know, we're using the Oracles, but I'm sure there's dozens and dozens more that we don't know about. And so, it's kind of our responsibility to be kind of a good citizen of the ecosystem and make sure that this transition goes extremely smoothly. So, what we committed to in this proposal is that Oracles v1 is going to run in parallel with Oracle v2 until at least single collateral die is shut down. And so, that is at least six months out. So, it gives these organizations six months to kind of transition over to Oracle v2. On top of that, we're going to be giving whitelist access to the Oracles, any Oracles, any number of Oracles for free for one year. So, this makes sure that, you know, no one has the rug pulled out from under them, right? Everyone has time to transition to the new architecture, see if it's what they like, and hopefully a year from now, you know, they'll select stay on. And so, this kind of allows us to support innovation, right? It lets us still support, you know, new projects, right? That don't have any funding, right? That's just a dev, you know, at home, building something cool, right? He can still use Oracles, no problem. And if it ever turns into something, right, then there's a long-term benefit for the system. Okay, and that's all I have for you today. If you want to find out more, we have a bunch of different socials. You can find us on Twitter, our active chat, really active forum and active subreddit. Or you can come find me, always having a chat about Oracles. Okay, thank you very much.