This post is a continuation of part 1, which provided an introduction to blockchain race conditions, front-running, the 0x protocol specification and presented two ways that 0x protocol may be used to implement a decentralized exchange that eliminates front-running and trade collisions by setting the 0x order schema’s taker parameter to an externally owned account (EOA).

There are a variety of ways that 0x protocol may be used that eliminate front-running and trade collisions, each with unique trade offs. The solutions presented in part 1 do so at the expense of networked liquidity, a unique property of 0x protocol that is described below. In this post, we will discuss ways 0x protocol may be used that prevent front-running and trade collisions while preserving networked liquidity by setting the 0x order schema’s taker parameter to a smart contract address.

Networked Liquidity

Networked liquidity refers to the seamless flow of orders through a network of interconnected exchanges, marketplaces and dApps. The interconnections act as a source of network effects, the phenomenon where a product or service gains additional utility as more people use it. Network effects are particularly important in marketplaces. Exchanges exist to aggregate buyers and sellers in one place — creating a pool of liquidity and, by extension, a more functional market. Networked liquidity allows for the same sort of aggregation, while remaining decentralized.

Orders can flow between relayers that implement the standard relayer API, allowing order book aggregation for relayers that are looking to add depth to their book as a bootstrapping technique or for groups of relayers that opt into some sort of fee sharing arrangement (see ZEIP12, this and this).

Orders can flow from relayers through dApps to their end users, providing end users the ability to frictionlessly acquire application-specific tokens or to make payments in any arbitrary token from directly within the dApp. We refer to this concept as token abstraction; you can learn more about token abstraction from our devcon 3 presentation.

Traders and dApp users can access all of these streams of order flow from a single standard wallet. No trading accounts. No need to put custody in the hands of a third party. No need to scatter one’s digital assets across multiple smart contracts. No deposits or withdrawals. This becomes increasingly useful as more types of digital assets and associated relayers enter the network.

Review

To summarize the key points that we have discussed up until now:

There are valuable advantages to networked liquidity. Networked liquidity can be achieved if each relayer in the network uses the open order book strategy discussed in part 1, but open order books are vulnerable to trade collisions and front-running. Solutions presented in part 1 eliminate front-running and trade collisions by setting the 0x order schema’s taker parameter to an EOA. In assigning each order to a specific counter party, there can be no free flow of orders and therefore no networked liquidity. We need a way to keep orders open so they can be filled by anyone, but we simultaneously need to bring structure to these disparate streams of order flow to prevent trade collisions and front-running.

The good news is that 0x protocol is designed in a modular way such that we can create novel solutions that sit one layer above 0x’s system of smart contracts. This will ultimately require us to set the 0x order schema’s taker parameter to a smart contract address. Let’s now take a look at how these smart contract interactions can work.

Chaining Smart Contracts Together

By setting the 0x order schema’s taker parameter to a smart contract address, we can force orders to be funneled through an arbitrarily complex pipeline of logic. This allows us to develop interesting smart contract systems on top of 0x while maintaining a clean separation between the respective bodies of code.

In the above diagram, 0x protocol’s Exchange smart contract is represented as a grey rectangle. The order shown on the left side of the figure will only be executed by the Exchange contract if it is passed in by the smart contract specified as the taker, which can be any arbitrary smart contract.

Some interesting things we can do:

Funnel orders through a contract that implements fee sharing for relayers that pool liquidity or for dApps that pull liquidity from relayers.

Funnel orders through a contract that allows a network of “wranglers” to liquidate a trader’s margin position if it falls below its collateral requirement, per the rate provided by a trusted price oracle. This could potentially be useful for projects like dYdX or Lendroid.

Funnel orders through a contract that requires the Ethereum addresses for each trader to be registered to a specific white list. A relayer that specializes in securities tokens could use this approach to ensure all traders accessing their order book have gone through a rigorous KYC/AML process. Even more interesting, one could outsource curation of the white list to an independent institution that specializes in compliance using something like Harbor or Polymath. This could allow any relayer to ensure security tokens are only accessible to accredited/KYC’d individuals but without the relayer having access to any sensitive data regarding the identity behind each Ethereum address.

Funnel orders through a contract that implements LoopRing like behavior where “ring miners” submit batches of matched orders to the blockchain and receive a portion of the fee or a spread.

Funnel orders through a contract that eliminates front-running and trade collisions by enforcing rules around trade execution, which we will explore in more detail below.

Note: while one can implement the above systems using version 1 of 0x protocol, the current smart contract architecture is designed such that these layer 2 contracts must (1) have access to msg.sender’s tokens and (2) forward trade proceeds to msg.sender after a trade is completed. ZEIP2 or ZEIP18 will simplify these types of contract interactions by decoupling msg.sender from taker , making it easier to create modular smart contract systems on top of 0x protocol.

Note: For an example of an interesting smart contract that plugs into 0x, check out the contract that we used for the ZRX token sale and explanatory diagram. TL;DR this contract executed the “Genesis Trade” which was just a huge sell order for 50% of the total supply of ZRX tokens, but divvied up equally across all ~12,000 people that registered to participate in our token sale.