Editing 0x (section)

= 2. Technology =

The 0x Project defines a peer-to-peer network of order book servers who are incentived to provide the service by receiving fees when a user elects to use their provided match.

This design presents multiple issues.

<span id="poor-scalability"></span>
== 2.1. Poor scalability ==

To progate open orders, the protocol specifies a broadcast algorithm where peers submit an order across the entire network. This routing algorithm is necessary to ensure that every order book server has the same amount of liquidity but it means that the protocol cannot scale to high transaction volumes.

<span id="race-conditions-with-matching"></span>
== 2.2. Race conditions with matching ==

0x doesn’t define enforcible matching. It is possible to submit an order across the network that is filled by multiple people (partially or in full) before a user has had chance to fill it themselves.

Since orders are filled asynchronously, order servers have no way to stay up to date with matches except to watch transactions confirm on the blockchain. This creates a race condition where users race to fill an order, wasting resources across the network and consuming unnecessary Ether as fees in the form of rejected on-chain transactions.

<span id="matches-are-unenforcible"></span>
== 2.3. Matches are unenforcible ==

A standard limit-based order book works by sorting all the sell orders from lowest to highest and all the buy orders from highest to lowest. The sell orders can then be put next to the buy orders to tell traders the bid-ask spread - a measure of the difference between the lowest price a seller is willing to sell at and the highest price a buyer is willing to buy at.

The bid-ask spread is useful because it can be used to ensure traders get access to accurate pricing information, knowledge of liquidity, and so fourth. But pricing information in 0x cannot be determined because matching is unenforcible. A person may indicate to a matching server they are after a certain trade but there is no part of the protocol that determines whether they go through with it.

This means that pricing cannot be determined since all open orders in the order book cannot be matched. Another consequence of this is that traders can never be ensured that they will get the best possible price for an order because they cannot be guaranteed to match against the tip of the order book.

<span id="incentives-ignore-the-cost-of-operation"></span>
== 2.4. Incentives ignore the cost of operation ==

0x defines an incentive system where matching servers are rewarded a fee from a user if they use a match that it provides. The issue is that for this to occur the matching server needs to store all broadcast orders and it has no way to guarantee that a match that it offers up will end up being used by a trader.

The consequence of this means that there is no way to ensure that a match server in 0x will be paid for their service. The protocol does not define any incentives for the cost of bandwidth, disk space, and so fourth which provides a poor reason to run the software.

The 0x token doesn’t make sense in this context.

<span id="suggested-fixes"></span>