We describe ZRX a protocol that facilitates low friction peer-to-peer exchange of ERC20 tokens on the Ethereum blockchain. The protocol is intended to serve as an open standard and common building block, driving interoperability among decentralized applications (dApps) that incorporate exchange functionality. Trades are executed by a system of Ethereum smart contracts that are publicly accessible, free to use and that any dApp can hook into. DApps built on top of the protocol can access public liquidity pools or create their own liquidity pool and charge transaction fees on the resulting volume. The protocol is unopinionated: it does not impose costs on its users or arbitrarily extract value from one group of users to beneﬁt another. Decentralized governance is used to continuously and securely integrate updates into the base protocol without disrupting dApps or end users.

Each order is a data packet containing order parameters and an associated signature. Order parameters are concatenated and hashed to 32 bytes via the Keccak SHA3 function. The order originator signs the order hash with their private key to produce an ECDSA signature.

1. Point-to-point Orders

Point-to-point orders allow two parties to directly exchange tokens between each other using just about any communication medium they prefer to relay messages. The packet of data that makes up the order is a few hundred bytes of hex that may be sent through email, a Facebook message, whisper or any similar service. The order can only be ﬁlled by the speciﬁed taker address, rendering the order useless for eavesdroppers or outside parties.

2. Broadcast Orders

For liquid markets to emerge, there must be public locations where buyers and sellers may post orders that are subsequently aggregated into order books i.e. exchanges. Building and operating an exchange is costly and the protocol we have described so far does not provide an incentive for someone to take on such an expense. Broadcast orders solve this issue by allowing anyone to act as an exchange, maintain an order book (public or private) and charge transaction fees on all resulting liquidity. We refer to entities that host and maintain an order book as Relayers rather than exchanges. Where an exchange must build and operate proprietary infrastructure, execute trades and handle user funds, Relayers merely facilitate signaling between market participants by hosting and propagating an order book that consists of generic messages. Relayers do not execute trades on behalf of market participants as this would require market participants to trust the Relayer. Instead, Takers execute their own trades.

The message format for broadcast orders includes two changes to the point-to-point message format to facilitate public exchange and incentivize Relayers. First, broadcast orders do not specify a taker address, allowing a broadcast order to be ﬁlled by anyone that happens to intercept it. Second, broadcast orders include feeA, feeB, and feeRecipient parameters which specify transaction fee values and an address used by a Relayer to collect transaction fees. The exchange smart contract transfers these fees to feeRecipient if and when an order is ﬁlled. Figure 3 presents the sequence of steps Makers and Relayers use to negotiate transaction fees in a trustless way.