Compliant peer to peer trading

At 0x, we envision a world in which all forms of value are represented as tokens on public blockchains. Public blockchains are compelling because they are permissionless and globally accessible, properties that are especially attractive for financial markets which have historically been subject to geographic fragmentation among other economic inefficiencies. While institutions would benefit from access to global financial markets that run on blockchain rails, they are generally subject to additional compliance requirements depending upon the jurisdiction in which they operate. This post will explore ways to apply flexible (and optional) compliance rules to trading activity on 0x protocol, paving the way for institutional adoption. We begin by introducing the concept of a permissioned token and demonstrate how Ethereum smart contracts may be used to automatically enforce rules over token ownership. Next, we explore compatibility challenges between permissioned tokens, centralized exchanges and decentralized exchanges. Finally, we introduce the concept of a permissioned liquidity pool which allows 0x relayers to enforce arbitrary rules over trades they help facilitate. Permissioned Tokens Permissioned tokens place restrictions on transfers directly within a token’s contract code, limiting ownership to Ethereum addresses that meet certain requirements. Aside from transfer restrictions, these tokens can behave like any other ERC20 token that one may be familiar with. The most common implementation of a permissioned token is straight forward: every time the token's transfer function is invoked, the token contract checks a Registry contract to see if the recipient is registered to a whitelist. The transfer will only complete successfully if the recipient is registered to that whitelist. In the above image, squares represent smart contracts and the circle represents an Ethereum account. Function calls are depicted as arrows that point from caller to callee. In (1), an Ethereum account is attempting to transfer a balance of permissioned ERC20 tokens to some recipient (not pictured). In (2), the permissioned ERC20 token contract is checking to see if the intended recipient is listed within a Registry contract before executing the transfer; (3) depicts the Registry’s response of true/false.Numerous teams are working on permissioned tokens: Harbor’s recently released R-Token standard — in combination with their compliance products — will facilitate compliant tokenized securities offerings to accredited investors and institutions across jurisdictions. OpenFinance created the Smart Securities Standard (S3) with a similar goal in mind and plans to launch a fully compliant secondary market for securities tokens that uses 0x protocol. Polymath created the ST-20 token for tokenizing securities on their platform/protocol. More recently, Zeppelin proposed a general framework (TPL) for creating permissioned tokens and delegating Registry write permissions. Compatibility with centralized exchanges For a permissioned token to be offered through a centralized exchange, the manager of the associated Registry contract must whitelist all public keys used by that exchange. This is a costly exercise as centralized exchanges typically generate a unique deposit address for each {customer, token} combination and additional public keys must be whitelisted to allow a centralized exchange to move tokens between deposit addresses and cold storage. Adding Ethereum addresses to the Registry is not free and would require significant coordination between the Registry manager and the centralized exchange. Compliance is another issue. The Registry manager cannot easily confirm that all of a centralized exchange’s users meet the requirements that have been set forth for inclusion in the Registry. If a regulator were to ask the Registry manager for proof that all trades on a centralized exchange are compliant, the manager would have no way to provide proof as the centralized exchange’s internal activity is opaque. Compatibility with decentralized exchanges Ethereum-based decentralized exchanges that require traders to deposit tokens from their wallet into a smart contract are incompatible with permissioned tokens — this includes OasisDEX, EtherDelta/ForkDelta, IDEX and Kyber. 0x protocol’s pipeline of smart contracts is designed to pull tokens directly from traders’ Ethereum accounts at the time a trade is executed (wallet-to-wallet trading). Transfer restrictions baked into a token automatically apply to all associated 0x trades limiting trading activity to users with the same set of permissions. In the above image, squares represent smart contracts and the circle represents an Ethereum account. Function calls are depicted as arrows that point from caller to callee. In (1), an Ethereum account (Taker) is attempting to execute a trade by passing an order into the 0x pipeline of contracts. Taker wants to purchase a permissioned ERC20 token in exchange for a standard ERC20 token. In (5), the permissioned token is checking to see if Taker is listed within a Registry before executing the transfer. If Taker is not listed within the Registry contract, the entire transaction will fail and revert. Permissioned Liquidity Pools Permissioned tokens are ideal for assets like securities that have strict regulatory requirements around ownership. Regardless of whether a token is permissioned or not, institutions and relayers may need to satisfy additional compliance requirements in order to trade them. Version 2 of 0x protocol will allow developers to plug their own custom smart contracts into the 0x pipeline (see ZEIP18) extending its functionality. This will open up a variety of exciting possibilities including permissioned liquidity pools which can be used to ensure a collection of 0x orders is only accessible to Ethereum addresses that meet certain requirements. The way that a relayer creates a permissioned liquidity pool is as follows: The relayer deploys an Ethereum contract — which we will refer to as Filter — that accepts one or more 0x orders and checks that the orders satisfy a set of conditions before forwarding them onto the 0x Exchange contract for settlement. The relayer can enforce any set of conditions they want in a Filter contract, but for this example we will require that both parties to a trade are listed within a KYC registry. The relayer only accepts orders onto their orderbook if the order.sender parameter is set to the Filter contract’s address. If a taker attempts to bypass the Filter contract by passing one of these orders directly into the 0x Exchange contract, the transaction will fail. The relayer’s orderbook now consists of orders that can only be executed if passed into the 0x Exchange contract by the Filter contract, ensuring that all traders accessing the orderbook satisfy KYC requirements. Trading permissions may be encoded into a Filter contract that ensures one or both parties to a trade are listed in a Registry contract. This registry lookup is depicted as step 2 in the above diagram. Relayers may enforce that all orders in their order book specify the Filter contract as order.sender, thereby ensuring their order book is only accessible to a specific subset of Ethereum addresses.Since permissioned liquidity pools are optional, tokens can be traded in permissioned and non-permissioned liquidity pools simultaneously. The only difference between the two pools is the set of traders that are able to access them (there can be overlap). Institutions with specific compliance requirements can trade with peers that satisfy the same set of requirements, while traders without these limitations can opt-in to accessing both pools. Solidity pseudo code Creating a Filter contract is relatively straightforward. The Solidity pseudo code provided below defines a conditionalFillOrder function that checks that both parties to a trade are listed within an arbitrary Registry contract before executing a trade. function conditionalFillOrder( Order order, uint takerTokenFillAmount, bytes signature) public{ require(registry.isMember(order.maker)); require(registry.isMember(msg.sender)); exchange.fillOrder(order, takerTokenFillAmount, signature);}; The clean separation between the 0x pipeline, Filter and Registry contracts makes it possible for multiple relayers to reference a single Registry. This is convenient for traders as it allows them to verify their identity once and bring this on-chain attestation with them to different relayers and dApps. Since the Registry contract is managed by a KYC provider that presumably keeps user details private, traders don’t need to trust relayers with their personal information and relayers don’t need to go through the trouble of acquiring and managing this information. Final Thoughts The next 12 months will be defined by the emergence of securities tokens and institutional participation in the token economy. While irrational exuberance surrounding ICOs may be waning, a growing hunger for compliant tokenized securities has taken its place. The same chaotic cycle will repeat itself with frenzied outbursts of innovation that take us in new unforeseen directions. However, this time there will be some semblance of rules and an opportunity for institutions to come along for the ride. A major emerging theme will be encoding complex compliance rules into smart contracts. 0x protocol’s modular architecture makes it ideal for peer-to-peer exchange in a world where complex rules are the status quo.