Security token code and the future of R-token

If you want to issue a tokenized or “programmable” security, you will need some code to program. There are an increasing number of ERC20 token formats to handle securities, including ST20 from Polymath, R-token from Harbor, and DS from Securitize.io. I have heard rumors that Tokensoft and New Alchemy are preparing their own token formats. I suspect they are adding to the noise because it is hard to find code that is truly open source and useful for advisors and issuers that want to design tokenized securities. Each vendor is trying to build its own walled garden, not a globally unified security market. It’s time to start consolidating the formats, and opening up participation. In this article, we will cover the basic requirements for a security token. We will also describe our own work to improve R-token, open it up, merge it with ST20, and connect it to DS. Harbor introduced their idea for a simple and upgradeable whitelist token last January as “R-token”. We adopted it and we have built it into a sophisticated machine. However, Harbor appears to have abandoned it. Their last code update was on , and they have not responded to calls or emails during the past few months. April 5 We have filled out R-token and proposed some simplifications and improvements, and added those capabilities to ST20. The next step is to merge that work with other formats to make a more standard and more open foundation. Security tokens have unique requirements A security token has basic requirements that are different from the requirements of a cryptocurrency. Whitelisting of qualified investors All of the tokens that I describe here can do whitelisting, which means that they keep a list of blockchain addresses that represent investors that are qualified to receive a security. Then, they prevent the transfer of the token to anyone that is not on the list. The most basic investor qualification function is KYC/AML. In the regulated world, almost every investor needs to be qualified with KYC/AML before you send them a security. “Know Your Customer” means that you know who the investor is, and it’s not a bad guy, a tax evader, or someone under political sanctions. “Anti Money Laundering” means that you know approximately where they got the money to buy a security, and it’s not from illegal activity. You can put people on a whitelist after you make these checks. In the US and many other jurisdictions, investors need an additional level of qualification before you can sell them private securities. Private securities are any securities without public market reporting, which is expensive. Governments allow you to sell to investors without the expensive public market reports and disclosure, but they often only allow you to sell to investors that are “sophisticated” or “professional” enough to do their own analysis and cover their own losses. In the US they can meet qualifications like accredited (they have $1M to invest), Qualified ($5M) or QIB ($100M). A lot of securities won’t need “sophisticated” investor qualification, but they will almost all need KYC/AML qualification. The US government has been an enthusiastic promoter of KYC/AML rules, and through their control of the dollar-based money transfer system, they have been able to push for KYC/AML rules in almost every jurisdiction. It’s possible to make sure that your buyers have been qualified if you only sell through centralized exchanges that check their qualifications. That’s how the current public exchange system works. However, this doesn’t actually cover the use case for tokenized securities, which are also sold directly by the issuer, in portals, exchanged peer to peer or “OTC”, and moved between exchanges. To get that type of mobility, you need a whitelist, and you need to be able to add qualified exchange customers to the whitelist when you transfer a security out of an exchange. So, whitelist token formats are important even to exchanges with good internal transfer agents. Transfer rules If you are selling a private security, you will need to enforce transfer rules so that you send only to qualified investors, according to the different rules of various jurisdictions. You probably also want to enforce lockups, such as the one year lockup for private securities sold in the US. You may have other rules that are typically part of a “subscription agreement” signed by a shareholder. One of the benefits of a tokenized security is that we don’t have to pass around paper and sign subscription agreements. Instead, we program the rules directly into the security. Then we can exchange. Transfer rules will almost always be required because the majority of security tokens are private securities, or they are private SOMEWHERE in the world where they have investors. Securities that qualify as a public security in Malta or the UK will usually need to be handled as private securities in the US. Keeping track of these rules will prevent you from getting a call from a regulator you don’t want to deal with. The tokens mentioned in this article are all programmed to run on Ethereum. However, we can use the same rules and whitelists for other chains and ledgers that are faster or simpler. For example, Stellar does not allow tokens to carry their own code. However, they are adding a feature which can require that an issuer sign off on every transfer using a type of centralized oracle. We can use the same whitelists and rules to do that. Security replacement and other governance With a cryptocurrency, if you lose the key, you lose the asset. Securities don’t work that way. If grandma buys a security, and dies without leaving a key, you still owe the securities to her estate. As the issuer, you need a way to essentially replace the share certificate by grabbing the old tokens and moving them to a new holder. There are other cases where you may need to force a transfer, such as the case where 90% of investors have accepted a tender offer, and you have the right to force the other 10% into the deal. To do this, you need a governance process, such as the multi-sig governance that we have programmed into our registry. You probably need a workflow for issuing more securities, which companies do all of the time after board approval, and for distributing securities or payments. Real name registry If you are selling stock, then you are required to keep a list of shareholders. You need to be able to track them down to verify regulatory compliance, and you need to be able to contact them so you can provide them with their shareholder rights. Essentially, you need to be able to go back to the party that qualified an investor and put them on the whitelist, and get more information for your registry. Our token implementations include to do this. a whitelisting system and registry Upgrades During the multi-year life of a security, the rules change. The sets of qualified investors change. You may want to provide new features for compatibility with emerging exchanges. You may want to fix your implementation. It’s very important to be able to attach updated code to your existing token. A lot of the token code that we looked at fails to meet the requirement for upgradeability. R-Token upgrades The original R-token concept was very simple. R-Token is a permissioned token on the Ethereum blockchain, enabling token transfers to occur if and only if they are approved by an on-chain Regulator Service (a script). The ServiceRegistry is a mechanism to upgrade the regulator as rules change over time. We liked the upgrade feature. We have made a number of modifications to make it easier to upgrade the rules, settings, and whitelists: Revised R-Token with reusable whitelists Service Registry is unnecessary component that costs additional fees. The pointer to the current Regulator can be updated in token itself. Settings Storage holds values for managing token transfers like transfer lockup, allow new shareholders, initial offering end date or managing whitelists. It is also replaceable. You can update these settings independent from updating the code. We filled in the rules for a US Reg D and global Reg S offering, and various other private market rules. We added reusable whitelists, which can be used with other token formats. Other token formats You can add these scripts to an ST20 token by replacing the “Transfer Manager”. This will upgrade the ST20 token that Polymath is currently generating to include upgraded whitelists and rules. It is a big improvement from the very crude whitelist in their initial release. It will also add the registry capabilities. I think that Polymath has done a pretty good job in offering their ST20 format as a standard that issuers and exchanges can build on. That is what we are doing here. However, much of their effort is going into the Polymath “platform”, which is a portal and a more complicated set of code that manages the process of an initial sale, and encourages you to use their POLY token. Engaging with this platform is difficult, and most people will skip it. Most advisors have their own sales channel. The POLY tokens are annoying. Polymath doesn’t return messages or have an established path for code contribution or plugin contribution. I find this to be true even though I have a partnership agreement with them. I look forward to working with them on a more open plugin process. Securitize.io is currently rolling out tokens with their new DS format, whitelists, and registry. Unfortunately, this is currently a closed system that requires you to buy all of the token programming from Securitize, and qualify investors through their portal. The DS architecture is pretty similar to our implementation. I offered my code to them, but they decided to roll their own. We can unify these efforts for exchanges by making a code- compatible API for the registry. I have sent messages to Tokensoft and New Alchemy, and not heard back. Developing a global market how we can share code or accept contributions. Let us know how we can include your whitelists and customer lists. We can all be engaged in helping issuers and exchanges ramp up a truly global security market. Let us know