Recently the 0x project team announced 0x version 2. Today we’re happy to announce that OpenRelay supports 0x v2 on Kovan!

Feature breakdown

0x v2 has a bunch of new features. Right now we support all of the old features from v1, and a small handful of the new features. Some of the other features we plan to support before 0x v2 is live on mainnet, while others we may never support.

Token Types

One of the big enhancements to 0x v2 is support for a wider range of token types. 0x v2 allows trading of both ERC20 and ERC721, and it has the capability to add new token types in the future without requiring an upgrade to the core exchange contract.

Right now we still only support ERC20 tokens. We aim to add support for ERC721 tokens in the next few weeks, but there are a handful of underlying components that we still need to update to validate ERC721 orders.

Signature Types

0x v2 supports several new ways of signing orders. The ones we currently support include:

The one we plan to support soon is:

The signature types we’re undecided on:

Standard Relayer API

Our current implementations supports this draft of the 0x Standard Relayer API for 0x v2. That draft is still a work in progress, and has had significant updates in the hour prior to posting this blog post. It is unclear what the final form will look like, but we expect that we will need to make further adjustments as the new version of the Standard Relayer API is finalized.

Bulk Cancellations

One feature of 0x v2 that is handy for traders is bulk order cancellation. You can now call Exchange.cancelOrdersUpTo(epoch), and any orders you have created where order.salt < epoch will be considered cancelled. This complicated our pruning process and order validation pipeline a bit, but we couldn’t support 0x v2 without supporting bulk cancellations or we would end up with cancelled orders we hadn’t pruned from our order book.


It turns out that just supporting Kovan was a bit of a hassle for OpenRelay. OpenRelay uses Geth’s Ethereum Client code for making RPC calls. Kovan is a proof-of-authority network that only runs on Parity. Because Geth’s code for making RPC calls validates blocks in a way that doesn’t make sense for Kovan, our block monitor was unable to process blocks for Parity.

To support Kovan, we’ve dusted off our old JavaScript block monitor microservice. Our old block monitor does not handle chain reorganizations as cleanly as the one we’re running on mainnet, but as Kovan is a proof-of-authority network block reorganizations should be few and far between.

Deprecated OpenRelay Feature

One feature we’re saying goodbye to is OpenRelay’s binary order format, which was previously supported by our REST API as an extension to the Standard Relayer API. The binary format made sense when every order was exactly 377 bytes, plus 64 bytes indicating fills and cancellations. But support for new asset and signature types means that the size of a 0x order is now variable. This would have complicated our binary format quite a bit, and while we still use an RLP encoded version internally, we don’t plan to expose that as part of our public REST API going forward.

Using 0x v2 on

As of right now, support for 0x v2 is live at based on the May 25th draft of the Standard Relayer API. If you need any help getting started, reach out to us on gitter!

Open Source Implications

For those following along with OpenRelay the Open Source project, these changes are a pretty big deal. While supports both versions 1 and 2 of 0x concurrently, our code base only supports one at a time. We are essentially running both versions of the software in our production environment, and have our load balancer routing requests to the right containers based on the URL.

If you need to continue using the v1 code base, you can find it on the support/0xv1 branch in our Github repository. We will continue to maintain that branch for as long as we support the 0x v1 exchange contract in our production environment.