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:

• EIP712 The 0x Project team ran an initiative to get EIP712 accepted by the larger Ethereum community. It is a way to sign structured data, which allows Ethereum clients to show their users much more detail about the data they’re signing. We hope this will become the primary way that 0x orders are signed.
• EthSign — This is the old way of signing orders, as supported in 0x v1. Users who sign orders with EthSign only see a hash of the data they’re signing, which could enable a malicious dApp to lie about what message the user is signing. We support EthSign for legacy purposes, as many clients don’t yet support EIP712, but we hope dApps building on OpenRelay will take EIP712 support seriously.
• Trezor — Trezor hardware wallets have a slightly different signature format than EthSign, but generally the same security concerns.

The one we plan to support soon is:

• PreSigned — For this signature type, a maker can make a contract call to notify the Exchange contract that they authorize a given order. The Exchange contract keeps track of the approval, and when it sees the order again considers it to be valid. Currently, we validate signatures in our Ingest service, and for performance reasons we do not allow our Ingest service to make RPC calls against the Ethereum blockchain. Supporting this, as well as some of the other signature types, will require a separate signature validation microservice, to validate on-chain signatures asynchronously.

The signature types we’re undecided on:

• Wallet — Wallet signature types allow contracts to act as the maker of an order, and gives them a function they can implement to say “Yes, I approve this signature.” There’s a good chance OpenRelay will never support this signature type. You can read here about how we prune our large order book, and the Wallet signature type presents some serious scalability problems for pruning our order book. It would be possible for someone to write a contract that would stop considering signatures valid without giving us any way to know an order had been invalidated. Thus, we will probably never support the Wallet signature type for open-ended wallet addresses — though we might support a whitelist of wallet contracts that we have verified.
• Validator — The validator signature type is very similar to the Wallet signature type, and has the same general problems for pruning the order book in a scalable manner. Our plan at the moment is to support a limited whitelist of validator contracts that we have vetted. Anyone who wishes to trade tokens from a wallet contract will be able to approve one of our whitelisted validators to validate on their behalf, so we believe this should cover most of the needs for trades initiated by contracts without having to offer open-ended support for validators. If you’re interested in developing a validator contract, contact us to make sure that your validator contract is designed in a way that we could support it. If there aren’t any validators on our whitelist as the mainnet launch approaches, we will probably build our own.

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.

Kovan

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 OpenRelay.xyz

As of right now, support for 0x v2 is live at https://api.openrelay.xyz/v1/ 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 api.openrelay.xyz 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.