 Hi guys, hey, hi, my name is Carl Lambert, I'm here for a project called Universal Market Access, or UMA, and I'm quite pleased to present to you guys this research paper we just put out, it's fresh, it's a draft, we're calling it Bitdex, and this is our design for a decentralized Bitmex using what we're calling Priceless Financial Contracts. So goals of this talk, just to give you an overview, I want to explain to you guys how Bitdex works, I want to explain this concept of priceless financial contracts, and then go into some details of what we think that can enable. So as a starting point, let's just talk about what Bitmex is, and I'm not really picking on Bitmex here, I'm talking about any centralized futures exchange, anything that has levered transactions, and so Bitmex, like the CME Trading Futures or any CFD provider, is a lever-driven trading platform, it's a huge exchange, and the exchange itself provides a bunch of functions that make it usable to the people that trade on it. Those functions require a trusted third party operator, and so those are things like custody margin for all the positions, moving margin back and forth clearing, and ensuring the solvency of all the positions in the exchange. What's really important to notice, reminded everybody of, is that when Bob and Alice trade on Bitmex, Bob and Alice might actually end up having offsetting positions, but they don't face each other, everyone faces the exchange. The exchange functions as what's called a central clearing counterparty, and they're the ones that ensure the solvency of all the positions. So Bitmex does some good things, all these exchanges, fast high performance trading, we like that, with high leverage, this is things that people want. Bitmex is going on a big business, CME, futures exchange, big businesses, these are services people want, but they are completely custodial, and the exchange sets the rules of game. So the exchange decides what leverage you get, how to trade, but importantly they also decide when positions get liquidated, unilaterally have that power. And so this is like really centralized, it's not just like a centralized coin base or whatever, where that's just custodial, there's also this whole aspect of centralization around trusting Bitmex or whatever exchange to monitor your position's solvency correctly and to not liquidate you at the wrong time. So this is bad, this is not what we want. So the question is, sorry, why is decentralizing Bitmex so hard? What makes this so difficult? Why can't we just like run this on the blockchain? And the fact is there's just so many damn transactions we have to check. So the idea is that Bitmex functions as this somewhat of a black box that has all the position and margin data for everybody out of all the trades in the system. And they go through and they check the solvency of all trades with each price tick. So every price update, they're checking the solvency of every position in the system. And that's just a lot of transactions, you can't run that on the chain. And the data is even available to do so if you did have it. So what are we going to do? So we're going to try to solve this with blockchains. But more importantly with some layer two thinking, some layer two concepts that we're going to put into financial contract design. Okay, core idea here, our observation on a futures exchange like Bitmex, position data does not change that often. The data can actually, it changes infrequently enough that it can be recorded on chain, allowing anyone to monitor positions to verify their solvency. And so this is pretty interesting, right? If we can actually put the position data on chain, we can design a system where anyone can monitor the solvency of that data off chain, allowing us to have a design with no centralized price feed and no centralized arbitrary of proper collateralization. So Bitmex does this by allowing any counterparty to dispute any opposite position. So any long can dispute any short, any short can dispute any long. And Oracle is only used to resolve these disputes when they happen. So this is very much like an Oracle minimized design. We only use an Oracle when a dispute happens. And I'll go into more detail on that in a second. Penalties are then paid to the disputeer by the disputeer position, if the dispute is deemed valid by the Oracle. So there's economic incentives here to correctly dispute or enforce the way the position trades. Okay, so core idea here, we're going to ask people off chain to monitor the exchange to see if it's properly collateralized. That's like the big idea. And there is no on chain price feed, an important point. All right, so let's just talk about what's happening on chain and off chain. Kind of go through some details here and why this can be fast. So Bitmex only puts data on chain that needs to be on chain. Let's break down the core exchange functions. So margin deposits and withdrawals, those happen very rarely. People contributing to the margin or withdrawing margin from their account, like on Bitmex that happens very frequently, that can easily be supported with on chain transactions. Recording new trades, how many new trades actually happen a second? It's hard to deduce exactly what happens on Bitmex here, but it's like low single digits. Arguably that'd be tough to support on Ethereum right now, but if you get pretty close. So we can also record that data on chain. The interesting part and where this scales is all the measuring trade solvency. So checking all the positions, Bitmex has like tens of thousands of transactions per second to check. All the positions in their system with every price take. But we are pushing that off chain because now we've recorded that trade and position data off chain. So anyone off chain can check the solvency position. That's where our scalability comes from. But one point I want to make clear is that Bitmex does not solve a decentralized order book problem. That's not what we're starting out to solve. Longs and shorts in this trading system still need a mechanism to find each other. That would be an order book. We aren't building that. There's pretty semi trusted designs or peer-to-peer order book designs like 0xMesh that are pretty interesting approaches to solving that problem. Okay, so let's go into an example just to try to illustrate what's happening with this design. So remember, the trade and position data is recorded on chain and anyone can check the positions. So what starts here? We're going to name all of our longs L1 through LN over here and our shorts S1 through SN. Important point, L1 does not base S1 and S2 does not base L2. They all base the contract in exchange. So they're not directly offsetting. But we're going to record, we're going to also define a market here where we're going to trade the price of Bitcoin and let's just say there's a starting price of Bitcoin at $10,000 per coin and so our NPV function for what longs and shorts get paid out is going to be the current price minus $10,000 so our initial price of $10,000 longs and shorts both means $0.00, we're all flat and we have a margin requirement here of 10% of the current price which means we got a tax leverage for $1,000 so you can get $10,000 exposure. Jumping through some details, okay? So we go and we record this data on chain everybody agrees that the price of Bitcoin is $10,000 they check the NPV in margin and everybody looks good, they all check it out everybody thinks everyone is correctly margin and the system is solvent. So let's now say that L2 thinks the price of Bitcoin might drop to $9,500 and if that were to happen L2 knows that they will be under collateralized they'll lose $500 because they're long they'll lose $500 and they'll no longer meet their margin requirement of 10% of the price so what L2 does is deposit additional margin they're doing this to make sure they don't get disputed and liquidated in their position. Cool, easy, this is exactly how it would work on get next to where if you didn't if you're right against your margin requirement and you don't deposit more margin you'll get liquidated. Let's go through another example where L2 does not deposit additional margin but S1 does indeed think the price of Bitcoin has dropped to $9,500. Note that I said this is S1's opinion there is no on-chain price fee for them to point to they basically it's like a bring your own price fee concept S1 is looking at the world and says hey I think the price of Bitcoin is $9,500 they're then going on to our on-chain data and they see that at a price of 9,500 L2 would actually be under-collateralized according to our NPV and margin functions and so what S1 does is they go ahead and dispute L2 they say hey I think you're under-collateralized you're in default and at that point that dispute goes to an oracle that's going to resolve this disagreement or this issue and as one is right L2 will pay a penalty to S1 this default penalty if S1 was wrong according to the oracle the penalty will go the other way to compensate L2 for being unfairly disputed okay core design, core idea so these are the core function signatures in our just initial simple design I'll actually just jump ahead to the slide and go back in a second that green is pretty bright so you can't read that but it basically says we've got a half-and-half situation so imagine you're now a position in this big-deck system at any given time you can do one of four things you can do nothing because you think you're correctly collateralized and you wanted to sit there when you're happy you can deposit additional margin in your position which you would do if you think the trade is going to move against you and you might get liquidated or you can withdraw we request a withdrawal of margin so if a trade has moved a lot in your favor and you're up a lot of money you can make a request to withdraw that money note that you cannot immediately withdraw the money because we need to have a time lock to allow other participants to verify that that request is valid, that you're not trying to take out too much money at your position or you can dispute somebody else's position and say they're under collateralized so the core argument here is that in the optimistic path in the happy path you're just depositing or withdrawing margin and making sure your position stays perfectly collateralized there's no need for an oracle and oracle price while you're staying in that happy path the only time we need an oracle and oracle price is when there's a dispute when somebody says, hey, this position is under collateralized so just to go back to that last slide for a second these are like the core functions of this simplistic design deposits happen at any time withdrawals can happen at any time again, time locked by this delay, this slackness requirement and once that passes then anybody can withdraw that mark then the withdrawal request goes through disputes remember, any long can dispute any short and vice versa what's interesting about this is that because we have many watchers of the system we've got many longs and many shorts and they're all watching each other we can actually have a pretty short wideness requirement our time law on disputes can be pretty short because we can be pretty confident that somebody's gonna be there to watch the system the last two things here are really about entering and exiting trades in the position so we have a simple design where any time you want to enter a new position you can create a pair so any long and short find each other say, hey, we want to do a trade at this price and negotiate that off-chain and then they come to the system and they're like hey, here's our new pair of longs and shorts we want to enter the system the Biddex contract just has to check that that new pair of longs and shorts is correctly margined and we can do that with a clever trick this is a little bit of an implementation to help but if you do it with a clever trick of having that new pair point to an existing long and short position that it is equal and collateralized to or more collateralized than this is detailed in the white paper but really it's a shortcut for us to have an instant entry through the system and then we have a simple mechanism where you can instantaneously exit a trade from the position and withdraw your margin if you're a long, you do that by buying an offsetting short position and then you're immediately able to withdraw the combined long and short deposits so those are detailed and a bit more detailed in the white paper just a quick overview so, again, back to the slide this kind of looks like a layer too and that's the idea this is meant to be a bit of a layer too for financial contract design where we are assuming that things stay in the happy path and we are only using our oracle when there is an unhappy dispute when something goes wrong so we're calling this priceless financial contract design and the core idea here is that if everyone behaves as they're supposed to if everyone doesn't default and adds margin appropriately then we don't actually need an on-chain price and it's priceless this is the happy path we stay in the happy path, we need no prices on-chain other core kind of concepts of this this framework that we're proposing is that when someone behaves badly it needs to be observable off-chain we need rewards to correctly reward participants for disputing bad behavior and if that dispute is proven valid we need that behavior to be punished, to be penalized and we only need on-chain prices to resolve disputes which means that the oracle functions as a sort of dispute resolution mechanism which should be relatively infrequently used so these ideas are sort of priceless financial contract design this is something new that we're going to write more about we would really love feedback on this idea but again it's all about how we can minimize oracle usage to allow us to do higher leverage, higher speed things with DeFi and with financial contracts so going touch deeper on what this means for oracle design itself so writing contracts pricelessly I'm repeating the point from the last slide writing contracts pricelessly means oracles become dispute resolution mechanisms that only need to be used when counterparties fail to agree that we think is kind of interesting and kind of novel and the example here is to point to like the fiat world where me and one enter into a legal contract financial contracts a lot of them are like legal contracts we can enter an illegal contract and we do that privately with no intention of litigating that contract we only litigated if something goes wrong we fail to maintain the terms of trade the same concepts being applied here where we're saying hey let's enter into a financial contract that we both know the terms and we're going to do what we've got to do but we're only going to dispute we're only going to use an oracle if something goes wrong framing oracles as dispute resolution mechanisms arguably opens up the design space for decentralized oracles since we can do things a little bit differently we no longer need like an on-chain price fee that's constantly pushing a lag or real-time price to the chain we can instead let oracles be relatively slow and expensive and potentially like far more decentralized because they should be relatively rarely used again like using the court analogy you don't go to court for every contract you write you only go to court when there's a major dispute and it also lets our oracles be asynchronous we don't need the dispute resolution process to be happening at the same time as the rest of the contract system so we must build a design for this type of oracle that we call our data verification mechanism which puts economic guarantees around corruptibility that design we've got way paper and it's actually a bit built it's on testnet it's well suited to support this type of priceless financial contract so just to wrap up really quickly we introduced this idea of Bitdex which is decentralizing Bitmax something that has been really really hard to do at DeFi and we did this using this concept of priceless financial contracts where we are pushing all of the work off-chain so we are getting greater scalability by having positions there's solvency being monitored off-chain and enforced via disputes we're doing this without an on-chain price feed people bring their own price feed off-chain and we're minimizing oracle usage so we're reframing the use of an oracle as purely a dispute resolution function this lets us build what we're calling the fast DeFi products like Bitdex in exchange with leverage it also lets us build synthetic tokens we're big on synthetic tokens you guys can go to our website and read all about that we can do this with lower collateral requirements because we can be much more efficient with our margin usage by not having a lagged price feed or any kind of delay and we can build all kinds of swaps options also to other financial contracts and this is the sort of stuff that frankly we love talking to you all about what you want to build and how you can build it ok so wrapping up there's a lot of research out there that we would love feedback on this Bitdex paper we just published last week it's a research paper and it's a draft we would love feedback on this design we also have our design for our oracle our dispute resolution style oracle that we published a couple months ago that we would love feedback on and there's five of us here at DeFi please join our developer Slack links in our github links to where you can find various things thanks very much