This post outlines major development updates during the month of September.

Introducing Monthly Development Updates

Development updates will be released at the end of each month to summarize key highlights of the work completed by the 0x core team. They will cover the 0x.js Javascript library, wiki (which contains tutorials and strategies relayers might find useful), 0x standard relayer API and Portal updates.

Changes to 0x.js

Return upon transaction broadcast instead of when mined. 0x.js methods that involve a transaction being broadcast to the Ethereum network used to only return once the transaction had been successfully mined. This meant that applications built on top of 0x.js were unable to build UI’s that would notify users upon transaction broadcast. Since it can take tens of seconds for a block to be mined, this led to a poor user experience. We therefore refactored 0x.js to instead return the transaction hash upon successful broadcast, and added an additional method (awaitTransactionMinedAsync) for clients who want to await for the transaction to be mined.

0x.js methods that involve a transaction being broadcast to the Ethereum network used to only return once the transaction had been successfully mined. This meant that applications built on top of 0x.js were unable to build UI’s that would notify users upon transaction broadcast. Since it can take tens of seconds for a block to be mined, this led to a poor user experience. We therefore refactored 0x.js to instead return the transaction hash upon successful broadcast, and added an additional method (awaitTransactionMinedAsync) for clients who want to await for the transaction to be mined. Added validation methods to public API. 0x.js performs a lot of client-side validation before calling the smart contract methods that fill/cancel orders. We do this in order to return useful error messages to clients and to save users gas costs by preventing them from sending transactions that are guaranteed to fail. We decided to make our internal validation methods public since they are independently useful to relayers who wish to validate or prune orders sitting on their orderbook. There are many reasons an order might become unfillable, and these validation methods do the heavy lifting in making sure an order is still fillable.

0x.js performs a lot of client-side validation before calling the smart contract methods that fill/cancel orders. We do this in order to return useful error messages to clients and to save users gas costs by preventing them from sending transactions that are guaranteed to fail. We decided to make our internal validation methods public since they are independently useful to relayers who wish to validate or prune orders sitting on their orderbook. There are many reasons an order might become unfillable, and these validation methods do the heavy lifting in making sure an order is still fillable. Support Web3 1.X providers. Although Web3 1.X is still in Beta, it has become the default npm install package and has thus seen increased usage. Although 0x.js still uses the more stable Web3 0.X under-the-hood, it now allows users of 1.X to pass in their provider to 0x.js. Internally we have normalized the interface for both types of providers so that either works with our library as expected.

Although Web3 1.X is still in Beta, it has become the default npm install package and has thus seen increased usage. Although 0x.js still uses the more stable Web3 0.X under-the-hood, it now allows users of 1.X to pass in their provider to 0x.js. Internally we have normalized the interface for both types of providers so that either works with our library as expected. Ability to set unlimited allowance (gas efficiency). There is now a method in 0x.js that sets a user’s ERC20 token allowance to the maximum unsigned integer value (2²⁵⁶-1). Setting a users allowance to a very large amount reduces friction in relayer UI’s so that a user only needs to set it once and can trade as many times as they wish. In addition, we have special-cased this maximum amount in both the implementation of our WETH and ZRX token contracts such that the allowances are not updated (saving ~10k gas cost per trade), if set to this max amount. We are currently requesting feedback on an EIP to make this an optional amendment to the ERC20 standard.

There is now a method in 0x.js that sets a user’s ERC20 token allowance to the maximum unsigned integer value (2²⁵⁶-1). Setting a users allowance to a very large amount reduces friction in relayer UI’s so that a user only needs to set it once and can trade as many times as they wish. In addition, we have special-cased this maximum amount in both the implementation of our WETH and ZRX token contracts such that the allowances are not updated (saving ~10k gas cost per trade), if set to this max amount. We are currently requesting feedback on an EIP to make this an optional amendment to the ERC20 standard. Additional tokenRegistry methods. We’ve added several more tokenRegistry methods to 0x.js to make it easier for clients to query the registry effectively by token name and symbol.

Release of the 0x Standard Relayer API Draft

The 0x Protocol is an open standard. Because of this, we expect many independent applications to be built on top of it (e.g dApps wanting token abstraction or exchange functionality, trading bots, market makers, etc…). In order to make it easier for anyone to source liquidity that conforms to the 0x order format, relayers can opt-in to implementing a set of standard relayer API endpoints. In doing so, they allow any client that has built an API integration that conforms to the standard relayer API to access the orders on their orderbook. This is a work in progress and we refer to the initial release as the standard relayer API v0.

Creation of the 0x Wiki

The 0x wiki is designed to be a resource for the entire 0x community. It sources its content from the open-source 0x Wiki Github repo that anyone can submit edits or new articles to. Many articles will be geared towards helping relayers but others will be for the community at large, such as the list of projects that are/will be using the 0x protocol or guides on how to verify custom tokens when using Portal.

Documents for Relayers :

Setup an Infura Node . Infura is a service that provides scalable Ethereum node infrastructure for dApps with significant traffic. Ethereum nodes were not built to act as server backends and have significant performance shortcomings when used in this way. In order to optimize Ethereum nodes for a server-like environment, Infura has had to change/omit some of the expected behavior of an Ethereum node in key ways. This document will outline what these changes were and how you can get Infura to play nicely with 0x.js.

Infura is a service that provides scalable Ethereum node infrastructure for dApps with significant traffic. Ethereum nodes were not built to act as server backends and have significant performance shortcomings when used in this way. In order to optimize Ethereum nodes for a server-like environment, Infura has had to change/omit some of the expected behavior of an Ethereum node in key ways. This document will outline what these changes were and how you can get Infura to play nicely with 0x.js. Setup a TestRPC Instance. In order to run 0x.js methods that interact with the Ethereum blockchain (i.e filling an order, checking a balance or setting an allowance) you need to point your Web3 Provider to an Ethereum node. Because of the ~12 second block times, during development it is best to use TestRPC a fast Ethereum RPC client made for fast testing and development.

In order to run 0x.js methods that interact with the Ethereum blockchain (i.e filling an order, checking a balance or setting an allowance) you need to point your Web3 Provider to an Ethereum node. Because of the ~12 second block times, during development it is best to use TestRPC a fast Ethereum RPC client made for fast testing and development. Web3 Explained. When instantiating a new instance of the 0x.js library, we require that you pass in a Web3 provider. Since there doesn’t seem to be great documentation on what exactly a Web3 Provider is, we thought we’d fill the gap.

When instantiating a new instance of the 0x.js library, we require that you pass in a Web3 provider. Since there doesn’t seem to be great documentation on what exactly a Web3 Provider is, we thought we’d fill the gap. Relayer Strategies. Relayers can adopt various styles when it comes to managing the orders of their users, thanks to the flexibility of the 0x protocol. For instance, one strategy, which we call centralized matching, involves the relayer acting as a taker and batch filling orders that are compatible, removing the need for users to fill the orders themselves. Another strategy would be to act like a reserve manager, where the relayer could provide its own liquidity by frequently posting large orders with short expiration times. Users could then always trade at a reasonable current market price, similar as to how Shapeshift and Changelly operate. More strategies are available on the wiki.

Changes in Portal (OTC)

0x OTC has been re-branded as 0x Portal, as we envision a slew of upgrades and features to be added over time. Portal will not only allow over-the-counter trades, but will be a one-stop-shop for all things ERC20 token related. Our goal is to build the gold standard of ERC20 token wallets, where users can view their token balance, trade with known counter-parties directly via the Øx protocol, and explore transactions on the blockchain.

Ability to send ERC20 tokens. It is now possible to send tokens via Portal using the SEND button in the Balances section.

It is now possible to send tokens via Portal using the SEND button in the Balances section. Trading custom token with warnings. 0x hosts a token registry smart contract containing major ERC20 token addresses that have been verified to be legitimate. However, users might want to trade and send tokens that are not part of this registry. In the past, fake tokens with the same name and symbol as legitimate tokens were created and users were tricked into exchanging valuable tokens for worthless ones. To mitigate this risk, we now add warnings when filling any order that contains unregistered tokens to ensure that users double-check the tokens authenticity before filling the order.

0x hosts a token registry smart contract containing major ERC20 token addresses that have been verified to be legitimate. However, users might want to trade and send tokens that are not part of this registry. In the past, fake tokens with the same name and symbol as legitimate tokens were created and users were tricked into exchanging valuable tokens for worthless ones. To mitigate this risk, we now add warnings when filling any order that contains unregistered tokens to ensure that users double-check the tokens authenticity before filling the order. Token tracking. To improve efficiency, Portal allows you to only track the tokens you are interested in, including custom tokens. These tokens will be stored in your browsers local storage and will be available whenever you open Portal.

Conclusion

To get a higher-level overview of the direction in which 0x development is headed, please read the 0x Development Roadmap Medium post. Our current focus is on facilitating the process of starting relayers, both by creating and improving the tools available and by offering our help and guidance to the teams building them. It is therefore important that every potential relayer contact us as soon as possible to make sure we can help them avoid common pitfalls and make sure they have all the tools and support they need to succeed.