Decentralizing the Order Book

Nick Valdez

Intro

With the emergence of bitcoin, block chain, or crypto technologies (whatever you want to refer them to as), a new paradigm and ideology of distributed protocols and systems has also emerged. This side project explores in an informal way (it’s a side project after all) how stock exchange and the order book can be re-designed to eliminate the all too common problem of front running, which in the past has been exploited by stock exchanges, big wall street banks, and high frequency trades who have access to super-fast computers that others do not.

Distributed Order Book Simulation

Participants are blue nodes, Miners are red nodes. Bid / ask trades are represented as small red dots. Block propagation between miner nodes is represented by white dots.

Inefficiencies in Centralized Order Books

The biggest inefficiency in a centralized order book is by far front running. The front running problem is particularly well highlighted in Michael Lewis’ Book “Flash Boys”. The centralized architecture of stock exchanges and order books lets some people exploit and rig the stock market. There are few different types of front running, but a good and real example that I recently read about should give you an idea of how the stock exchange can front run you.

From "The Man Who Solved the Market: How Jim Simons Launched the Quant Revolution" by Gregory Zuckerman

“Whenever Medallion traded Canadian dollars, the fund seemed to lose money. Almost every trade was a dud. It didn’t seem to make sense—the model said Medallion should be racking up money, but they were losing, over and over, every day. One afternoon, Berlekamp shared his frustrations with Simons, who called a trader on the floor of the Chicago Board of Trade to get his take on their problems. “Don’t you know, Jim?” the trader told him, with a chuckle. “Those guys are crooks.” Only three traders on the exchange focused on Canadian dollar futures, and they worked hand-in-hand to take advantage of customers naive enough to transact with them.”

“When Simons’s team placed a buy order, the brokers shared the information, and the traders immediately purchased Canadian dollar contracts for themselves, pushing the price up just a tad, before selling to Simons and pocketing the difference as profit. They’d do the opposite if Medallion was selling; the small differences in price were enough to turn the Canadian dollar trades into losers. It was one of Wall Street’s oldest tricks, but Berlekamp and his fellow academics were oblivious to the practice.”

Zuckerman, Gregory. The Man Who Solved the Market (p. 113). Penguin Publishing Group. Kindle Edition.

There are other types of front running that you can look up, but overall key takeaway here is that front running is possible because trading occurs through a centralized entity. The protocol forces you to place a lot of trust in this central entity.

Bitcoin + Incentive Engineering = Distributed Order Book

The question we are trying to answer here is how to match buyers’ and sellers’ trades and have them agree on a price. The protocol, shown in the simulation video above, is described below.

1. Participants (blue nodes) broadcast their buy or sell trades to all miners (red nodes) in the P2P network.

2. Miners validate bid/ask orders from their mem pool in order to prepare a block for the block chain. Miners validate by making sure the bidder has enough funds if it’s a bid order, or the seller actually possesses the financial instruments it is selling if it is an ask order.

3. Miners match bid and ask orders that pass the step validation. This where incentive engineering kicks in. The miner’s fee is the spread of the orders they match. Thus, the miner will be incentivized to match the highest bid with the lowest sell price.

4. Proof of work or Proof of state and block propagation by the miner.

Let’s take a closer look at why a miner is not incentivized to front run anymore:

1. Assume four orders arrive. 100 bid, 100 ask, 99 bid, 99 ask, all with the same volume.

2. The miner would be incentivized to match the 100 bid with 99 ask, keeping the 1$ spread. Net 1$ gain

3. If the miner decides to front run by:

A: Ignoring the 99 ask and submitting a 99.5 ask which improves their price by $0.5 but decreases the gains from the spread by an equivalent amount, netting only $0.5.

B: Ignoring the $99 ask and filling the order themselves at the best ask price, in this case $99, then the miner would gain $1 on the surplus.

C: Ignoring the $99 bid and submitting a worse bid (lower than $99),then the miner would not gain anything because they are selling undervalue.

As you can see, if the protocol allows miners to keep the spread between matched bid and ask orders (the surplus), there is no incentive to front run by:

A: Price improvements through ignoring or dropping orders.

B: Ability to prioritize their trades over others.

Other Notes about a decentralized protocol

Time precedence order matching in this system is not entirely possible due to the fact that trade orders are broadcasted in the P2P network and there can be delays. Thus, this system operates on price precedence. Orders with the best price will get matched first (best bid = highest bid price, best ask = lowest ask price).

This system also has similar if not the same assumptions the bitcoin network has on miners. ( trust that the majority of miner nodes behave honestly due to the incentives mentioned in the previous section ).

Due to the nature of the distributed system, order matching does not occur like it does in a continuous market. Instead, it acts like a call market (“In a call market, orders are placed over an interval of time and then executed as a batch”). Think of this as the participants broadcasting orders to miners, miners batching together orders and then executing a proof of work or proof of stake computation.

References

Clark, Jeremy, Joseph Bonneau, Edward W. Felten, Joshua A. Kroll, Andrew Miller, and Arvind Narayanan. ​ On Decentralizing Prediction Markets and Order Books​. In Workshop on the Economics of Information Security, 2014.

Andrychowicz, Marcin, Stefan Dziembowski, Daniel Malinowski, and Lukasz Mazurek. ​Secure multiparty computations on Bitcoin​. In IEEE Security and Privacy 2014.