Trustless Market Orders

With the advent of the decentralized economy, we are seeing a wide array of trustless trading platforms like DEX’s, bulletin boards, and relayers that allow wallet-to-wallet trading through the use of cryptographically-signed orders. These orders express the willingness to swap some fixed amount of one token for a fixed amount of another.

Despite a variety of implementations and strategies, there is no trustless trading platform that has an efficient, scalable and reliable method for the execution of market orders. In response to this need, I’ll outline our strategy at The Ocean and explain why it’s the best approach to building this necessary component of a capital market.

This is largely accomplished with 0x, although the problems and solutions outlined here extend to any protocol that implements such behavior. Similar issues would apply with dy/dx, Augur, Dharma or any other scenario where multiple offers might be accepted at once.

Market Orders

What is a market order?

In a market like a stock exchange (a continuous double auction), order books have limit orders at different prices to buy or sell traded assets. Traders who want to buy or sell at the best available price place a market order to be matched with one or more limit orders that meet this criteria.

Market orders are handled by a matching engine, which is a process that maintains the state of the order books and handles incoming requests to place new market or limit orders. There are a variety of ways to achieve market orders, and all have some benefits and drawbacks. We’ll detail some approaches below.

Market Order Example

• Say a trader, Alice, wants to buy 10 bananas. She creates a market order to buy 10 bananas and submits it to the banana exchange.
• The sell side of the order book contains an order from another trader, Bob, to sell 20 bananas at $0.10/banana.
• These orders are matched so that the new market order matches with half of the outstanding limit order, and Alice buys 10 bananas from Bob for a total of $1.
• Then, suppose a third trader, Chris, comes along and wants to buy 20 bananas. Bob only has 10 bananas left to sell, so Chris also looks for the next best offer. This is Donna, who is selling 10 bananas for $0.12 each.
• Now, Chris’ market order for 20 bananas is matched with both Bob’s order for 10 bananas at $0.10 each and Chris’ order for 10 bananas at $0.12 each.
• In the end, Chris’ total market order is for 20 bananas for $2.20.

Limit Orders

There is some ambiguity in the way the term limit order is used. When we talk about a limit order, it may be fully, partially or not immediately fillable (FIF, PIF or NIF). If it is FIF, then that is effectively a market order since it is matched with existing limit orders. If it is NIF, then the matching engine creates a target order and puts it on the book. If it’s PIF, then there is a market portion and a target portion. We create and fill the market order and the target order is placed on the book. It’s fair to say that a market order is a special case of a limit order with infinitely high or low limit price.

Best Pricing

I’ll use the term “best pricing” to mean that an exchange is giving the best available price to a trader making a market order. This would be achieved by directly matching two traders together, as in the example above. This is applicable when placing an aggressive (ie. PIF / FIF) limit order since the trader has specified that they will pay a higher price than the best price available.

Trustlessness and Market Orders

The above banana example works well in the context of a trustful, centralized exchange. Chris can place the market order and the exchange can match that order with Bob and Donna. The exchange calculates the total of the matched orders and moves the funds between the accounts managed by the exchange.

However, for the market order to be trustless, Chris must cryptographically sign a declaration of the exact price that what she’s willing to pay. This can be difficult when you have multiple traders trying to take the same orders. If, in the above example, Chris decides to make her market order, she would create and sign an order to buy 20 bananas at $2.20 and submit that to the exchange to be matched with Bob and Donna’s orders.

If Chris knew the exact state of the order book and could communicate instantaneously with the exchange, then there would be no problem. She could create the market order buying 20 bananas for $2.20, sign it and send it to the exchange to execute. However, this is often not the case. It is more likely that by the time she gets the updated order book, creates, signs and sends the market order and the exchange receives it — the intended orders would be unavailable, or some better orders would have come along. In this case, the price of the market order that she signed no longer matches the sum of orders in the book, and there is a problem.

Existing Approaches

Existing approaches from 0x relayers come in a few varieties. Most (maybe all) relayers operate either an open order book or a matching strategy and there are mechanisms to achieve market orders that are used in each:

Open Order Book — Radar Relay, ERC Dex, Bamboo, etc.

• As detailed in the 0x wiki, an open order book is the “simplest and most obvious strategy” for maintaining an order book. In short, there are no market orders. Every trade involves taking all or some of one, and only one, limit order. The trader may take an order with the best available price, as they should, or they can take any order they want. They might, for instance, not want to trade with certain parties for legal reasons. A market order can be effectively achieved by taking several orders from the top of the book in sequence until the desired amount has been traded. This is inefficient in that it consumes gas for each of the orders and places the burden of matching on the trader, rather than the exchange.

Matching Strategy, Fixed-Price Execution — DDEX

• Using the matching strategy, a matching engine can be implemented such that all orders that are submitted are limit orders with a finite price and when there is a price overlap, the relayer matches the order and executes the trade. Limit orders will rarely have a perfect price match and the relayer won’t trade at a loss, so any discrepancy in price is retained in the common taker address, which is the relayer. In practice, the price overlap can be minimized but not eliminated. This is a plausible approach in the relatively volatile and illiquid early days of decentralized trading but as price efficiency increases, these errors become less acceptable.

Matching Strategy, Overcharge/Refund — Paradex

• Paradex had a unique solution to this problem which was to use the fixed price execution above but with the addition of a refund to the trader that placed the market order, assuming that the transaction cost for this refund was less than the refund itself. While this solves the issue of best execution, it introduces an extra transaction, which costs gas and it requires the trader to trust the exchange.

Intent/Reservation

At The Ocean, we solve the trustless market order problem in a way that guarantees best execution, minimizes transaction fees and recreates the patterns of traditional exchanges. Our matching engine is built using the matching strategy and it works as follows:

• The trader submits their intent to make a market order, specifying the amount they would like to buy or sell.
• The matching engine performs appropriate validation and then scans the order book to find the best priced orders with which to match.
• Those orders are placed on reservation, meaning that no other trader can take them in the meantime.
• The matching engine compiles the exact cost to execute the market order at the best price and fills out a 0x order with the appropriate details.
• This order is returned to the trader making the market order and they sign it.
• The signed market order is returned to the matching engine to be submitted to the Ethereum network along with the orders that had been placed on reserve. The are submitted to the 0x contract using BatchFillOrKill to guarantee that no order is filled unless all orders are filled.

Astute readers may be asking what happens if the user chooses not to sign the order that they’ve been provided with. To deal with this situation, which we’ve dubbed “flaking”, we’ve created a reputation system that imposes penalties on traders that behave badly (by flaking or otherwise acting irresponsibly).

We find that the intent/reservation system works well with our corporate philosophy in several ways:

• It provides best pricing which we believe is a necessary component to a fair and sustainable market.
• It requires user accountability which we can achieve because we have user accounts as part of our KYC/AML compliance.
• The additional round trip to the server provides an implicit speed bump to limit potentially price manipulative trading practices.
• We believe in design and engineering at the highest level. There are significant challenges to implementing this mechanism, which we took head on because we’re committed to creating the best possible product, and we believe we have done so.

Further Research

While we are convinced that the intent/reservation approach to trustless market orders provides a scalable, robust solution, we are actively engaged in improving our matching engine to prevent the possibility of flaking and reduce gas costs. With the coming release of 0x v2, we see several plausible paths forward including forwarding contracts, a smart funnel and eventually a state channel/plasma based solution that will allow orders of magnitude improvements in speed and gas efficiency. These are the very early days of the decentralized economy and we’re very excited to be engaged in solving these problems.

__________________________

Have some thoughts or comments? Join our Telegram to chat with our team!

Follow us on Twitter at @TheOceanTrade or subscribe to our newsletter to stay in the loop.