 So we're going to get started. I'm very excited to be here today to talk to you about Xerox. This project has been a long time in the coming. And I hope that we can get some people excited about it today. So just to outline this presentation, I'm going to quickly give a little bit of background and timeline on Xerox protocol, motivate the problem we are trying to solve, talk a little bit about the existing work. Then we'll go into Xerox protocol. We'll talk about the benefits of an open standard. We'll cover the developer ecosystem that we see developing today. And we'll quickly discuss the need for governance for open protocols. Then we'll go into DAP integrations and something that we like to call token abstraction. So my co-founder Amir and I started working on Xerox just over a year ago. We released our white paper in February of this year. And since then have put together a really talented and awesome team. All eight of us are here at the conference. We love chatting with people. So feel free to come up and say hello. And we're happy to answer any questions. So really the motivation behind creating Xerox protocol was this long-term theme that we see coming into existence where anything that can be assigned to value in the world is going to eventually be tokenized and moved onto an open financial network like the Ethereum blockchain. So this can be things like traditional assets like fiat currencies, stocks and bonds, debt assets, all the way to scarce digital goods like video game items and loyalty points and airline miles, and even things that are more abstract like attention. So naturally, with all of these different tokens that are going to eventually find their way onto the Ethereum blockchain, there needs to be a very low friction way to exchange these tokens. So just taking a quick look at the exchange ecosystem on the Ethereum blockchain, kind of, this is kind of the state of the Ethereum blockchain back when we started. There's been quite a few developments recently as well. But there's a handful of existing decentralized exchanges and there's a lot of decentralized applications that require exchange functionality in order to operate. So things like prediction markets or stable coins or decentralized fund management platforms, all of these things require exchange functionality. So the problem that we identified in the ecosystem was that every single one of these exchanges and dApps was creating their own proprietary and custom smart contracts from scratch. And what this meant is that not only would each exchange have to bootstrap liquidity from scratch, but it would also expose end users to a bunch of different smart contracts that have varying levels of security and efficiency, and they all do the exact same thing. So that's not a very efficient approach. Another issue with having a bunch of different implementations of exchange smart contracts is that there's no interoperability between any of them. So it fractures the ecosystem and it kind of results in less liquidity for everyone. So in our view, smart contracts should really behave like modular building blocks that can be assembled and reconfigured. And we also believe that open standards tend to win out in the long run. So I'm just gonna briefly talk about the different approaches to decentralized exchange that exist and give like a high level view of the pros and cons. So the very first decentralized exchanges that were created on the Ethereum blockchain kind of took the same functionality of a centralized exchange and pulled it into an Ethereum smart contract. So the Ethereum smart contract would store an order book within the contract. So what this means is that every time someone wants to post, modify, or cancel an order, they must pay gas costs and create an Ethereum transaction. And this becomes completely unrealistically expensive for any sort of market maker to create liquidity using an on-chain order book. Not only is it really expensive, but you also bloat the blockchain with tons of unnecessary transactions that aren't necessarily moving any value. They're also high latency. A second class of decentralized exchanges are automated market makers. And automated market makers, instead of having two parties on either side of a market trading directly, both parties trade with a smart contract. And the exchange rate that is offered by that smart contract is modified deterministically according to how strong the market forces are on either side of the market. Auger spent a long time working on finding working implementations of automated market makers and found that they're really subject to front running, they can be gameable. And they're really low throughput. So if you have one party with a large pot of some kind of token and another counterparty that would like to trade with them, instead of just doing one big trade directly, they must shop up that trade into little tiny pieces and trade with the smart contract back and forth. So it's really inefficient. The third approach to decentralized exchange, and we haven't seen any examples in production yet, but we will soon, I'm sure, are state channels. And so state channels are amazing for reducing latency and increasing throughput because with state channels, transactions occur off of the blockchain. And you can sort of accumulate a series of intermediate state changes, aggregate them and settle them all in the blockchain in a single transaction. The issue with state channels is that they're great if you wanna do day trading, but if you wanna just do one block trade, you just wanna buy a big chunk of tokens and immediately use them, there's a lot of friction around using a state channel. You have to move your funds into the channel. You have to place down a security deposit to ensure that everyone is behaving honestly within that channel. And then when you want to move your funds out of the state channel, there's a challenge period which is required also to ensure people are behaving honestly. Another downside to state channels is that when you move into a state channel off of the blockchain, you isolate yourself from all of the cool and interesting smart contracts that exist on the Ethereum blockchain. Yep. So Zach pioneered the off-chain order book with on-chain settlement approach. Around a little while after, we came up with a similar approach, but it's really a protocol instead of an on-chain order book. So Xerox Protocol really is comprised of a standard order schema that represents the different parameters associated with a given order. So the two assets that are being exchanged, the exchange rate, the expiration time for this order, and a cryptographic signature of the above parameters. And that is coupled with a smart contract system that is responsible for settling these trades directly on the blockchain. What's really makes Xerox a protocol is that there really aren't any rules about how you choose to pass these cryptographically signed chunks of data around off of the blockchain. So the transport layer is arbitrary. You can generate one of these cryptographically signed orders and you can send it to a counterparty in an email or over Facebook, or you can write it down on a piece of paper and send it to them using a carrier pigeon. It doesn't matter. The cryptographic signature just needs to be valid. Another thing that is different is that the message passing semantics are arbitrary and you can choose to use a variety of different strategies. So if I wanted to trade directly with a counterparty in a peer-to-peer fashion, like an over-the-counter trade, I can just create this order that specifies the parameters I am interested in trading at and I can cryptographically sign it and I can send it to my counterparty and we can settle that trade directly on the blockchain, completely free. There's no fees involved other than the gas costs. But naturally, people need to go to a location where a bunch of different parties are interested in trading and where these orders are aggregated in a single location. And we call these relayers or they're very similar to decentralized exchanges. What's really cool about 0x is that anyone can be a relayer. Anyone can create a decentralized exchange and charge trading fees on all the volume that they create. They keep 100% of the fees that they charge. There's also a variety of different relayer strategies that a relayer can decide to use. So you can use an open order book strategy, kind of like Ether Delta, where there's a public post-it board and people can put their orders up and anyone can take them down. You can also do a centralized matching strategy where a relayer will only accept orders onto their order book if they are specified as the only entity able to fill those orders. And when they find two orders on either side of the market, they can batch fill them simultaneously and synchronously on the blockchain and you can eliminate things like front running. A third option is a shape shift type exchange where someone essentially acts as a reserve manager and they just post a bid and ask for a single trading pair. So why create an open standard? Why? Well, one of the reasons is because if you have an open standard, you can create really robust developer tools. So things like Xerox.js, our JavaScript library, and things like our standard relayer API. And with these tools, you massively lower the barrier to entry for new people and developers that wanna create decentralized exchanges. And so what you end up getting are a variety of different decentralized exchanges that are highly competitive on fees as well as user experience. They also find and target different market niches and you end up with a diversity of different decentralized exchanges. A second reason to create an open standard is that if every single decentralized exchange is speaking the exact same language, it creates these network effects around liquidity where each relayer isn't necessarily competing with the others, they could actually benefit from a new relayer entering the ecosystem as arbitrages are taken advantage of across different exchanges risk-free and atomically. Decentralized applications can also be a source of customers for these decentralized exchanges or relayers. So since deploying Xerox protocol on the Ethereum mainnet in August 15th, we've seen just a crazy explosion of development activity. There are upwards of 10 different completely independent developer teams creating relayers on top of Xerox protocol. So I'm just gonna give you a closer look at a few of these. So the first relayer to go live on the Ethereum mainnet is Kin Alpha. And this was created by a single developer in their spare time over the course of a few weeks. You can see that it leaves a little bit to be desired in terms of the user experience, but we just thought it was pretty amazing that someone could go and create this on their own in a matter of weeks. Another really cool relayer that's worth checking out is Radar Relay. They're live on the mainnet today. You can go to radarrelay.com and check them out. They're doing a little bit of volume, but their API should be up soon. And third is Paradex. Paradex has created this beautiful user interface and they're expecting to launch their beta on the mainnet this month. And they're using a centralized matching strategy. So we're really excited to see all this development activity going on. And I think that we will see a dent put into the centralized exchange industry. Some other interesting development that we've seen are just independent developers out there creating trade explorers that allow you to view and explore the various trading activity going on on top of ZeroX protocol. And you can sort of sort trades by different relayers and by different trading pairs, et cetera. It's been really exciting for us to see people building things completely independently on top of the protocol and just finding out about it on Reddit. So now I wanna talk about something that is a little bit different that ZeroX protocol enables. And I think this is something that's pretty unique compared to the other approaches and implementations that are out there today. So ZeroX protocol allows smart contracts to natively execute trades in a single line of smart contract code. And this is really powerful because this essentially allows ZeroX protocol to act as an exchange module that exists natively within the EVM. And this allows ZeroX to be treated as a sort of fundamental building block that can be combined and built upon by other developers creating their own protocols. And to date we've seen two examples of completely independent protocols being created on top of ZeroX, DYDX and Dharma. I would encourage you to go check them out. There are also a variety of other decentralized applications that have decided to either right now or some point in the future integrate ZeroX protocol because it will allow them to get the functionality they need without having to write any code from scratch. So now I wanna talk a little bit about governance. So ZeroX is an open system and there are a variety of stakeholders and they each have their own motives and their own desires that they need out of the protocol. But they all benefit from the network effects of building on top of the same shared standard. And at the same time, ZeroX protocol is a system of Ethereum smart contracts that are immutable, but they must remain future proof over time. So how do you decide on protocol upgrades? You can either allow a small group of developers to make all the decisions about the future direction of the protocol, or you can allow all of the stakeholders in the system to have this fair say. So what we decided to do is to create a decentralized governance mechanism that uses token voting for future upgrades to the protocol. So I understand that everyone here is probably a little bit sick of all the tokens that are out there today and they might not wanna deal with another token. So I'm gonna just briefly talk about something called token abstraction that ZeroX enables and I think is really exciting, but we're gonna have to think about five or 10 years out from now. So when we think about decentralized applications, we used to think of them as sort of these vertically integrated monoliths that might've been built on the Bitcoin blockchain or the Ethereum blockchain, but I think what we're starting to see is an unbundling where there's many layers in the decentralized application stack and they're all specialized networks with distinct incentives and tokens. So you might imagine that a decentralized application requires a consensus layer, it might require some file storage and some computation and it might require some oracle to inject external data into that DAP. So if we have all of these different layers in the decentralized application stack and you're the end user of this DAP, it's going to require you to have a bunch of these different tokens for each layer of the stack and that's something that I don't think very many people are excited about. So in this example you can see there's some sort of decentralized application and what it wants to do is it wants to take a data set from say IPFS, it wants to run some computations on that data set using something like Trubit and the result of that computation is going to be injected into a smart contract which makes some sort of decision depending upon the result. Something that just would not be feasible within the EVM. In order to power some sort of sophisticated decentralized application like this, you might be required to have a handful of different tokens and that's not a very good user experience. So something that we're really excited about that we think ZeroX will play a role in in the future is something called token abstraction. So as the end user of a decentralized application, instead of having to hold a variety of different tokens that you may not know or care about or really have any vested interest in, you can just hold on to some tokenized fiat and you can pass in this fiat along with a thick stack of ZeroX orders into the decentralized application that you want to use into the smart contract. It will forward those fiat tokens and the ZeroX orders onto the ZeroX smart contracts and the smart contract will synchronously and immediately receive the variety of tokens that it needs to power that decentralized application. The smart contract will immediately go on its merry way using them as it needs to. So you can imagine that the takeaway from this is that instead of having to have a bunch of different tokens as an end user in the future, you might just go to a decentralized application and see that it's gonna cost you $3.50 in fiat tokens in order to access some of its functionality. So lastly, we're working on version two of ZeroX protocol today and we would love to get some community involvement and feedback. Some of the things that we're really excited about, including in our ZeroX improvement proposals are things like support for non-fungible tokens, atomic order matching, order generation by smart contracts, and a variety of other things as well. So we welcome you to come and contribute to the protocol and shape its future. So thank you very much, I appreciate the attention. Thank you.