0x
Decentralized order books and the quest for liquidity
In this article we are going to explore a huge project, 0x. We’ll start from their basic primitive, the order, and then move up layer by layer until we get to Matcha, the trading application that 0x has built on top of all their infrastructure.
Decentralized order books
In the previous articles we talked about Uniswap and Balancer. These projects can be seen as alternatives to the traditional way of buying and selling assets: the order book. An order book is a collection of buy and sell orders, and an order is just someone saying “I’m willing to buy an amount X of asset A for an amount Y of asset B”. In case you’ve never seen one, they look like this:
(This is a section of Loopring’s order book for the LRC/ETH market.)
Building a decentralized order book is actually very simple. You could make a smart contract where anyone can submit an order for selling some token, and then anyone else can see this order and fill it (“filling” just means buying the token that the order creator is selling).
The problem with that implementation is that everything is done on-chain, and so you have to send a transaction and pay gas each time you create a new order. This is not ideal. 0x fixes this by implementing a decentralized order book with a twist: while filling an order is done on-chain, creating and distributing orders is done off-chain. Let’s see how that works.
Suppose Alice wants to sell 1 ETH for 400 DAI. If the current market price of ETH is of $390, Uniswap or Balancer won’t work: she’ll have to wait until someone is willing to pay that price. Here’s how 0x would be used in this scenario:
First, Alice grants permission to the 0x exchange contract to move her ETH (well, WETH, but you get the idea).
Then she creates and order that says “I want to sell 1 ETH for 400 DAI” and signs it with her private key.
She distributes this order somehow. Anything is valid here: she could share it in a Telegram group, post it on Twitter, write a QR code with smoke in the sky, whatever. We’ll come back to this.
Bob somehow gets Alice’s signed order and he’s willing to fill it.
Bob grants permission to the 0x exchange contract to move his DAI.
Finally, Bob submits Alice’s signed order to the 0x exchange contract. The contract verifies the signature and atomically moves 1 ETH from Alice to Bob and 400 DAI from Bob to Alice.
(Check the end of this section in 0x docs for a visual explanation of this process.)
There are a lot of details not covered by this. Orders can have expiration dates, which are checked by the exchange contract. Orders can also be cancelled, although this is done on-chain and so it costs gas. It’s also worth mentioning that while this example (and the rest of this article) uses ERC20 tokens, 0x is actually agnostic about the assets that are being traded.
Relayers
If this was all 0x did, it would already be quite useful. This exchange contract lets you swap assets in a trustless way with anyone, which is pretty cool. But as a decentralized exchange it leaves much to be desired. The problem is that you have to find someone that just happens to be willing to act as the other part of the trade, when ideally you would only have to submit your order and forget about it.
The first and oldest mechanism that 0x created to deal with this is the relayer. 0x defines a relayer as “any entity that helps traders create, find and fill 0x orders”. This is, by design, a very abstract definition: there are several ways in which a relayer can work. A trivial relayer could be just an API where people can submit orders, see orders submitted by others and fill them. This is missing the incentives for the person running it, but it’s already a working relayer.
There’s a mechanism in the exchange contract that allow another kind of relayer. This mechanism lets anyone submit orders that complement each other. For example, if Alice creates an order selling 1 ETH for 400 DAI, and Bob creates an order buying 1 ETH for 410 DAI, anyone can submit both orders and keep the remaining 10 DAI (give or take, I’m fuzzy on the details here). So a relayer could accept orders but not list them, and benefit from the profit of submitting matching orders. For more examples, check the relayer strategies section of the 0x docs.
Mesh
The problem with relayers is that they can form silos of orders. A market is more useful if it has more available orders —that is, if it has more liquidity. The first attempt done by the 0x team to improve this was what they call the Standard Relayer API (SRA). The idea was for everyone to implement this API, so that any relayer could fetch orders from another one and increase its liquidity.
But this had a lot of issues. First, it meant that every relayer had to implement not only the SRA but also the mechanisms for fetching orders. Second, each relayer had to be aware of the others and add new ones if they appeared. Finally, a relayer could choose to fetch orders from the rest without sharing their own (thereby increasing its liquidity without giving liquidity to its “competitors”).
To solve this problem, the 0x team created Mesh. This is a p2p network that works like a bittorrent for 0x orders. So all a relayer has to do is to start a node for this network, submit orders to it, and fetch the new ones that show up.
Mesh fixes the three problems we mentioned before: a relayer uses this node as a sort-of external service (and therefore they don’t have to implement anything too complex, except the logic that consumes this service), the node itself handles the discovery and management of new peers, and there’s also an incentivization mechanism so that the more you share, the more you get from the network.
What’s more, Mesh is not only useful for relayers. If you are a market maker (a person that buys and sells in a market and profits from the spread) you could submit your orders directly to Mesh, without having to use a relayer. There’s even work in progress for using Mesh directly in the browser, without needing a server.
Liquidity bridges
Mesh helps a lot in increasing the off-chain liquidity of the protocol. But what if we consider on-chain protocols as potential providers of more liquidity?
This is the idea behind liquidity bridges. These are smart contracts that can act as bridges between the 0x exchange and other on-chain protocols. For example, you could have a liquidity bridge for Uniswap, and use it as a potential source of liquidity for a 0x user. The technical details are a bit complex. Roughly speaking, these contracts work as the creator of orders that, when filled, use the underlying protocol they are bridging to pay their part of the deal. If this is sounds cool and weird, it’s because it is.
What’s the point of these bridges? Why would you use them instead of using Uniswap directly? Well, I think the answer is that you are trying to aggregate as much liquidity as you can, and while you can’t move off-chain liquidity (that is, 0x orders) on-chain, you can make on-chain liquidity “live” next to off-chain liquidity. In practice this means that when you are looking for the best way to sell your ETH, you have at your disposal all the 0x orders plus every on-chain protocol that was bridged to 0x.
0x API
The last piece of our puzzle is 0x API. This is a public API offered by 0x that acts as a common interface to both Mesh (that is, off-chain liquidity) and liquidity bridges (that is, on-chain liquidity). This means that you can use these combined sources to get the best possible price for a given pair of tokens.
There’s nothing crazy here. This is just a public API offered by 0x that integrates and makes easier to use all the things we’ve mentioned so far. It’s worth mentioning that while 0x maintains an instance of this API, they also let anyone deploy it on premises.
Matcha
We started with plain 0x orders that anyone can create and distribute off-chain, and anyone else can take and fill on-chain. Then we talked about relayers and its role as entities that make it easier to create, find and fill these orders. After that we moved to Mesh, a p2p network for sharing orders that helps a lot in increasing off-chain liquidity. Then we discussed liquidity bridges as mechanisms for augmenting this off-chain liquidity with on-chain liquidity from other protocols. And finally we mentioned how 0x API abstracts all of these things away so that anyone can build on it.
One of the teams that used the 0x API to build something was the 0x team itself! After creating all this infrastructure, they went on to create their own exchange on top of it: Matcha.
There are two things worth noting about Matcha. First, as we just said, it uses all this available liquidity to let you trade two assets at the best possible price. But second, it hides all of this behind a very minimalist UI with a streamlined experience. You don’t need to know anything at all about all we explained in this article. In fact, there isn’t even an order book (unlike some relayer-based applications). In this sense, Matcha combines the many technical achievements from the 0x team with a cool and simple design for end users.
Further reading
Check this video for a more detailed explanation of what 0x Mesh is and how it works
This Decrypt article has a good high-level description of Matcha
And, of course, check the official docs to learn more