UMA’s DVM: Using Economic Guarantees to Build a Provable Honest Oracle with Hart Lambur

all right we're good to go so first of all that thing Austin did was really really cool who here was in Joey's talk on Oracle's like an hour a little bit ago okay so that'll give a little context what we're talking about we're gonna go into this concept of like economic guarantees for Oracle's and why that matters an important it is important specifically for defy applications so I'm Harlan burr our project is Uma or universal market access so start off by just giving you guys like two seconds of context for the problems we're trying to solve so the underlying mission here is really all about universal market access we really believe that financial risk and financial products should be borderless permissionless unsensible and that financial risk and financial products should move across the globe much like information does today and so the way we're going about doing that is really two interrelated components we kind of do two things that tie together the first world we're calling self-enforcing financial contract templates these are design patterns for how to create financial products I'm an example of that as synthetic tokens so synthetic token would be like an A or C 20 token that can track anything with a price feed my colleague Regina did a great workshop on that last night and you guys can come talk to us better more but separate to those financial contract templates we also have a design for an Oracle that powers those templates and gets real-world data into them and what we want to talk about today is really this concept of putting an economic guarantee around that Oracle so we can prove in a sense that it's decentralized and cannot be corrupted up profitably so a lot of what I'll kind of start out with here and please do interrupt me but I want to start out with like just the motivation about why this concept of economic guarantees is important or matters in the dphi space and it just starts out with this idea that we're working in this ecosystem where we have the potential to come up with all this really useful financial innovation but it won't matter for if the products that we build um have pay us I can get manipulated if people can distort these systems it just doesn't matter in the end and our big starting premise here is that any on chain Oracle anything in this permissionless pseudo anonymous world can be corrupted so it's actually useful to go back and be like okay why is this not a problem in in the real world in the fiat world and that's because we have this really useful concept of laws against fraud and manipulation and bribery and also that kind of stuff so if I go and try to bribe a contract I go to jail and this toy example we'll use for a lot of our talking we got Alice and Bob here and let's just suppose that they enter into a bet there it's a million dollar bet where they both deposit five hundred grand and this bed is gonna pay out according to an external reference the external reference here is what we're calling our Oracle turns out right like if Bob could go and bribe this Oracle to say that he's right regardless of whether he's right or wrong and in that case he can steal Alice's five hundred grand but of course if Bob does this in the fiat world he goes to jail it's as simple as that so his cost of doing so are really very high but in the blockchain world we don't have this concept of fraud it's totally okay for us to actually hack the system and so Bob can go ahead and bribe this Oracle and it's completely okay so this becomes a really big problem at scale if you take this example you know of Bob and Alice having this 1 million dollar contract where Bob could make 500 grand if he corrupts the Oracle you can imagine where Bob just scales that up and he just keeps entering into these contracts and now he's got a two and a half million dollar incentive if he enters into five contracts he's got now a two and a half million dollar incentive to go and bribe the Oracle and he could keep scaling this with as many contracts as he can enter into so there's a large large incentive here for Bob to break or hack the system and ultimately this is our whole concept of why economic guarantees matter for these unchain Oracle's all right so to state this a bit more formally in this permissionless blockchain like aetherium private economic incentives end up being the only tool we have to incentivize behavior we don't have fiat world laws we can't don't send people to jail for bribery so we need to build an Oracle system such that defied contracts can prove there is no profitable way there is no economic incentive to corrupt this system and we really look at this as like it's useful to think about the extreme case is if we're gonna have trillions of dollars of value in decentralized finance on aetherium we need to solve this problem within the dphi context of how we're gonna keep these systems secure okay so that's kind of the motivation in context for how we're framing the problem and actually it's important even go back to kind of what Joe is talking about earlier we are looking at this problem specifically within the defy context this isn't like a generalized Oracle problem we're not like we're not answering necessarily like how much rain there is or stuff like that this is really related to financial applications well it can go into more on that later so let's formally define this problem we define this concept of this cost of corruption profit from corruption framework and so we define our cost of corruption as the minimum bribe you need to pay to corrupt the Oracle so if I could pay a million bucks to corrupt this this Oracle system that's my cost of corruption separately there is this concept of a profit of corruption which is the configuration of the universe where I could extract the most profit if I were to corrupt the Oracle and then it follows right that what we're really looking to do here to create a system where there's no economic incentive to break this Oracle we want to build a system where the cost of corruption is always greater than our our profit from corruption this this this inequality right here so just to kind of get our semantics right in this toy example of this million dollar contract between Bob and Alice on the profit from corruption would be how much you could steal out of the contract if Bob and Alice both put in five hundred grand the most they could steal would be this father and grand number separately our cost of corruption is whatever it whatever the minimum bribe we'd have to pay to corrupt this Oracle system so cool we'll get into like a little bit of math but the high-level outline of how we're going to tackle this problem is just to chunk it up and break it down into the three steps we really need to do to prove that inequality so let's create a system to measure this cost of corruption let's create a system measure the profitable corruption and let's then define a mechanism to keep this inequality in check so going into you a few more sentences of detail on those three steps and how they work and then we're gonna dive deeper on all of them our core Oracle design is it is a shelling point style voting system Joey mentioned selling points tiles a bit ago it's a showing points tell voting system but where there is a voting right so voters get asked to vote on outcomes their votes are weighted by their voting stake by how many vote tokens they have these Bo tokens are freely tradable the token holders are paid a reward for voting correctly and they're charged a penalty if they don't vote or don't vote correctly the theory behind this is it looks a lot like 51% attack in proof-of-work as long as 51% of voters are honest they will vote honestly and the system will resolve truthfully cool second point how do we measure the total value we're securing the total profit from corruption well very simply we can do this analysis pretty easily any individual contract that goes back and if we look at Bob and Alice's contract we can figure out how much money could get stolen if somebody were to corrupt that system so what we're gonna do is we're gonna design an infrastructure where all contracts that are secured by this Oracle report their own individual profit from corruption number and we can do a worst-case analysis by summing all those values together the last point is probably most interesting thing which is then how we go about creating taining this inequality where we keep the costs of corrupting the system greater than the total total profit you could make and this go we do this with what we're calling a variable fee policy and the theory the thinking right is if the cost of corruption is what a much greater than our profit corruption if that inequality is like really very true or there's a big gap there we're safe our system is secure we don't have to do anything but as the cost of corruption approaches the floor as it looks like the that inequality is getting threatened we levy an increasing fee on the users of the system on the contracts that are using the system and we use that fee to buy and burn the voting tokens to support the floor and because we do this programmatically we have this very nice feedback loop where we maintain our floor price based off this credible commitment to tax the users of the system with this variable fee to enforce this floor it's probably the coolest most interesting aspect what we're doing we'll go into more detail on that in a couple slides okay so the math is pretty simple we don't need to go in too much detail on it but I just want to give some math on how we measure actually measure our cost of corruption so simply because these voting rights are freely tradable and because in order to control the the the Oracle you need to control 51% of the participating supply we can actually use the market use wherever these voting rights are trading in the in the free market to calculate the cost it would take to corrupt the system so here our math we have this added parameter ADA which is just the percentage of non participating tokens because we can't assume all voters will participate but if you if you for simplicity if you pretend that that's zero that everybody participates effectively the cost of corruption is whatever it takes to buy or control half of the voting supply separately on our profit from corruption the the key thinking here is just what I sort of detailed earlier where for any individual contract it's relatively trivial for us to look at an individual contract and be like okay if I could control the auricle inputs to this contract here's how much money I can steal so the way the system is designed is all contracts using the oracle implemented interface where they report that profit from corruption back to the system as a whole and then we are able to do a worst case analysis by summing that value across all contracts in the system um there are some interesting questions here which we've a time to get into now of course man where we can get into how we prevent unauthorized access to the system or what's commonly called parasitic usage we'll see if we have time for that okay so if you take the two results from these last few slides our our cost of corruption and our profit of corruption and we plug them into the inequality and move things around we can actually define like a floor price in our token in the voting token it needs to be maintained for the system you secure and again if you kind of take the ADA parameter of non-participation and for simplicity you say it's everyone's participating so it goes to zero it means that we need the market cap of our voting token supply to be equal to twice the value it's securing and that's so simply put let's say we're securing 50 million dollars of value in the system it needs to cost more than 50 million dollars to buy 51% of the voting tokens or it needs to cost 100 million bucks the market cap of the voting token needs to 100 million to secure the 50 million dollars and that's actually like the kind of simplest math of round this idea of an economic guarantee in our white paper which we'll talk about at the end we add in a concept of like a safe floor that's a little bit above the absolute floor to put in a bit of buffer so if you do read the white paper and you're wondering what the difference is that's why that piece safe number exists so now it goes into kind of the okay wait you guys say you're gonna maintain this floor how do you actually go about doing that and it all stems from the fact that aetherium and block chains let us immutably program logic that like will absolutely run we have this incredibly commit to what is effectively a taxation policy or our fee policy here and so what we're able to do is every voting period basically every cycle of the system which we're parameterizing to be like roughly a day we run through this logic where we calculate what price what floor price we're trying to maintain for our token we observe and measure that floor price and if that floor price is below if the current price is below the level that we need to maintain we levy fees on the contracts using the system we take that fee revenue we buy and burn the voting token to support the fee and we repeat and the thing that's kind of super fascinating about this is because it's all immutably programmed in the logic of our system it also means third party speculators have an incentive to come in here and actually do this work for us so a third party speculator when they see the voting token approaching the floor they have an asymmetric risk ward trade where if they were to buy this voting token at the floor they know they can sell it to the buy and burn mechanism but they have unlimited upside so you know we got to see how this all works in practice but in theory there should be a strong incentive for third party speculators to actually enforce the floor for us based on the logic that's immutably red in our system yeah that's a great question so what is in the code we've written and we'll get in later like kind of where we are the status of this thing and the code we've written we are programmatically collecting the fees how those fees are being spent we have not written programmatically in the system yet because the kind of defy and where you source liquidity has been changing so rapidly you could imagine a number of options for how we would programmatically do this how are you it once the fees are collected how do we actually do that by and burn do we do an auction do we buy them on something like you know swap there's a series of other like ways we could do it the simplest most centralized way to start is that you entrust a foundation so the foundation doesn't get to choose how much fees they collect but once the fees are collected perhaps you can entrust a foundation to actually go and execute that buyback on your behalf that might be where we start but I think very quickly we'll get into using you know swap or an auction mechanism and on a an auction mechanism to do is buy and burn yeah I probably want to talk to you more offline and that where my mind goes on that is that if if an attacker comes and buys up a bunch of tokens he's gonna push the price up himself so I'd have to think like we think through the scenarios of like where that yeah exactly it's like a yeah exactly so I that's a bit of fun edge would be a fun thing to think through of course yeah so I guess there's video here too the question is like is the user experience for for fees how does that user experience look right and so there's a bunch of implementation kind of decisions here about how you could go about doing this remember that the types of contracts that we think the system is securing are usually over collateralized so if you do charge fees you're taking it out of their excess margin their excess collateralization so because of that the experience should be kind of like not costly or not age shouldn't be that bad it shouldn't impose action on the user you're right though if like but like there's sort of edge cases that need to be considered more fully if you were to impose an action on a user and then you push them below their collateralization threshold that'd be a bad experience so I think there's also other designs where the fees can be collected kind of lazily and if contracts or participants in the system choose to not pay their fees they may run the risk of being locked out of being able to use the Oracle system so there's other stuff like that that could sort of solve that usability constraint of course so yeah guys ok other other nerdy with some cool math but it's really not that hard um what we actually have for this token mechanism is a model for what the the fundamental value of our token should be so what what this is really saying this math is saying this actually looks a lot like a discounted cash flow model that we can use to to look at what the fundamental value of a stalker so if you think of a low dividend paying stock like Amazon you know awhile ago it was something where theoretically what Amazon should be valued at is the present discounted value of all the markets expected future dividends for that stock similarly what's interesting about our design is that the market cap of the voting token should equal the expectation of all future discounted buybacks and so what's interesting about this is that if the market expects use of the protocol to grow the price of the voting token today should be should reflect that expectation of future buybacks which means that the voting token should trade above its floor which means we don't have to charge any fees to any users if there is an expectation of future growth so there is this way this interesting way we're borrowing from the future we're borrowing from the future of future usage to subsidize the cost of using the system for today for early users which is kind of interesting now to be clear the system itself is not profit maximizing like a traditional stock or corporation is a the concept that we think this kind of works is it's this idea where the system is only trying to extract enough fees to support its own security once the system is secure it charges no more so in some ways it's it's like a collective concept where the contracts using the system are are opting in to be willing to pay the fees to secure the auricle for their own collective best interest but the system is not designed to extract any rent past what is needed to maintain its own security all right oh okay go fast here so what kind of that's all talking about like nerdy stuff around the Oracle but the other part of what we do is build out a lot of what we do and frankly what we're kind of most known for is building these contract templates specifically for synthetic tokens or for other kind of financial products and so it's interesting to talk about like what can you build with this infrastructure and Joey earlier talked about this like kind of fast versus slow Oracle's we very much look at this as like actually a fairly slow Oracle and I think the right question to ask is like when do you need an Oracle and in what context and we just put out a research paper on something that we're calling bit decks this is a design a research design a draft for a decentralized bit mechs using what we're calling like priceless contracts and really the design here is like hey when do we actually need an Oracle and our thesis is that we can build most financial contracts and most financial products where we don't require an on chain price feed we're not looking for a constant stream of prices being pushed the chain rather we can really look at the Oracle as something like a dispute resolution process where if contract participants fail to agree that the terms of trade are being followed you then call an Oracle to resolve a dispute and so the thup the kind of thought process here is it's a little bit like layer 2 ish inspired we're in the happy case and the optimistic path there isn't any need for an Oracle at all all you really do is you need the Oracle the resolve disputes when the contract participants themselves fail to agree that the terms that the terms of the contract are being followed and so there's a lot more like really cool stuff we can talk about there we have well I'll get to to the next slide comeback papers right this paper here is on this paper bit decks that we put out on it talks about this priceless contract or concept and then we have our Oracle paper as well yeah so just quickly on development we actually have the code for the Oracle written it's on our github it's on test net we are looking to deploy to Maine Ned fairly soon and we do have a series of financial contract templates what we're doing here a lot is around synthetic tokens so check out this token builder the synthetic token builder if you guys haven't already and check out our research paper on fit decks and priceless contracts cool bunch of us are here you should come talk to us I might have a minute or two for questions oh yeah it's it's only so we did a proof-of-concept around one of our financial contract templates not using our Oracle design that we deployed to main net in March so we actually had a token someone created a token using our synthetic contract template that tracked the S&P 500 I had like a million dollars of value and on main net and all that that was using a centralized Oracle this Oracle design only exists on test net right now so we will have to be deploying it no I mean it's it's a parameter to the system we're looking at making it about a day so there's like a data committed data reveal so it'll be like a two day process to get a result so if you dispute a trade you only you only pause that trade you don't pause the system so one way to think about the way this priceless framework design kind of works is that any disputes only affect the the kind of the contract in question it's like liquidating one CDP in the maker system doesn't pause the entire maker system you can resolve it asynchronously cost so there's a cost of capital like like just like in maker you can't liquidate well actually that's not right I'll take that back but in the design of the system there's a cost of capital that would be required to just to file a dispute yeah well so the voting if the market is efficient right the voting token should actually reflect the markets expectation of future usage of the Oracle itself there's a separate kind of angle to what you're talking about where we need to incentivize participation like people that we don't want speculators in this voting token this is actually something where we really want people doing the work and so in the system there is an inflation parameter effectively a reward parameter that we can tune and might set at a quite high level to incentivize to only reward people that are doing the work and effectively penalize the people that are not doing the work I think that's perfect timing anything else guys cool all right thank you [Applause]