0x v3 Mesh P2Pnetwork

so this presentation does require some background to what is and what is if you have questions please hold until the end of both presentations zero is a protocol for decentralized exchange it uses off came the way and on can settle book unchanged settlement sir orders are broadcast by these these entities call three layers and that users behind these orders and then they submit them to the direct smart contracts for seventy so this is roughly how the smart contract pie level architecture looks like so you have real layers who are these opportunities for supporters and then orders are propagated to users who go through the primary exchange contract the exchange contract sentence transfer the dispatch transfers to these proxy contracts which are responsible for actually transferring these different assets and then the tokens are small community service so some background on where we're currently at today and what is included in Xerox 2.0 so 2.0 was a fundamental shift in the architecture of our smart contracts I added a mechanism for supporting arbitrary asset types using the protocol named Bernie it supports university 20 and you guys know 7.1 tokens and pretty soon there'll be a vote to add support for it also included a much more flexible trading functionality so you can match multiple orders together without requiring enough capital they're also more efficient ways to cancel orders so you like cancelling ahmedabad orders and the single fixed size transaction and I would say most importantly it allowed the protocol to just become much more extensible you can use custom smart contracts at various points within the trade execution process you can now create orders from smart contract wallets so there's multiple tags you can add arbitrary for your post conditions - executing a trade or could use smart contracts for customs signature of allocation so 2.0 was deployed last September and you received a good amount of feedback since then a couple points here people generally don't like that these given three layers are required to be denominated in CRX it just seems to be a point of friction for both users and developers there's a desire to interact with the smart contracts in a variety of languages there are many classes of developers within the CRX ecosystem and typically they're not all familiar with tight scripted liquidity could be better all around and people wanted more flexibility around matching and verifying fortress so that functionality was included in 2.

0 but their appeal educators I think are really preventing people from taking so the high-level goals at 3.0 are to improve developer experience to incentivize the quiddity and create better alignment for the key stakeholders which are primarily market makers to remove points of friction within the protocol and to create more flexibility around integrating plus new smart contracts now all these problems are possible to fully solve in a smart contract level but they can all certainly be improved 0x uses a process called the Xerox improvement proposals process similar to the IPS imperium to search every discussion around new features in the protocol so I encourage you to check out this repo on our github after this presentation if you want to get a full idea of all the features including 3.0 we don't have time to go over all of them unfortunately but these are the ones I'll be covering at a pretty high level so I'm lumping all these together because they all have to do with developer experience but generally we're going to be making a lot more of the functions within our smart contracts public and then once we have that it makes it much more easy to support any arbitrary languages for interacting with our smart contracts most languages have tooling to generate smart contracts wrappers from just a smart contracts API and once you have that since many more functions will be public you will basically be able to get most of our developer tools for free in any way support that we're also you also want to add which revert reasons so currently if you you know you set of transaction it's more contract and that fails you might get a message that just says like invalid signature or something like that so with rich revert reasons you're actually able to pass in parameters and for these perverts so now you might see like invalid signature here's a hash of the border and here's a signature ultimately the goal is to be completely language agnostic with this one is pretty straightforward so as I mentioned people are generally not happy that you have to pay fees these are X tokens right now so this proposal would remove CRX as the mandatory fee token from you layers and you'd be able to charge these in any assets supported within the protocol so you can charge using crypto kiddies cheese wizards you die whatever see I p38 creates a mechanism for sourcing liquidity from fiber network so this is already technically possible to do in 2.0 but the issue is that it changes how you actually interact with 0x orders changes both the UX and the developer experience so nobody is really using this today but in 3.0 it will become possible to interact with these in the exact same way as with any other z relax order and since liquidity is one of our biggest goals right now this is a great way for real Ayres to bootstrap their look where all they would have to do is monitor the tiger prices on pain and then they could just like create orders on behalf of this smart contract and people could interact with the fours as they usually do so from a DAP developer's perspective if you are integrating severe wax you'll basically get kagura integrations for free also I want to shout out to the tiger team because they helped us move this in creation along and just have been really responsive and supportive I will say that if this works really well it's possible to add any other sources of on camera quickly kagra makes sense as a starting point because they actually integrate a lot of those things into their protocol as well so you'll technically be able to get liquidity from pipe unit swab or easy to dive just by using Congress contracts so this is sort of how work a relayer would create an order on behalf of this tiger maker smart contract send the orders of the taker the taker fills the border the exchange contract exchange contract sends this throughout the rest of the pipeline contracts and the taper to open its sent to this tiger contract the Kagura maker contract will lapse sell that token using the actual Kagura network contracts and it will receive the token that the taker wishes to purchase and then it will send it back to the taker completing the trade and this requires no extra steps VIP 31 describes probably the biggest fundamental change in architecture proposed 43.

0 introduces state-based liquidity incentives into the protocol so there's a lot of information out there and this is a pretty complex topic I'm just gonna address it at a very high level but generally it adds a small protocol fee to every single trade this fees scales with the gas price of a transaction and initially it will target just the average gas cost of a single bill so you can imagine that basically your gas costs are just going to double when interacting with the protocol market makers receive rebates and the amount of the rebates are a function of the liquidity that they provide and the amount of CRX that they stake so this incentivizes CRX holders to either provide liquidity or to delegate to the most effective market makers who are providing the most liquidity so and once you like a strange choice to have this be denominated in ether and to have it scaled with the gas price of a transaction so I want to explain that a little bit because I think that's one of the coolest parts of this feature so we found that a huge percentage of all the trading volume on key centralized exchanges today is actually just arbitrage BOTS and they were just arguing all these different sources of aunt and liquidity these are BOTS are extremely sophisticated and it's very common for them to against these front-running wars with each other they're just hitting up at the gas price of each other's transactions and and they're willing to do that as long as its profitable for them to do so the issue with this is that trading is a zero-sum game so if an our block or if the miner is making a lot of profit that is actually taken away from the traders profitability so this is attracts people from actually creating orders in the place so by having the rebate scale with the gas price of a transaction you're essentially redirecting some of the profit from miners back to the market makers so mark makers can then provide more competitive pricing because they have some protection against arbitrage theoretically this this could actually reduce bid-ask spreads or reduce the net bit as spread so that even though the taker is paying an extra protocol fee they will be filling an order at a better price than they would have otherwise and he receiving that benefit for that there's a lot of additional reading especially on zi p 31 you could look at our CI peas repo which digs into the smart contract architecture of it all we have a really good blog post that digs into it as well and a video that goes along with that and then there's actually a wet neighbor and some good discussion going on at our forum so please check that out and with that I will hand it over to Alex will talk about the CRX match hi guys I'm Alex Brown and I'm the technical lead on a new project that we're really excited about called 0x mesh 0x mesh is a peer-to-peer network for sharing orders so to help explain why the six significant I'm gonna talk a little bit about how sharing orders works on 0x today most users interact with 0x through something that's called a real layer three layers are responsible for aggregating orders from many different users into an order book and they allow users to add remove or update their orders via an API or a GUI or both relays also have the ability to share orders with each other through something called the standard relay API this is what the appliance system kind of looks like we have a lot of different real layers some of them are sharing orders with one another via the SRA some of them are not and this kind of leads to a disjointed Network where not everybody knows about all the orders in the ecosystem the SRA does a pretty decent job of allowing real layers to share or dos with each other but there are some problems with it firstly each relayer has to implement their own SRA server and a lot of them are written in different languages so this leads to a lot of redundant work in the ecosystem the SRA is a little bit hard to extend support for new token standards when we added support for a or C 7:21 we also updated the SRA spec but it was a little bit hard because they didn't plan for this from the asteroid it was originally designed and after we updated the spec we had to wait for relators to update all their implementations to match it the last thing is that with the SRA relays I want to share orders with each other have to know about all the other identities ahead of time so they have to manually go through and add the SRA endpoints that they want to pull orders from and they also have to convince other real layers to add their endpoints the SRA is not going to go away anytime soon but 0x master offers a more efficient way for relators to share orders with one another and enable some exciting new possibilities grx mash runs inside of a docker container and real layers interact with it by using a simple web socket API what this means is that all the relays are sharing the same codebase so there's not any more redundant work throughout the ecosystem as your expansion features a flexible messaging system that can be easily updated to support new token standards or new order formats so I means it'll be a lot easier to update in the future and since we're managing the code and it runs in a docker container there'll be a lot less work on the part of real layers most importantly peers in the 0x match network are discovered dynamically based on shared interest so there's no longer a requirement for all the participants in the network to know each other ahead of time and manually keep track of endpoints what this leads to is a much more cohesive network for shared liquidity so with Xerox mesh we expect to see more relays connected to one another and more application developers taking advantage of the shed liquidity pool another thing that we're really excited about is that Xerox mash enables a new type of relayer called a service relay so 0x much runs inside of a browser and what this means is that if you had a UI on top of it and you can host it on something like ipfs and serve it through a dot browser then users already have everything that they need to share orders with one another and start trading this means that you don't need to have a separate database or separate back-end server we think that there's still definitely a place for traditional hosted real layers especially for highly liquid and fast-moving ERC 20 markets so I don't think they're gonna go away but the service real layer model enables a new way for niche markets for n of T's for example or markets that need a little bit more time to mature it's a great way for them to get started so for some technical details 0x mesh is written in go it compiles to web assembly which allows it to run the browser we're using lib p2p and Webber to see is the networking layer and this enables two browser peers to communicate with one another directly without using a third party we have an incentive model that's inspired from live tour instead for tat and encourages people to share more orders and we also have a DDoS protection mechanism which involves checking the eath balances of users you can find out a lot more about this in our architecture doc which is on the forum so just to give you a rough idea of where we're at in the development process we announced this project in March of this year shortly after that really just the architecture dock which I mentioned which is available on our forum starting today we're open sourcing the repo so you can go ahead play around with it if you want to in June we're gonna launch a beta with a handful of early participants in the network and then finally in September we expect to be on main full production contacts so like I mentor we're open source in the repo now there's still a lot of work to do and a lot of features that you need to have but it is technically runnable so if you're feeling adventurous you can go to github.com slash the arcs project slash is your ex match and check out the code that we have so far and give it a try that's it at this point Amir and I will take questions if anybody has questions [Applause] yes so WebRTC actually has a requirement or something called a signaling server to exchange offers and answers so this is something that we're constantly thinking about in the first version of Xerox mash they're either the centralized server just just for that initial signaling portion we're also coordinating with Lippe derby team on generating a spec that will allow any peer to serve as a signaler so as long as two peers are connected to the same peer they can then signal through love any other questions sure yeah of course so we're building an incentive model that is inspired by the live torrent the term the term has this model called tit for tat where you share chunks of a file with people that also share files with you so you pick the four of your peers that shared the most with you and then you pick one pair randomly and the random peer is really important because it enables people that just joined the network it gives them a chance to kind of participate and if you share something of them and maybe it'll share something back so ours is gonna be very similar but it'll be based on sharing orders instead of chunks of files no no comment on the value but those are the state based the clear the incentives that I was talking about so you would stake CRX and provide liquidity to some dates yes I think you got reasons is extremely important long term there's a very basic governance framework we're using right now but it feels like it's probably a little bit early to release full-blown governance I think we need a network that's really worth governing in the first place and in order to do that I think glue quality is going to you know really kickstart a test cycle yeah so that smart contract is actually going through audits this week should be almost done by now and we're basically waiting for the actual 11:55 spec to be finalized before we would have a vote to add up to the protocol but it seems like it's probably not very controversial and you know as soon as that happens they can be at it pretty quickly there aren't that many projects who are using 11:55 today but in my opinion it's like by far the best token standard it's kind of a combination the RC 20 and years at 7:21 and there are some efficiency gains that come with using it as well but I know of a handful of projects that intend on using it so I think when those come online that's you know probably when Wilson some activity there but it's hard to say hold on any other questions thank you [Applause]