If you follow the decentralized trading space, you’re likely aware of the SEC’s charges against EtherDelta’s founder. Obviously this has some implications for OpenRelay, so we want to talk about what we’re doing to stay on the right side of the law.
At the time of this post, OpenRelay has only facilitated trades for a small handful of tokens on the Ethereum Mainnet, and none of them resemble securities. The tokens that have been traded on OpenRelay to date are either utility tokens like ZRX and WETH or novelty tokens like MBGN. We are confident that, to date, we have not facilitated any trades that violate US securities law.
As we have discussed in several prior blog posts, OpenRelay has never set out to be a platform for trading tokens that are thinly veiled securities. As Greg discussed in our last blog post, tokens can represent a wide variety of instruments, and securities are only a small fraction of the potential use cases for tokens. OpenRelay wants to target the whole of the token space, but if we have to exclude tokenized securities from our offering, that doesn’t change much about our plan.
To make sure that OpenRelay does not become a platform for trading securities, we are going to make several compliance related updates, both to our software and our operational process.
Terms of Service
We will soon release updates to our terms of service. We have had a terms of service in place since we first launched OpenRelay, but we have not had a way to ensure that users of our API have seen or agreed to the terms of service. After the update to our terms, we will require that order makers sign the terms of service with their private key and submit the signature to our API before they are able to submit orders to our API. We aim to make this a smooth, one time process, and it should only effect the makers of orders.
OpenRelay was built to accept orders for any asset pairs supported by the 0x protocol. So far we have not developed any capability to restrict specific assets or asset pairs from being traded, but to ensure that we can avoid the exchange of securities, we will implement blacklist capabilities and begin to proactively maintain a blacklist.
Note that we are fairly adamant about implementing these restrictions with a blacklist (to exclude known security tokens) rather than a whitelist (to allow only approved tokens). We can imagine many scenarios where someone might wish to create a brand new token and immediately offer that token on OpenRelay. If each token is subject to a vetting process before it can be used in orders, that hurts a lot of potential use cases.
Even for tokens which we decide to restrict for trading, we may have exceptions for certain token pairs. For example, if an order is offering a token in exchange for NotCoin, that essentially means that nothing is being traded and trading regulations may not apply.
At widgets.openrelay.xyz we have a toolkit of widgets people can embed on their own websites to start trading. The list of tokens originally supported by the toolkit had been vetted for accuracy, in that the name, symbol, and decimals correctly mapped to the token addresses. Originally, we created that list of tokens to support Fling, and when we started making trading widgets we grabbed the token list we already had.
Our mistake was that we had not reviewed the tokens for whether or not they might be construed as a security. That wasn’t a concern for Fling, which is not about trading, but is a concern for widgets intended for the trading of digital assets. To ensure compliance with securities law, we have drastically reduced the list of tokens supported by our trading widgets to ones we are confident are not securities. Once we come up with a review process, we will start adding tokens back into our trading widgets.
We will keep our list of tokens available for use cases like Fling that aren’t about trading, but our trading widgets will only include tokens that have been evaluated from a securities perspective.
Another feature we were already planning is called Order Pools. The idea of order pools is that we will create partitioned groups of orders within OpenRelay that have their own constraints in terms of what orders can be uploaded to the pool, and what orders should be visible through the pool.
Anyone who wants to will be able to create their own order pools, and we will have some premium options for order pool owners. Order pools will have lots of potential applications, letting different affiliates create different fee structures and otherwise constrain what orders can be uploaded to their pools.
From a securities perspective, we may eventually partner with an affiliate who is interested in offering securities and willing to handle the legal hurdles involved. Order pools could allow those affiliates to impose the constraints they are legally obligated to impose while sharing OpenRelay’s order book management infrastructure.
Keep an eye on the blog for updates as Order Pools start to come online.
Open Source Implications
Most of what we’ve talked about here deals specifically with OpenRelay.xyz, our hosted instance of OpenRelay. The constraints we are imposing will be implemented in our open source projects, but will be applied primarily through our hosted services. If someone chose to host their own instance of the OpenRelay services, we cannot constrain the tokens they allow on their platform.
In general features like a blacklisting capability will be implemented in OpenRelay, but the specific set of blacklisted tokens will be data stored in our database. We cannot control whether third parties running our software include the same set of tokens, but they should be aware of the legal ramifications.
More To Come
You can expect to hear more from OpenRelay on the subject of tokenized securities. We plan to explore some of the historical context of securities law, and look at what smart contract technology can do to solve some of the problems these laws were created to solve. Keep an eye on the blog for more.