 We're being here for building synthetic derivatives on Ethereum, just to quickly start off by introducing ourselves. My name is Allison. I'm the co-founder of UMA. I come from a traditional institutional finance background. After graduating college, I traded interest rate products at Goldman Sachs for about six years, managed a $30 billion book with $100 million. Now, ultimately decided, though, that that was just making rich people richer and wasn't particularly fun. Decided to get back to my roots in technology, joined a startup in California that did mobile lending. Still, that company is still doing great, but through that experience, I really discovered that whether I was working with big central banks or micro entrepreneurs in third world countries, the financial incentives that existed in the existing financial system just weren't aligned between different stakeholders. So I got very enchanted with all of this blockchain stuff, the idea that you could embed economic incentives into a technology and change the way that people interact with it. And so that's how I came about to get started with UMA. My co-presenter is my colleague Regina. Hi, I'm Regina. I lead our financial engineering efforts at UMA. I also came from a traditional, I'd say, finance background. So prior to joining UMA, I was a equity derivative structure at a bank. So I thought a lot about different kinds of financial products and how to structure bespoke trades for clients. Great. So first, just to tell you a little bit about what we do at UMA, we build financial infrastructure for Ethereum. And specifically, this means two things. One is a set of smart contract templates that you can use in filling different parameters to create customized financial products. The other is a decentralized Oracle service that can be used to verify and validate the payoffs associated with these financial contracts. Today, this is the loose agenda. We're going to be talking about synthetic derivatives, different types of derivatives, the market dynamics with which they trade, just a high level overview. And then we're also going to be talking about what you can actually do with UMA today. We've created basically a subset, a particular type of synthetic derivative that you can actually use and interact with, both on the Ethereum, Rink of the Testnet and Mainnet. And we're gonna talk a little bit about ways that they are both being used and could be applied to different use cases today and how you could actually extend it further. And then lastly, because all derivatives fundamentally require an on-chain Oracle, we're also going to touch on how you can actually write secure, scalable financial contracts on the blockchain that don't require a constantly live on-chain price Oracle, called the Priceless Contract Design Framework. And hopefully we'll have a little bit of time at the end for Q&A. Okay, so just to really quickly introduce synthetic derivatives here, I'm sorry if this is a little basic for some of you, but derivatives are a very, very, very flexible invention within financial products where basically you can create any arbitrary payout structure that you want based on external reference data. And so what we build at UMA is basically the smart contract templates of if this, then that logic for how different payouts should work, and then the decentralized Oracle service to validate the accuracy of this external reference. And really simplistically, if you understand betting, you really probably get derivatives. Sorry, I'm American, so I used a football example here. But these binary discrete and continuous examples here really are actually the simplest examples of derivatives that you could make. So you could create a binary derivative that's answering a yes-no question, like will the giants win their next game? If yes, pay Alice, if no, pay Bob. That really is a binary derivative. Same with discrete, where you're choosing between a discrete set of possible outcomes, like which team within the NFL is going to win the Super Bowl this year. And then there's continuous derivatives like how many rushing yards are you going to have, or what's the valuation of a given team. And just like when you're making a bet with somebody, you have to define the terms of a derivative in advance. So if you and I were to make a bet, right, in advance we'd say what size? Like $10 that the giants win their next game. We would also define the expiration, or it might be implied that the expiration is right after the next game occurs. And we'd also have to talk about the collateralization and payout terms. Do I just trust you, or are we both going to put $10 into a pot and have somebody else hold on to it? And are we talking about dollars, or die, or ETH as the payout currency? And then finally, there's the valuation function. So a really simple binary bet is really easy to understand. $10 if the giants win the next game for me, and $10 if the giants lose their next game for you. But the valuation functions can become infinitely complex or composable as well. So it could be like if the giants ever win the next, or if the giants win the next three of five, or if the giants ever win some number of games in some particular permutation of ways over the next 10 years of existence. So the thing that powers all of these synthetic derivatives is a external reference. So in the example of you and I making this bet about whether the giants are going to win the next game or not, we're kind of also implicitly, we need a way to actually reference and validate who actually won that next game. And unfortunately, when it comes to blockchain smart contracts, well they're actually quite dumb when it comes to external data. They have no way of knowing anything about the external world. And unfortunately, there's no external penalty if we encode all this logic into a smart contract, that somehow you're able to corrupt the oracle. So what we need to do is in order for us to even begin to think about building synthetic derivatives, we need a way of being able to build an honest oracle. And so the way that we've basically defined an honest oracle here is we're simply trying to create an oracle where the cost to corrupt this oracle is going to be greater than the profit. Our actual initial assertion is that any on-chain oracle can be corrupted. There's some way in which you could potentially, whether through a bribe or even hardware malfunction, cause an oracle to return bad data. So we need to make sure then that if we're going to be using an oracle to validate the payouts of a multi-billion dollar or multi-trillion dollar contract, that we have a way to guarantee that it will be on and that it will be honest. And so in the example earlier of Alice and Bob entering into a contract that has external reference data, the way that we can think about setting up these incentives is any amount of money that Alice and Bob are putting into this contract to back their bet is a potential profit that somebody could earn if they were able to corrupt the data. And the amount of money that an oracle would accept as a bribe to actually corrupt that data is kind of the potential cost of corruption. So what we need to do is to design a mechanism to keep the cost of corruption greater than the potential profit from corruption. And so it's really just three simple steps, figure out what the cost of corrupting an oracle is, figure out the potential profit somebody could make by corrupting the oracle and have this mechanism, build this mechanism and prove that it's going to work. I cut the slides with all the math, but the white paper is on our GitHub if any of you are so inclined to go and look at it. Okay. What's the GitHub story? I'm sorry? GitHub.com slash? Boom, I'm protocol. Yeah. Okay, so talking about synthetic derivatives, I gave the really high overview of how you can create arbitrary payouts and these payouts can be binary or discrete or continuous. There's also another thing to think about when it comes to synthetic derivatives and the way that they're created, which is how many counter parties are involved. So if it's just a bet between me and you, that's a bilateral trade, typically those are done peer to peer or OTC. And because it's just you and me that need to negotiate the terms of this thing, we can make it very, very customized. We can make the payout in Nike shoes if we wanted to, even though nobody else in their right mind would probably want to build out a market for trading, you know, Giants games relative to Nike shoes. So in other types of synthetic derivatives, the number of counter parties involved are way more numerous. So in some cases you have many people who want to be on one side and many people who want to be on the other side. Typically when that happens, a good example of that would be like, you know, Bitmex perpetual futures where many people are long perpetual futures on Bitmex, many people are short perpetual futures on Bitmex. And what happens in the Bitmex exchange is every single term of the contract is already standardized. And the only thing that people are negotiating when they actually trade is price and size. So it simplifies the potential terms for negotiation because everything else has been standardized and advanced. And it allows many people who are long and many people who are short to actually be able to coordinate to do a trade with each other. Generally speaking, many to many, when the counter parties are many to many, those products trade on exchanges. Then there's this kind of newish paradigm that exists in this blockchain space, which is a one to many coordination mechanism. So that could be like one smart contract to many users of the smart contract. Or what Regina is going to be talking about later is actually our first template, which is a template that lets you build synthetic tokens where there's one creator of the synthetic token facility and many users of the synthetic token that gets created from that facility. And depending on the specific dynamics of that contract that they create, that product could subsequently trade peer to peer, OTC, or on exchange, depending on how liquid the underlying product becomes. So as Allison mentioned, one of the first products or financial product templates that we've created is one of these synthetic token builders. So I'll talk a little bit more about what a synthetic asset token is, and then I'll also show you hopefully a video of how you can actually use the synthetic token builder to build your own synthetic tokens on Rinkbeat Testnet today. So a synthetic asset token is, as Allison said, a type of one to many derivative, a synthetic derivative. And what that means is that one person, such as me, could create a token facility, which is this rectangle, could create this token facility, and then mint tokens from that token facility that I can then distribute to other people to give financial risk. So in that sense, it's one to many where I'm a single token sponsor giving financial risk to many different people, all who just have to hold some token. So they don't actually have to enter any particular spoke agreement with me. All they have to do is buy a token that was created from the token facility that I created. Okay, so in that sense, a synthetic asset token looks a lot like other over-collateralized lending facilities that you might have seen. So I think this looks very similar to, for example, a maker of CDP, where in the same framework, you're depositing some collateral, and then using that collateral to back tokens that are minted and then distributing to other people. There are definitely a couple of differences, though, between this and a maker of CDP, namely that these, for example, are expiring tokens. So what happens here is if I create this token facility, I use that to create some synthetic tokens that track the price of something. And what happens is that after a certain expiration time stamp, the amount of backing collateral that backs the tokens is fixed. So it's fixed to whatever the latest price was at that point, and anyone can then redeem those tokens for the backing collateral. So it's one really big difference between this and other, you might see the perpetual lending facilities. But in some ways it is very similar, right? So you've also got these good and bad situations where, depending on what the on-chain price fee tells you the price is, you can be under over-collateralized relative to the collateralization requirements. So in the good case, the price fee tells you, okay, this is the actual price. That's how much collateral you need to have to back the tokens. You need to be over-collateralized by, say, 5% or 10%. That's where that is. And oh, great, you've got excess collateral in excess of the required collateral. In the bad case, what happens is, let's say, again, the reference price comes in at this. It says you need to have this much required collateral, but you're under-collateralized relative to that. That's fine. A penalty is assessed. That's awarded to the token holders. Anyone who holds those tokens is able to come in and redeem their tokens for the back-and-collateral plus a proportional amount of the penalty, and the whole trade is unwound. So there are two, I'd say, main differences here. One is that the tokens always have an expiry. So they have this feature where they can be redeemed for the back-and-collateral when they expire. And the second is that these token facilities are not fungible. If I create a token facility and I emit these tokens, those tokens can't be redeemed against someone else's facility. So they're non-fungible in that sense. Whereas with dye, dye is fungible, you can use dye to close out anyone's CDC. So those are two of the main differences behind the synthetic asset tokens. And I more than have to discuss some of the motivations behind why we chose to include those two features that has its whole set of design principles. But that's roughly how a synthetic asset token works. And we think this is really exciting because it means that you can use this financial contract template to create lots of different kinds of financial risk and provide that type of financial risk to lots of different people, thus enabling universal market access. So Allison will discuss some other examples of that. But first I'm going to show you that you can build your own tokens on a ring to be using this synthetic token builder. So if you're connected to the Wi-Fi, you can go to tokenbuilder.umaproject.org. And on Ring Me Testnet, you'll be able to actually follow along with hopefully the video that I'm about to show you. You just need to have Testnet ETH and Testnet dye. All right, so let me try to get this video up. Get to this website and you have Testnet, you can Testnet dye. First thing you're going to do is open a token facility. So that's actually creating that box that I showed you in the diagram before, right? So what does that mean? You're setting a bunch of parameters and then launching a smart contract. So when you launch the smart contract, it's like you're opening a new token facility. Then you're going to deposit some money into that token facility, right? And borrow tokens that are backed by some portion of that margin. So in this case, they're depositing 10,000 Testnet dye and withdrawing five tokens. So they're borrowing five tokens that are backed by the 10,000 dyes that they deposited. So I think this clip is actually 50 seconds. So really fast. And if you know what you're doing, of course it's super fast. But you should feel free to actually go in, look at the different price feeds that we've already curated for you, as well as some of the expertise that we've curated, play around with it, create your own tokens, send them to people, have Testnet financial lists, and check it out. But that's how we've basically shown you the financial engineering behind it, right? And then we've shown you an implementation or a way that people can access that type of financial engineering. Because I think essentially as a structure, I see the first kind of diagram with boxes and arrows and cash flows, it makes a lot of sense to me. But one of the really cool things about tokenizing this kind of financial risk is that it becomes very accessible. Once you have these tokens on Testnet, you can just send them to anyone and begin your financial risk that way. There's no need to hammer out a bilateral agreement between two counterparties. So that's the video. Let me close this. Was anyone able to actually get onto the token builder? Well, we tried. And for at least trying, this is the QR code for that Ethereum Galaxy game. So that was gonna be our little challenge. But feel free to scan that and then collect your star. I'm just gonna pass it around too so that Regina can move on with the presentation if you don't have it yet. Okay. I see some phones, so I will give you three seconds. Okay, and that's it. That's it, so we're moving forward. But anyway, the paper is working. I did say three seconds. So, okay, now we're gonna talk a bit more about the financial engineering behind the scenes and what that synthetic asset token really is and what it's doing. So as I mentioned before, right? In that video, what someone did was the first thing he did was he defined a couple of parameters. So he chose a price fee, he chose an expiration date, he chose a name for his tokens and then his token facility. Then he deployed the contract, right? So now we've actually got a token facility that's live on Rink v. Testnet. Then what did he do? He deposited the collateral, right? So he deposited the die. Die is the margin currency that we've chosen for this synthetic token builder at this point. But of course that's something that you can change. So you deposit die into the token facility. Then you borrow tokens that are backed by some portion of that die. Remember that you're over-collateralizing the value of the tokens that you're borrowing and so there will be at least as much die in there as the value, the die value of the tokens that you're borrowing. And then once you do that, right? That's all done by this token sponsor. So that was the position that I was saying I had before. I am a token sponsor, so I'm creating the token facility and then borrowing the tokens. And now as a token sponsor, now that I have these tokens, what I do with them, I trade them with the token holder to actually begin having a financial risk. Just raise your hand if you understand why the token sponsor doesn't have any financial risk here before this. Okay, okay, so I think that's actually, that's a really interesting data point. I'm happy to go into that in more detail later. But that's also an interesting tidbit about this kind of token facility deployment. Is that before here, before you trade them with anyone? You actually have no risk to the price speed that you're using. But in any case, sure. Yeah, good question on defining the parameters. Looks like you have a limited set of portals and some expiration dates. So how do you think about letting people create contracts and do possibility versus just launching the token to yourself, like launching like the UMA go-to? Perfect question. Allison is gonna discuss a lot of that in the next couple of sections. So yeah, so I just wanted to highlight here that the idea is someone is defining a bunch of parameters and then launching a token facility from which they borrow these tokens and then sell them. But to your point, absolutely, you can change the parameters and we would love to see people change the parameters that are currently available and include their own parameters. So what you can do is, again, if anyone can access this, this is just a link to the GitHub where all of the code that powers the synthetic token builder lives. So you could actually go there and follow along as I'm talking about this. But there's, in the code, there's a section where we define a bunch of the parameters for a token facility. And I wanna highlight three of these parameters because I think they'll probably be the most interesting to people who wanna create their own token facilities or synthetic tokens. One is this finder address. So this is basically the price feed, right, the on-chain price feed that the token price is going to track. So if I say, for example, that this address points to an on-chain price feed for the price of Bitcoin and DAI, it means that each of my synthetic asset tokens that I'm borrowing from the token facility will be backed by that number of DAI. So that's one that should be interesting. And the two other ones are the expiration date of the facility. So in the synthetic token builder in the video, you might've seen that there are a couple of pre-selected dates but you can choose other ones. And then the margin currency of the facility. So as I mentioned, right now we're using DAI on test debt but you could certainly change that to be a different margin currency that you would like. We already have some cool projects that have done things like that or are looking to do things like that. So Alison's gonna spend a bit more time talking about those projects that she's seen as well as some ideas for those of you out there who wanna build new things. So we started off by saying UMI is a decentralized financial contracts platform with a decentralized Oracle service and smart contract templates. Specifically right now the first one that we've created is the synthetic token template. And what you can do to customize and adapt the synthetic token template to your particular use case or need is first choose the reference price index. And as Regina mentioned, in the UI we had already curated a certain set of price indices that we thought the audience might find interesting. But the cool thing about derivatives is that your imagination now is really the limit. So in terms of the prices that you wanna reference you can reference cross chain assets like Bitcoin or US or whatever. Off chain assets like traditional fiat assets, gold, S&P 500, et cetera. Local currencies, so not just dollars but sterling or any local foreign exchange currency that you can think of. And then also non-tradable things. So things that aren't inherently assets or things that you can touch and buy but rather just price indices. So for example, the number of followers that CZ has on Twitter or the number of votes that a particular Reddit post has or my favorite topic, interest rates which we're gonna get into later. You can also customize your margin currency. So in the DAF UI we curated it with DAI it's just a little bit easier from a mental model perspective I think to think about things in dollars but you could also use ETH or even things like interest-bearing stable coins so that you can be even more efficient with your margin. And then once you've created your synthetic token there's a lot of different ways to actually apply them and use them. So you could go and trade them on an exchange or build an exchange around synthetic tokens. You could use them for local payments. You could, like for example if we had a synthetic yen token we could be trading yen with each other instead of trying to figure out actual cash. You could obviously interface with them through a wallet or some other sort of brokerage experience and by a brokerage experience just to differentiate that from exchange that's like how if you're buying stocks in the US or something you're probably buying them through a broker. You're buying them through like Fidelity or Robinhood or E-Trade as opposed to trading directly on the New York Stock Exchange or something like that. And then you could also look at creating funding and issuance platforms so much like the Maker CDP portal. You could actually use these token facilities to attain leverage for yourself but in this case, customize levered exposures. So just to highlight some of the use cases that we found really interesting and that we're either working with on proof of concepts or supporting in the marketplace. I talked a little bit earlier about local currencies and how they can be used for payments. There's a really interesting company called Sempo. Hi. So they're building, they basically help NGOs to give aid directly in places that have been affected by disaster. And for an aid recipient, they don't really want to think about DAI or ETH or whatever. They think about their world in their local currency but unless their local currency exists as a stable point on the blockchain, we can't actually use a blockchain-based wallet to facilitate that whole process. So what we can actually do then with this synthetic token builder is reference the price of the local currency. So like the Vaatu DAI exchange rate. And then we can margin that contract with something that has real value like DAI or CDAI, interest-bearing DAI. And then we can use the synthetic Vaatu tokens that get created in the actual wallet and payment system so that from a user experience perspective, the end user just thinks, oh, I'm moving Vaatu around. Great, like I'm familiar with that instead of having to do some sort of mental gymnastics around what the DAI to Vaatu exchange rate is. Another really cool use case. I don't know if Tom's here, but if you're building international wallets or serving international users, many of them lack access to international, traditional fiat assets. Or if they're already crypto-native, just would prefer the convenience of being able to manage all of their financial assets out of a single wallet. So what we can do is reference something like the S&P 500 or another major global stock exchange. Margin it again either in a stablecoin or an interest-bearing stablecoin depending on how capital efficient you want to be. Create these synthetic tokens that track the value of, let's say, the S&P 500 and then actually sell that to these international users that are looking to invest in US stock indices, but don't otherwise have access to it. And then the third use case is making otherwise untradable things actually become tradable. So a lot of people talk about Bitcoin dominance, right? And you can look at the Bitcoin dominance index or you could look at an altcoin dominance index, whatever it is, it's actually really, really hard to trade. There's thousands of coins. Imagine trying to actually go around and swapping those in and out and then rebalancing it in live time. You'd incur a great deal of trading costs and it's just kind of a headache. Well, what you could do instead is you could create a synthetic token that directly references the Bitcoin dominance index itself, margin it in whatever you think makes sense, and then take these subsequent tokens and trade them out. So if you're a Bitcoin maximalist, right? You could actually buy a Bitcoin dominance token or if you're an altcoin, if you wanted to short the 2017 ICO craze, you could try to create this facility and sell an altcoin dominance token to somebody else as well. On the topic of non-tradable indices, I'm gonna talk about interest rates in particular. So interest rates have this really, really interesting quality where they give you one more variable to play with. So most of the time, if you're trading something, like if you're trading Bitcoin for ETH, there's only two variables that you care about. How much am I trading and what's the price that I'm trading at? And most things kind of follow your standard 2D supply and demand curve. When you're trading interest rates, you add another variable of time. So interest rates measure the cost of renting some amount of money for a period of time. And you end up being able to basically create these 3D interest rate curves according to what the cost of renting that money is, how much money you're trying to rent, and how long you're trying to rent it for. The killer use case so far in basically all of DeFi has been within borrowing and lending. And the interest rates that are used in those borrowing and lending protocols have all just been short-term interest rates. They're more or less ignoring time and they're saying, here's the cost to rent a hundred die. And then the interest rate actually resets every time the stability fee changes or every time somebody new interacts with that compound lending pool. But if we wanted to create an interest rate market, we could actually create a market for how much it would cost to rent that specific amount of die for a defined and longer period of time. The reason why this is important is because, first of all, it's a huge, huge, huge market. If we look at the fiat world, derivatives are a $500 plus trillion market. Almost all of it is interest rates. So, and if you wanna talk about uniquely enabled use cases, these things have to be traded synthetically. There is no other way to trade time without a synthetic derivative because an interest rate is an abstract thing. You can't touch, look, see, or feel it. It's on a token. You can only trade it in the form of a derivative. And it's important actually that we are able to trade these interest rates and allow people to trade interest rate risk over time because, right now, the only reason why people are using these borrowing and lending pools in DeFi is generally for speculative and kind of not price-sensitive use cases. If I believe that ETH is going to moon next week, I don't really care if I'm borrowing at 1%, 10%, or 25%. But if you're talking about non-speculative use cases, home loan, car loan, business loan, student loan, price does matter a lot more. And the ability for borrowers and lenders to actually start offsetting their interest rate risk, the ability to lock in interest rates or speculate on interest rates is a fundamental necessity in order for these use cases to get unlocked in DeFi. So this is why we care a lot about this. There's a whole hour and a half long workshop on YouTube that you guys can find later if you want to go really deeper in. But I'm going to highlight three ways, actually, that you can create interest rate products with UMA today using the synthetic token template. And I'm not saying that the synthetic token template is necessarily the way that it should be created or the way that it necessarily will exist forever and ever and ever. But these are actually three different ways that you can actually create them today that would give us price discovery and insight into how this market could evolve. And so these three are kind of a simplified version of Dan Robinson's why tokens. SUMA, which is a project that came out of ETH Boston, and then fixed rate tokens, which is more or less something that I made up. So to dive into these. So how many of you have read the why token paper? Okay, okay, cool. So the way that basically why tokens work is you're trying to create a yield curve for what the ETH dollar funding rate looks like over time. So how much money will it cost? Or sorry, how much will it cost for me to borrow dollars against my ETH for different periods of time? That's what a yield curve for ETH dollar would be. And that's what the motivation is for creating why tokens is. The way that it would work is you take the UMA synthetic token template, you make the reference price index, the price of dollar ETH. So it's just one divided by the price of ETH. You use ETH as the margin currency. And you basically just say that every token I borrow will pay out one dollar at expiration. If the price of ETH goes up, it's less ETH. And if the price of ETH goes down, it's more ETH. It's always one dollar worth of ETH at expiration. And so effectively it's sort of like what you've created there is an expiring stable coin. From the token sponsor's perspective, if they were to create this product, create this token facility and borrow tokens against it, it would enable them to get levered ETH exposure. Kind of a similar reason to why anybody might open up a MakerDAO CDP or something like that. But the difference is that the way that they would get this exposure would be with a fixed interest rate over the lifetime of that token facility. From a token holder's perspective, they get to own a token that they can redeem for one dollar at expiration. And they're buying it for less than one dollar initially. Free money, right? But basically it's kind of like interest, it's an interest-bearing token, interest-bearing stable coin, but kind of different from CDI. And if we have a market for this, what we could do is observe the market price for these Y tokens that have different expiration dates and use that market price to calculate back into what the implied funding rate for ETH dollar is for different periods of time. So you could create a Y token that expires in three months, a Y token that expires in six months, and a Y token that expires in one year. They would all have different prices. And based on that price, you could get an implied interest rate. Based on that implied interest rate, you'd be able to build out a yield curve, and then you'd have better visibility into what the market expects the ETH dollar funding rate to look like over periods of time. Right now, all we know is that what the Maker stability fee is today. We don't know what it'll be next week, we don't know what it'll be next month, and it's actually quite hard to figure out what expectations are. If any of you have ever been on any of those governance calls, there's quite a bit of debate. This would actually give them more insight into what the market already naturally expects the interest rate to be over different periods of time. Another way to create this is through summa tokens where basically the reference price index is 100 minus the expected stability fee that you would pay between two fixed dates. So let's say the two fixed dates are January 1st to December 31st, and what we're referencing is what the market expects the stability fee to be on average between Jan 1 and D31, and then we take 100 minus that. So the price of this thing would generally always be less than 100. The reason why somebody might actually want to do this is if they wanted to really directly speculate on what the expectation of interest rates are over time. So the token sponsor would make money if rates increase. Effectively, a token sponsor could use this if they were a borrower, and they were worried that interest rates were going to increase, and so they could create these summa tokens in order to match off the P&L there. From a summa holder's perspective, they make money if rates decline. It's kind of like a lender who wants to lock in their interest rate today because they think interest rates are really high and they're going to go down in the future. And same deal, we can look at the market implied price and it'll reveal information about what the market expects the interest rate to finally be in the future. Final version is a fixed rate token. It's just kind of like summa tokens, but a little bit simplified. You just directly reference an expectation of what an interest rate will be between two fixed dates and you tokenize it. So if I say between Jan 1 and D31, the expected interest rate is 10%. Every token, so the interest on a 100-dialone would be 10-dial, then the token would be redeemed for 10-dial at expiration. And then you can directly trade these fixed rate tokens between each other. So every token is effectively the variable interest rate that you expect the MakerDAO system to cost you on a $100 loan over those two fixed dates. To kind of summarize what will be covered there with all these different use cases, synthetic products are highly composable within the DeFi and general Ethereum universe. And the innovation can kind of occur at many different levels. The innovation can occur at the price index level where you can just make up basically or reference arbitrary price indices. The financial engineering level, basically the interaction between the price index and the margin currency and the payout structure that you're creating, or even at the application layer. So how you're delivering the product to the user and what's new or unique or different or special about the way that you're delivering that product. And synthetics are really great because they offer the features of leverage, support for cross-chain off-chain non-tradable assets. And this ability for synthetics to enable risk transfer for things that were previously not tradable is critical for developing markets like interest rate markets where we can start to think about supporting non-speculated use cases. And so Regina is now going to talk about how you can actually build contract templates, not necessarily just the synthetic token one that we already have, but other contract templates that are safe, secure, and scalable. The fundamentals, as great as synthetics are, at a fundamental level, they all require an oracle. And on-chain price feeds are expensive. They are hard to maintain, they're dangerous. A number of DeFi projects out there all do use oracles and many of them have had oracles that have actually failed at some point or the other. And so we actually believe that it's going to be really hard for DeFi to actually scale at a global and large size without a secure oracle, but we believe that the right way to actually build these contracts that need an external price reference is actually to minimize the use of on-chain oracles at all. And so Regina's going to talk about our framework for writing templates that fulfill this. I want to emphasize one more time that the topic of this workshop is building synthetic derivatives. So what we mean by synthetic is specifically this, that the financial risk that you have on-chain comes from an external price feed, comes from a reference asset that the derivative is referring to rather than any sort of physical token that's being borrowed or lent to a chief leverage. I just want to emphasize that very, very clearly because I think the rest of this talk is going to be about getting rid of those price feeds. And so I want to make sure that we're on a chance that synthetic derivatives are all about referencing an asset and they have nothing to do with actually physically borrowing or lending anything to get leverage. So on that note, we talked about the token facility and how there is a certain price that comes in from this price feed that tells you how much collateral you need to have to actually fully back the tokens and then again what your collateralization requirement is. So based off of this one price feed that's being pushed into this token facility, we know both the price of the amount of backing collateral and the amount of required collateral. So we have these two things. Then we just do a check to see if you have sufficient collateral to meet those requirements. And so depending on what price, the price feed pushes, you know that you're either in this state or in this state. And once you're in this state, you know that, OK, great. This penalty is assessed. And that all gets paid out to the token holders and people get to redeem. So this is how probably most people think of synthetic derivatives. I'd say, in fact, this has a lot of analogies to how fiat works and how synthetic derivatives are settled in fiat. So if this is our existing framework for how we margin and trade and settle synthetic derivatives, we've got a lot of dependency on this price feed. And that's why these price feeds are so expensive. We pay a lot for them in the fiat world. And of course, as Allison has been talking about with the Oracle, they're corruptible. So if I expand to make a lot of money by, say, maybe from this penalty, maybe it's really in my favor to crop this price feed so I can recoup the penalty. Or so that I can really reduce the amount of money that token holders get, I might want to crop this price feed. There are a lot of reasons that in fiat especially, this is susceptible. And in fiat, there are a lot of reasons why this is really expensive. So I'd say it's funny because in fiat, it's expensive from a dollar cost perspective. And in fiat, it's also expensive from a computation and keeping things alive on chain perspective. We are talking a lot about corruptible Oracle. Is there any legal framework to basically put some liability for the price feeds in the current business? In fiat? In traditional business? Yeah, so in traditional finance, I think, there might be, I would say the more conventional way that we've addressed this issue in fiat is we hire a lot of people to look at prices and confirm that the prices that are being sent from one custodian to the other custodian are correct. But if somebody will lie, then we can undo the things, right? And yeah, that's another thing that you can do in fiat is that you can undo these transactions. So you can hire people to go back and move money back from certain accounts to others. We should be able to backport this feature. I know it's not fully fast, let's say, automated, but no, this is the world we are living in, like, the life that happened. I think that's a little bit out of scope for this presentation, but happy to discuss later. OK, so as I mentioned before, right? In that picture, we've got these price feeds that are regularly pushing prices to smart contracts. So one way to visualize this is to say, OK, we've got this price feed that runs that someone has to maintain. It's an unverified price feed here in the sense that I'm going to say it's just something that's been piped in from, say, Bloomberg onto the blockchain. Maybe we're using some service that ensures that it's not been corrupted from Bloomberg on its way to the blockchain, but it's unverified in the sense that if it comes out incorrect from Bloomberg, we don't really have a solution. So here we've got some price feeds that's regularly pushing prices to this smart contract at, say, frequent 15-minute price updates. So the question is, how do you provide prices so quickly from a decentralized, economically-guaranteed Oracle? So that's the big question that we're trying to answer, right? We want these prices to come frequently so that we can liquidate people when they need to be liquidated. But we also need enough time to actually have, I guess, in the fiat world to have humans look at prices and check to make sure that they're correct. So how do we address this problem? And there are two options that we're currently seeing in DeFi. The first is you can implement a delay at the Oracle level. So what you can do is you can say, we're still going to get prices every 15 minutes. But each of those prices is going to be delayed by an hour. So the price you get at 1 PM is actually the price from 12 PM. So 1 PM in blockchain time or real-world time corresponds to a price of 12 clock. So you're basically giving people a one-hour delay before the price from 12 o'clock hits the blockchain at 1 o'clock. One thing that's really cool is this looks kind of like how settlement works in fiat. So right now, if you trade stocks, let's say in your brokerage account, as Allison mentioned, you get filled at a certain price and you know that you got executed at, say, the price from 12 o'clock. But the stock doesn't actually arrive at your custodian until, say, two business days later. So you don't physically have it or you don't have that record implemented until that time. So in that way, it's a lot like this kind of mechanism where you've got this price that's delayed then hitting the blockchain at a later time and then you actually move tokens or collateral at 1 PM to correspond to the 12 PM price. So that's one option. One of the challenges with this, though, is it puts everyone on the same clock. So this isn't great because let's say you've got a lot of different smart contracts that all depend on the same price. And this is fine, but it means that let's say you've got some contracts that have a small amount of money and you're okay having it be updated every 15 minutes. You don't need the one hour delay. It's not that much money at risk, like I'd be happy without it. But let's say you also have some contracts that have a lot of money and you really, really care about making sure those prices are right. Well, it works, but it puts everyone on the same clock. So maybe not ideal. Another option is you can implement the delay at the smart contract level. So what you can say is, right, so again, the price is coming in exactly at one o'clock this time. Then what we say, that's fine. We recognize that price on chain, but we're gonna move margin at two o'clock. So here it's just like the picture I had before, but instead of implementing the delay at the oracle level, we're implementing it at the smart contract level. But still, again, it looks, still like sentiment if you ought, it still looks like the option from before. The only difference is, do we implement the delay when we're moving margin, or do we implement the delay when the price is coming on chain? Requires fewer oracle calls in the sense that you don't have, for example, here, right? Like you don't have this one hour delay, so it's a little bit less oracle intensive, but you still have the problem if you just put a one hour delay somewhere, whether it's at this level oracle. Can you say again, what's the benefit of the delay? So the benefit of the delay is if you have, for example, a price that you're seeing in the real world at 12 o'clock, it gives time for us all to agree that that price for 12 o'clock was the correct price. And when I say us all to agree, I mean, physically for human analysts to look at it and confirm, oh, that makes sense, the price of the S&P is not 200, right? And so it gives people a chance to review that. So as you can see, both of these options are doable. Certainly they have been implemented, but they're not great. You still have this whole settlement issue, you still have unverified price feeds. So what I'm going to propose is instead of pushing prices to smart contracts, let's let the projects just pull them when they need them, right? So instead of having all of these prices pushed onto the smart contract, why not have a smart contract that says, okay, I don't need to know the price right now because everything's going fine, there are no liquidations, I don't think there should be any liquidations, it's fine, right? So we're here, everything's going fine. Then when you see in this DeFi smart contract that there's something that would require a price, say, oh hey, like I think there should be a liquidation here, why not let them just raise that as an issue? I'm going to call that a dispute in this picture, but raise that as an issue and then let an oracle handle it then. This concept I think is one of the most important things in designing like financial contracts that are compatible with an oracle. Is this movement away from a push mentality into a pull mentality? So as you can see here right here, we're moving away from having someone push prices into a smart contract and just letting the smart contract pull prices from, in this case, a decentralized economically guaranteed oracle and just pull those prices when it needs them. Great. How does it know if it needs to know? It doesn't know what the underlying price is. Great question. The smart contract doesn't know what the price is, right, because the smart contract hasn't actually pulled for a price. It doesn't know. It doesn't know if you should be liquidated. When we've got a bunch of human beings interacting or I guess like other robots in interacting with these smart contracts and they can do the work of saying, oh, based on my assumption of what the price is right now, I don't think there should be a liquidation. So I don't need to raise a dispute to make that smart contract pull a price down. What I can do is I can say, well, it looks fine to me because I can see off chain that, oh, like I look at the price on Bloomberg, it looks fine. I think that these should not be liquidated. I'm okay, I don't need to pull a price. So I'm basically saying that the human beings or the other robots interacting with a smart contract are looking at that smart contract and saying, I don't need to go pull a price right now. I'm letting them decide when, okay, there's actually a situation where someone's actually in default, someone needs to be disputed, someone needs to be liquidated. At that time, there needs to be an issue that's raised to another power. And I can say, okay, you're correct, you're right and said liquidated. I'm now going to give you the final verdict on what that price is. Are you worried about DOS attacks? Great question. I actually think it's a really great technical question that, oh, sorry, are we worried about DOS attacks? Great question. Our team has done some thinking on that. I will put you in touch with if those people after this. So I want to get through the rest of these slides because I do want to mention this in the context of synthetic tokens, which I hope will be helpful in understanding the framework more than having to take questions after this and then outside. Cool. So I talked about this framework, right? Now let's talk about how you might apply them to the synthetic tokens that we were just talking about because in the synthetic tokens before, right, there still was that problem of, okay, well, we've got these on-chain price fields so our team is really hard to put on-chain, but those are still profitable and potentially could cause liquidations when there shouldn't be. So how do we make these synthetic tokens in the price list framework? I kind of mentioned this in my answer to that, and that's questions that I took it, but here's what you could do, right? You've got a token facility. You know there's backing collateral in it and you know that there's some amount of total collateral. So I can see this information. I can see this information kind of, but what I really can see is the total collateral. And then, I'm sorry, I'm saying I is the token holder, right? So I'm someone who holds a token that was issued from here. What I can say is I see the total collateral. When I look outside of testnet, I look and I say, oh, okay, Bloomberg is telling me this price. Based on that information, I can say, well, that looks okay, he's got enough collateral that if that price were to be pulled onto the blockchain right now, and it really were that price, there would be no issue. This person would have enough backing collateral. They would have enough to meet the required collateral. These question marks would turn into checks. And so what I can do as a token holder is say, this looks fine. I don't need you to pull in a price. I don't need you to pull that data and perform a very expensive check to make sure that everyone agrees on the price. This looks fine, I'm happy with it. The token sponsor is free right now to keep depositing or withdrawing margin from their token facility. They're free to keep doing this because no one's disputed his position. But if something were to happen, let's say I look off chain on the token holder, I look off chain and the price actually looks really, really high. And I think to myself, hmm, the total collateral actually is lower than the required collateral. There should be more collateral in here, right? That's an issue. So why is this spread, right? That's an issue. So what should I do? I should say, that looks wrong. DVM help us resolve this dispute. Raise this issue to, as I was saying before, the other power, this DVM. Raise this issue to them and say, hey, we need you to pull a price on chain now. We need you to come and resolve this dispute because I think this guy is undercollaboralized. You need to help us resolve that issue. And that's why UMA is building a DVM. To help answer that question, right? To say, hi, how can I help in this situation, right? So we've got these two scenarios, right? In the happy path, in the happy scenario, this is going on. No one needs to pull an expensive price on chain. Token sponsors are free to deposit and withdraw with no delay. Well, with some delay, I'll go into the delay in a bit, but they're free to deposit and withdraw. In the unhappy path, in the unhappy case, well, we've frozen the margin in here while this DVM, the DVM stands for data verification mechanism, but while this dispute resolution process takes place, we freeze the margin and someone else does that work of pulling that price on chain. So what does that mean for a smart contract? If you're building a smart contract that intends to use this framework, what additional considerations do you need to have? The way it works is your smart contract, right? Remember, this is the token facility from before that was deployed in the ring fee test net. This token facility needs to consistently pay these continuous taxes. So what we have in this picture is they're paying taxes regularly to this UMA store contract. So you've got a token facility that's paying these taxes and that helps ensure that going back to Alice's statement about the Oracle, it helps ensure that the cost of corruption is higher than the profit from corruption. Because what this is doing is it's saying these taxes are going to make the cost of corruption higher. And once you've done that, right, once you've created a token facility that's up to date on its taxes, that's paid the correct amount of taxes, it gives them the ability to later call the DVM when they leave it. So what you can do is you can say, well, as the UMA's DVM, as the Oracle, I say, well, great, this token facility has paid its taxes regularly. Now that they need to raise a dispute, I'm more than happy to assist. When they do that, right, the token facility requests the price on chain to pull it in to resolve the dispute. It generates an answer, and then you as the smart contract can go in and retrieve the price from that Oracle, right? So to recap what we've discussed so far, actually, I guess this is all of it, but to recap what we've discussed, we started out this conversation talking about on chain price feeds and financial contract templates, right? We started out talking about how with these and with our synthetic token builder contract, with the synthetic asset token contract, all the different kinds of things you can do with that. Allison gave like six or nine examples of things that you can build with that and more, and we would love, love, love to hear other things that you wanna do with these things and how you might use them in different applications. So if you have ideas about that, please, please talk to Allison, because we're thinking a lot about how you can use these templates to make cool tools for other projects. Then from there, we talked about how you could deploy these financial contracts with new parameters. So we talked about how if you change, for example, the price feed or you change the expiration date or the margin currency, you can make new things that go into those applications. Matt Rice, who's our lead engineer, he's sitting here and can help with anyone who has questions about how to do that from a technical perspective. And then we ended this conversation with how you can use, you can kind of skip these on-chain price feeds and build things that rely on oracles or these kinds of backup oracles like UMIS-DVM and how you can design different types of financial products in that way. And so if you wanna talk about that more, please find me. So that's kind of what we've discussed so far. More than happy to take questions now and have additional conversations. Cool. Is there a mic we should use or should they just yell? I think just yell. Just yell, okay. Can you explain in more details how taxes from the contract to the UMA will help to keep the oracle known? Sure, sure. So the basic idea of how the oracle works is that when the oracle is requested, the price is requested from the oracle, okay, when a price is requested from the oracle, the oracle then goes out to a bunch of people or I'm saying this very colloquially, but it goes out to a bunch of people and says, tell us what you think the correct price should be. Those people then submit their answers for oh, I think the price should be this and they also have some balance of voting tokens. So those voting tokens influence or determine how much influence they have over the correct, the final price that's returned to the smart contract. So it's basically if you own more voting tokens, you have more of a say in what the right price is. The taxes that I was describing before those go to do a token buybacks. So those increase the cost of corruption because now those tokens have gone to increase the price of the tokens. So if you wanna go and bribe the oracle, you need to go out and buy more voting tokens, but those voting tokens are now expensive. That's the cost of corruption. So the only way to get that voting tokens is from taxes which were paid or I can get it somewhere else. If I want to vote on prices for the oracle, I can go out and buy the voting token, but the price at which I have to buy the voting token is influenced, of course, by the buybacks. To those voting tokens, you're probably gonna get used when you get to the back of the token because otherwise it wouldn't really be a cost, right? Because you buy the asset, you vote, but then you get the asset back. I'll let Matt, Matt take that one. If the token burned, they get, the idea is that if the price is ever wrong, the value of those voting tokens goes to zero because you've effectively cropped the systems and they're worthless because you don't expect them to use the system in the future. So the voting tokens, you don't burn them. The idea is that you're holding them. So if you were to do something bad, the value you're holding will go to zero. So that's the economic incentive. I'm having a lot of trouble understanding the value of what you're doing. I think what you're doing is you're replacing the human driven system that you currently have and the defects that we have with another hybrid human driven system that continues to have latency and continues to have the problem of moderation and acceleration. If you can show me how we deal with the latency of settlement and the problems for white human vibration, then I'd love what you're dealing with. Right now I'm having a lot of trouble understanding why this is better than what we have. Okay, that's more an statement. So I think that in some ways there are a lot of corollaries to the fiat world, right? But like when you and I enter into a contract in the regular fiat world, we're abiding by the terms of the contract because we know there's external consequences if we fail. We know that you can take me to court, you can sue me, potentially if I did something really bad, somebody could send me to jail, right? In the blockchain land, there is no such thing. So this horrible that we built is basically a primitive that allows us to create an economic incentive to be able to get some of this off-chain data on chain and be able to verify things so that we can do more with our smart contracts that we otherwise would not be able to do because in this blockchain global world, there is no external jail, there is no external single global court system that we can all arbitrate to. And there's what we want, there's what we want in monitoring the information. This is sort of that full event so that we can state what happens since then to a good extent. Great, so on the first question, let's say you're right, so let's say someone misses a situation where, so let's say in that diagram, in that diagram, right? So there was a situation where initially you were here and then we got here and no one called the pull for a price. There were two outcomes, right? One is the next time someone does call for a price, we're still here. So eventually it gets caught just not by the first person. The second case is that by the time someone's come in to say, oh, hey, something looks off, we're back here. In which case what's happened is you've given someone that kind of like optionality, right? It's saying, oh, well, oh, I know I'm under collateralized but I'm just gonna hope that no one calls to pull for a price. I think that's a very valid concern but the hope is that with lots of different voting token or voting with lots of different voters or with lots of different counterparties in a system that has like more liquidity that people will be monitoring that stuff. And I would say actually one of the cool things about potentially the way that this ecosystem grows is that we eventually have third parties that are incentivized to watch for this kind of stuff and pull for those kinds of price feeds or pull those prices because they've got some kind of economic incentive to do so. So I think there are lots of ways that this could be built in the future and have like different add-on features. Yeah, so all of the systems that you're describing I assume would still like in whatever jurisdiction they're operating with existing jurisprudence would apply. And I'm wondering how much research you guys have already put into the types of legal contracts that would be needed to enable someone to operate with these kinds of systems, right? Yeah, so pretty complicated because every country kind of has their own set of rules. The first thing to kind of understand is that sadly there's a lot of ambiguity when it comes to this stuff actually not just because of the blockchain aspect but just in general, the definition of a derivative and the definition of a security is not always super clear. And it really depends on the specific facts and circumstances of what you're trying to create. So if for example you're using a non-security as the, if you're using something that's not a security as collateral like ETH and you're using something that's not a security as the reference price index like the price of Bitcoin and you don't have very high leverage, then it's unclear these products depending on jurisdiction could be classified as a derivative or a loan or a hybrid instrument but certainly not a security. Alternatively, if you use a reference price index that absolutely is a security like the price of Apple stock or if you're using a margin currency that absolutely is a security like some sort of an STO thing then yeah, like that would probably be subject to securities regulations. But it always depends on the precise combination of things that you're trying to do. So every one of these UMA contracts has its own scope and then when you went through the demo, it had like the data plus the trackable spot away plus all the other stuff. How does the UX work with this when you have thousands of different tokens? How does this interoperate with the existing exchange? It's like this isn't gonna work on uniswap products. It's like how does this be a scale as you have one more token? Great question. I think again, there are like two different ways that this could evolve and probably more. One way that I can see it evolving is we do more financial engineering work on making those tokens fungible between different contracts that have the same parameters. We've done some thinking about how you could implement that and decided not to launch our initial version with those additional features because they seem very, very complicated but it's possible to make a system where all of those things are fungible. I mean, DAI is one example of something where they are fungible. And the second is depending on the way that that marketplace for synthetic token looks in the future, potentially we could have lots of different individual token sponsors who then create tokens and sell them to individuals but depending on the way that the ecosystem looks in the future, you could imagine a scenario where there actually is one big token sponsor and maybe that one big token sponsor is actually some collection of individuals who've pooled their risks of how, right? There's so many ways that this could grow and change that I think definitely the first thing I mentioned with financial engineering is one thing, the composability with other ways to pool risk is another. Lastly, maybe there is like UX solution that works better. So I think there are lots of different ways that this could go and I'd be more than happy to continue that conversation. Have you considered this from a, I mean, obviously you have, but like, do you think this would work from a parametric insurance perspective where you just have an event and you get to pay off if there's no rain or if there's too much rain? Can you repeat the question? Yeah, so your question is about parametric insurance? Yeah, or just insurance in general where you have an event and there's gonna be a payout or not because I mean, it's essentially the same logic. Just a different price feed. So yes, asterisk with some caveats. So I think the biggest issue with binary payouts on chain is the question of margining. So if you want like a million dollar insurance policy, like I get a million dollars if the rain is really bad this year, then the only way to do it really safely is to put the full million dollars into that contract from day one and then have an oracle that tells you whether it rained really badly this year or not. But that's really, really capital inefficient and most insurance products don't actually work that way. Generally when you buy a million dollar insurance policy from a normal fiat insurance provider, they're only putting up a small amount of money, a small fraction of that million dollars and they don't have to put the full million dollars up front. Otherwise they wouldn't be able to write as many policies as they do in the fiat world. So I think this is an area where at least for right now and the way that we thought about writing insurance on the blockchain, that it would probably be less competitive to the fiat alternative. I mean, you do have catastrophe bonds where you basically have, at least as I understand them, you have all of the money in government bonds and then as an investor, you just take the risk that you get to return and all your money goes away if the event happens. But those in- Can you repeat the question please? I want to hear you say what you think. I was just saying there are catastrophe bonds where you put all the money up front. There's a kind of bond where you put all the money up front and it disappears if a bad event happens, but I'm not actually sure how popular they are. Yeah, and there's actually still embedded leverage in those in the way that they work in the fiat world that doesn't really translate easily into blockchain land. Okay. If you're collateralized and you know you're gonna probably, or you have a dispute, you see that the contract is gonna fail after a couple of minutes, what is probably having this immediate pricing? When you started the presentation, you started by saying that Uber is a very expensive or those price providers can be very expensive and I agree with you, but depending on the magnitude of the pricing, this can also be insignificant. It's really in their business, right? So my question is more like about the oracles. What if you would have like five, six different oracles for every derivative front page? You have at least where this pricing is coming from if it's gonna be from the central bank or from Thompson Reuters or Bloomberg at this specific time. So my question would be, is this whole mechanism about forgetting about the price provider or not trusting the price provider because 100% of the financial services just trust Bloomberg as the price provider? So I think that when we were saying expensive, we actually meant expensive in a number of different ways. So expensive is expensive in terms of actually purchasing the data and getting a license with Bloomberg or whoever for that data, but there's also expense with running your off-chain servers, running the DevOps effectively between your off-chain server and your on-chain communication, paying the gas fees, and then also all of the coordination cost amongst anybody who's participating in a contract like the centralized version, so BitMEX for example, they just decide what their XBT index is and when they decided that Bitfinex wasn't good enough or when they want to tweak their algorithm, they just make that decision unilaterally and they change the way they calculate the price index, they hook up the new APIs, they do all that stuff. But in this blockchain decentralized land if you don't want a single point of authority in that way to make those decisions, but you similarly have thousands of people who are long and thousands of people who are short in a single smart contract, how can you actually do that effectively? Just as an oracle, maybe the oracle must be like a centralized already established trustworthy body, like a Bloomberg or a Thomson, writers who are in the central bank, the price is coming from the authorities. So I mean it depends I think on your use case and where and why you're willing to accept that centralization, but again, even if you are willing to accept Thomson Reuters as the source of truth and you're willing to say I'm gonna go with that price, things still happen. You still get NAN, you still get zero, you get flash crashes where they go back and break the price and in a smart contract world where everybody's kind of self-custiding their own coins, well if you're using that NAN or the zero price from Thomson Reuters, the coins are already moved, that's a very, very bad you know when you're under collateralized like before, like you see the price in the real world and then you're like oops, right. And so in this system, right, before the coins can actually move, you go to a decentralized verification mechanism to actually validate that this price is the right price rather than just directly and done way using it. So what prevents the voters in the oracle from shorting the voting token and dropping the cost of the transaction zero? So in the case that you're able to use boomer tech construct, also some interesting proof is one proof is that you can surely get constructed is something that will allow me to short the price of the voting token and therefore drop my cost of transaction zero and want pretty much any thing. There's actually potentially an even easier way to do that, which is if these tokens were on some sort of a lending protocol and they were being lent out in massive size, you could simply borrow the tokens, take no price risk yourself, use the tokens to vote, create lots of bad prices that break every contract and then make out like a bandit. So, huge problem. We'll be really interesting to see how that evolves, but that's why the initial conditions of the token distribution actually matter a great deal and why it's really important that you have a really highly engaged voter community. So as a rational rumor token holder, as a rational stakeholder, I should never lend these out. Or if I ever observed that there is a meaningful portion of these being lent out, then I should not, I should no longer own these tokens. But in a market where you, you know, and you've got hundreds of billions or billions of dollars locked up in these phone banks and then suddenly someone does that to sign it, screw it, I'm not a voter, but I'm gonna create a derivative that will allow me to short the token. Coordination requires us to get everyone to basically exit their contracts before something that happens is just not correct. But you need somebody on the other side who's willing to go levered long. So if you wanna short a trillion dollars worth of these Zuma tokens, you gotta find somebody who's willing to go a trillion dollars long. So in that discovery process, it will impact the market, there will be signal to the market that this is happening and so that it should not happen. It would be irrational for that to happen. But isn't the payout dependent on how much value is locked inside these contracts? So I mean, for example, if the group was worth a lot more, then let's just say it's all on the capital, it's about a million dollars. Like, do you still have that risk right now? So that's actually the system that we've built where if you have, let's say, a hundred million dollars of margin locked inside of smart contracts that are referencing the Zuma oracle, then the Zuma tokens must be worth at least a hundred million dollars or the value of the voting tokens actually must be worth at least a hundred million dollars in order to prevent a civil attack. So that's actually why we have that dynamic tax rate that Regina talked about earlier. So if we ever observe that the value of the tokens is too low for the system to be guaranteed to be economically safe because there's so much margin in the system, we would actually implement the tax on the system and use that tax to buy and burn tokens until the market cap got high enough again. And so what is the tax pay then, like what we call collateral? Because every contract has different collateral, right? Yeah, every contract has potentially different collateral and the acceptable collateral is a governance parameter of the system. So you wouldn't be able to just use some random altcoin that nobody actually knows what the value is. Please take your stuff with you. Don't leave it here before you leave. We still have more time for more questions. I'm going to leave this up so that you at least you guys know who we are and come find us later. It seems to me that like looking for sort of holistic data, don't make sure that by using the whole model, you're kind of diffusing the risk to external parties that are not on hand. And I'm wondering if there are some ways that the risk potential is difficult to quantify when that happens because now we're thinking on a sufficient level of market players and a sufficient amount of market activity to catch those empty spaces where we do need to invoke some kind of a, I forget what you called it. A dispute? A dispute, yeah. And whereas there might be things where you're just not noticing things are happening because your contact is essentially rarely getting data, right? So I'm just curious if you've thought about this more and maybe there's some things being missed here. Yeah, I think one of the key takeaways is just economic incentives drive the world, right? And so within months of Make It Out, for example, releasing their reference implementation of the Keeper Code, somebody had already improved it and their original code was being beat every single time and they haven't yet had a failed liquidation. So similarly, we didn't go into it explicitly here but a portion of the penalty actually is basically paid out to the caller of the dispute. And so we economically incentivize people to actually go and dispute in addition to just saying like everybody takes some responsibility for it because like you kind of should. Yeah, I mean, it's very wise I find it that any whole versus push mechanism is just an element more element, right? So really to admire that and just think on that and possibly new challenges. Yeah, definitely. I think also standardization is important. So I think if you've had a billion smart contracts and a billion different ways to devolve them and if you had to write a separate EPI for each of them or whatever to actually be the Keeper in that system, it would be very hard. So I think the key part of building these sorts of systems and making them successful is making sure that there's a standard way to quickly look through all the contracts and make sure there are no disputes across the models. So for instance, if you had 10 maker doubts, you'd all have the same EPI, so the same Keeper code would work for all of them. So one person can earn one system and monitor 100,000 smart contracts easily. That's the idea. How would you say your Oracle solution that there's from other solutions that they're all good or like Chainlink or some of these other systems? How would you say there's these kinds of unique and how is it sort of around the financial engineering or do the derivatives part of it? Yeah, so I think the UMA system is very different from systems like Chainlink because what Chainlink is effectively doing is taking the programmatic API data and then making it such that rather than having a single node reporting on it, you have multiple nodes reporting on it. We're similar to Augur in that we both use a Shelling Point game to incentivize the recording of like honest reporting, but we're different in the implementation details, specifically that Augur has to have a designated reporter initially rather than our system, we're actually using the entire network for reporting and also Augur's markets are done in natural language, which is beneficial for some things and that you can do more but really harmful for other things and that a lot of markets resolve invalid. In UMA system, the price requests are standardized, so there's just a simple identifier. My question is related to the scale of this argument system. It is a whole system which of course requires much less information and points of information than as you illustrated, regular interval, but still if you need a specific action, it's more like it's not even bold, maybe it's more like an order. You ask the market for something, then some action happens in response to that order. So you cannot have like 50 arguments use the same information or a thousand arguments use the same information as you would have if you just regularly push data from the blockchain and then the different information would just pull that one piece of information because they are all doing contracts on gold, for example. But in your case, you would have an action request each time there's a need for something. Did I understand that correctly? Yeah, and I would say that's actually feature not a bug because it prevents parasitic usage. It prevents? Parasitic usage, so it ensures then that if there's lots of contracts that would like to use our Oracle, well in order to use it and have the Oracle be used for them, they've got to be paying their taxes. They can't just observe what other contracts are getting. Pat, how much more time do we have? I just... Just do have five minutes more. Perfect. So I keep thinking about the legal framework. Would it make sense in your opinion to really anchor the users on the system to a legal agreement? Anchor the users to a legal agreement? Yeah, make a legal agreement between the users of the tokens with the sponsors and the Oracle code. That would be something that could happen at the application layer if that was a desired feature, but not a built-in feature of this. Are you planning to build it? The legal? Nah. Why not? There's over a hundred countries. In many countries, in fact, yes, and the financial instrument will be considered as a security, so if you seek for adoption, Yeah, so I think that that, again, is just something that needs to be handled at the application layer and not the protocol layer. So under this due resolution process, one thing that kind of occurred to me is that you not only need to be able to then query your Oracle to find out what the current price is and see whether there's a discrepancy in a significant gap there, but you also need to, at least I'm asking, do you need to then query a certain amount of historical data to verify that this upside down, I don't know what you call the state and the derivative, or is it not under-collateralized? Yeah, it was under-collateralized. Whether the state has occurred in the recent past, but this view generally is saying like something happened here, but it might not be in that state anymore. So I assume you have to kind of go back a ways and say, like, you can tell them not to study them. It pursues them, because now it's going to follow us. So the point you call this view, you say, you're basically saying, contract is bad right now, and we take a time stamp and yeah, it's going to take some time to resolve, but you hear out the price exactly at that time stamp when this view is called, and you freeze all the parts in the contract, so basically the contract waits to see if it was under-collateralized at that exact point in time. Right, and the price at that exact point. So you're saying that there is no support for some kind of domino effect that would have occurred if you had caught it at that historical point in time, but you no longer caught it. You're no longer in that state. Correct, there is, I would say no support. I'd say like, it depends on how you design your financial contract or the employee to be Oracle, but ideally it should be more of a, it should be more, things are a lot simpler if you do present value, it's kind of complicated if you would say, I wanted to group us like 10 prices, and I want to like check all these kind of arbitrary points because time is continuous, and you can provide it, and there are all sorts of complications. But also like, all our Oracle does is says, it returns, what is the price of this thing at this time? If you wanted your contract to be complicated, you could request some sort of a slightly historical price. I mean, there's limitations to how historically you can go, and then you can design your contract for that domino effect if you wanted it to. We didn't make that design decision, but you could. Well, one challenge about this is that by using it this way, you, sorry, I lost my friend, so I might come back now. I want to ask about the Uma Oracle's incentive moment, because most of the costs of the Oracle's is the collateral that they need to have in order to secure the, basically, the operation, and the fact that now we work in the form of, instead of push, means that they get much less fees, it's still the need to hold the same collateral. So someone needs to pay for the fact that they, they're operating and they stake the cost to protect their operation. So one way to think about, like, a much voting token holder's incentives is basically compensating them for the work that they're doing of providing these prices, and compensating them for the opportunity cost of holding onto these tokens rather than selling these tokens and buying something else that could be productive or more yielding or something like that. And when you actually do the math, which is in our white paper, you can basically think of it, the value of these tokens as being a discounted cash flow, a discounted cash flow series of all future expected dividend payments. And there's kind of different stages for what a token holder would expect over different periods of the ecosystem's growth. So at steady state, which is kind of like where Fiat derivatives are right now, Fiat derivatives have been around $500 trillion of notional volume for the last 10 or 20 years. So at a steady state in the boomer ecosystem, the desired compensation for boomer token holders is pretty much simply just the yields that they want to be earning on their assets. Whatever that target yield might be, it might be a function of the environment, it might be a function of how much work they have to do, et cetera. But you can think about what those assumptions might be, you can look at traditional stocks and what the dividend yields are for those things and come to some number, like if an UMA token holder might demand a 5% annualized yield or a 10% annualized yield and then back that into what the taxes would look like on the financial contract users. And it's actually quite reasonable. So back at the envelope back tells us that something like a 50-racist point annualized tax on these financial contract templates on just the margin, which is an even smaller percentage of notional would be sufficient to compensate UMA token holders and still earn them a healthy yield. A little bit about the roadmap and the current usage. I see you're bluntly into Ethereum, but are your blockchain agnostic as a protocol? And then the second question is regarding test net, meaning that any water people basically building that you have seen on the past six months, maybe a year from now ago is basically only interest rates, more effects. It's a dye versus what are the actual projects that are coming using the protocol? Sure, so the synthetic token template, that financial contract template, it's both deployed on main net and test net. The main net implementation is referencing a centralized protocol. So it was really just to test proof of concepts of different applications and use cases. Earlier this year, a market maker used it to create a US stock index token so that anybody who owned crypto could also get exposure to US stocks. We ended up deprecating that. And now we're working with other proof of concepts around, I think I mentioned currencies earlier, there's a different stock thing that we're working on now with a different application layer provider. Those are coming out later this year or next. On the decentralized Oracle side, our biggest internal priority is to get that onto main net later this year or early next year. Right now it's still in private alpha testing. And your final question. Is it a blockchain agnostic? Blockchain, theoretically yes. Is it more of an Ethereum ERC? Theoretically yes, but practically speaking, the Ethereum community is pretty magical and I think DeFi composability and standardization is a huge component of what gives this stuff value. So until or unless other blockchains actually have that type of community where these applications really make sense, it doesn't make sense to trade them and deploy elsewhere. So during your talk, you sort of showed how a lot of projects are relying on some 15-minute tool, let's say, of price feeds that are being pushed to the chain. If you have a lot of these, why wouldn't they sort of band together and batch as in lots of 15 minutes and then kind of degrades to just one price feed and you can actually end up with a lot more value buying in Oracle than it's being paid in taxes. Only to double up. If someone's just created the Oracle last five minutes, I probably don't need to create it again and I can avoid the tax. Yeah, yeah. So what you are, the question you're asking about is basically what Augur calls parasitic usage, right? And maybe, do you wanna talk about? Yeah, I mean, we have quite a few ideas about how to deal with this, but the rough idea is that we don't want to be able to do that, we want you. So we have these designs for like, basically whitelisting contracts in some ways based on their byte code, making sure they kind of follow the rules to allow them into our system. And it's a little bit technical how we prevent contracts from getting around those whitelists by just reading the chain data, basically proving this data exists in a smart contract and reading it that way. But it's a little more, like we can talk offline, it's more of a breeze. I mean, the summary is kind of just fuzzing so that you can't directly read outputs, but it's all fuzz, that's private information. Yeah, we do payouts rather than playing prices. So you don't say the price is $5, you say this person gets $7, this person gets $3, and that way it's unique to the contract and not everybody can use that because it's specific to that particular contract. If you want a price, you have to press seven. Show me if you can, I'll take one. Last question. Okay. Can you talk a little bit more about how they're underlying that expiry? So like, I've got these tokens and like a thousand people have bought them and they're not inspired. They need to go and pull their underlying out of the contract right now. How does that work? What is the trajectory of that? That's a great question. I think there is like a challenge of how do you broadcast all token holders that's time to redeem the tokens. And ideally they know that they should go back and redeem for the underlying throttle. Again, a lot of different solutions I'm gonna throw out there. One is that you could have the wallets be in charge of that, right? So for your wallet to support these kinds of tokens, like you're able to go back and read what is the expiration date and notify your users, right? That's one way. The other way is in our synthetic token build or DAB we have right now it's geared really towards token sponsors, right? Because it shows you what your collateralization is and what you should deposit or withdraw. Again, that could turn into a portal that all token holders use as well and those token sponsors, a lot of different answers. But we definitely love to collaborate on different types of projects if you're interested in building that kind of functionality. I mean, ultimately I would say the kind of the solutions that we've envisioned all currently live at the application layer not the protocol layer. So we're building this infrastructure and we'd love to, if you have ideas about how we can support at the protocol level we'd love to hear them otherwise. Okay. I think we're gonna end here but with lovefish hat outside and later on comment. Thank you.