This post outlines major development updates during the month of November 2017.

This November, we have been hard at work on several major projects including Order Watcher, 0x Connect, 0x Deployer and transitioning our Typescript codebase to a mono repo architecture. We are excited to update you on the status of these various projects, some of which you can use today!

Changes to 0x.js

Order Watcher. Last month we introduced the concept of the Order Watcher. The Order Watcher allows 0x relayers to perform efficient order book pruning and traders to more quickly react to changes to an order book. It does this by notifying these parties whenever a transaction reaches the Ethereum mempool that could impact the validity of an order they care about. This new feature is close to being completed, and a standalone announcement, as well as several wiki articles will be published soon.

Last month we introduced the concept of the Order Watcher. The Order Watcher allows 0x relayers to perform efficient order book pruning and traders to more quickly react to changes to an order book. It does this by notifying these parties whenever a transaction reaches the Ethereum mempool that could impact the validity of an order they care about. This new feature is close to being completed, and a standalone announcement, as well as several wiki articles will be published soon. Customizable gas price & limits. Developers can now pass in a custom gasPrice and gasLimit for any transaction sending method in 0x.js. GasPrice could already be set globally, but can now be overridden for individual method calls. Gas estimation is now only performed if a specific gasLimit is not supplied.

Developers can now pass in a custom gasPrice and gasLimit for any transaction sending method in 0x.js. GasPrice could already be set globally, but can now be overridden for individual method calls. Gas estimation is now only performed if a specific gasLimit is not supplied. Small fixes & refactors. Numerical properties in transactionReceipts now contain numbers rather then hex strings. You can now specify a timeout when calling awaitTransactionMinedAsync (special thanks to Luke Autry at ERC dEX for this addition). Several tweaks were made to the subscription interfaces for ergonomic reasons.

Standard Relayer API and 0x Connect

Since introducing the 0x standard relayer API last month, we built a Javascript library, called 0x Connect, that makes it easy to interact with any relayer’s API that is compliant with the 0x standard relayer API v0. This way decentralized applications and traders can build a single integration that connects to multiple relayers. You can read more about 0x Connect in the 0x Connect announcement, introductory tutorial and documentation.

We have decided to move all our Typescript codebases into a single mono-repo. The reasons for this re-org were numerous including the ability to have a single lint, build, test and release process, easily coordinate changes across packages and to have a natural way of re-using code between sub-packages without getting stuck in dependency hell. Mono repos have always been preferred by large tech companies (Google, Facebook, etc…) but have been rarer amongst open source projects. This trend has been changing, with many projects including React, Babel, Parity and Geth all embracing mono repo architectures. We will still be publishing sub-packages independently from one another, and a clear separation of concerns will be maintained.

After using Truffle for our compilation and deployment needs, we have decided to take the leap and build our own replacement tool. 0x Deployer is a simple command-line tool that allows us to easily manage different deployed versions of specific contracts across multiple network. It also allows us to compile contracts with specific versions of Solidity. This is a tool we intend to use internally, but it is possible that we eventually publish it as a standalone package for others to use as well.

We had many requests to make it easier for relayers to add Ledger Nano S hardware wallet support to their platforms. As a first step, we have been working on a Ledger subprovider for use with web3-provider-engine. Relayers will be able to pass this Ledger subprovider into the 0x.js library, allowing them to easily add Ledger support to their platforms as an alternative to Metamask. This is still a work in progress, but we hope to release it very soon.

Trade tokens from your Ledger hardware wallet

Non-Fungible Tokens (ERC-721) Support

Currently, the 0x protocol only supports exchange between ERC-20 compliant tokens, which are the most common type of tokens on the Ethereum network. ERC-20 tokens are said to be fungible, like Ether and Bitcoin, where each token within a given token contract is considered identical. For instance, every ZRX is equivalent and identical to every other ZRX token. However, not all assets are fungible, for example one can own thousands of cryptographic kitties but each CryptoKitty has a one-of-a-kind digital genome that maps to unique physical characteristics.

This is the decentralized future we are fighting for.

We believe this class of assets will be an important part of the tokenized future, where physical and digital real estate, gaming items, ENS domains and other unique, non-fungible assets will be represented on the Ethereum blockchain. This is why we are conducting research into exchange between ERC-20 and ERC-721 tokens. Although we are hopeful that this could be added in the 0x protocol V2 (Q2 2018), ERC-721 is still actively being discussed and maturation of this token standard might be required before adapting 0x to support it.

Front-Running and Griefing Research

Front-running and griefing are attacks that many decentralized applications need to guard themselves against. In the case of 0x, these attacks are not inherently dangerous, but could lead to wasted gas, unpleasant user-experiences and allow certain agents, like miners, to profit at the expense of others. We spend a considerable amount of time discussing and researching solutions to these problems with our community members and we plan on publishing an article solely on this topic by the end of the year. In the mean time, you can read about how Paradex is addressing front-running and griefing in their most recent blog post.

As a reminder, we would love more community feedback on what should be included in the next release of the protocol. If you are interested in contributing, please take a look at the 0x improvement proposals (ZEIPs) and join the conversation about how to best accomplish the suggested changes. If you have a new improvement in mind, create a new issue outlining your proposal.