Comparison between Security Token Proposals (Part 1)

Fig. 1: Stock Market (Source: https://www.intheblack.com/articles/2017/10/03/october-stock-market-crash)

This post is aimed to give an understanding on various Security Token proposals till date, proposed on the Ethereum network. The scope of this article is restricted only to current Security Token proposals in the market and it is not about the Security Token market in general. This is a work in progress and we always welcome polite disagreement. Happy reading!

Introduction

The constantly added volume of Ethereum Security Token proposals reflects the continuous push towards a growing ecosystem around Security Tokens. A Security Token standard, which could be widely adopted and provides clear direction is still missing. This is primarily because from the issuer perspective Security Tokens require complex cross-border interactions, need to follow a highly regulated market, and have to manage divergent legal requirements.

Despite such major hurdles, Security Token proposals are being released on a constant basis. With so many Security Token proposals it is easy to lose track of this ecosystem. The objective of this article is to bring clarity to the sphere. Firstly, we will explain what a so called Ethereum Request for Comments (ERC) is and what the ERC-20 standard stands for. If you are deep into the ecosystem you can simply skip it. Subsequently, we will also point out the problems associated with the vanilla ERC-20 standard for securities token adaptation. Secondly, a comparison of 8 current Security Token proposals will be made. The aim here is to give an overview and understanding of those current proposals. For easy reference we have prepared a table which lists the features of the different Security Token proposals.

ERC-20 standard and the problems for securities token adoption

This section will explain what an ERC is and what the ERC-20 standard stands for. After that the problems associated with this standard for securities token adaptation will be shown.

ERC stands for “Ethereum Request for Comments”, while the number 20 is the number assigned to this specific request (more information on ERC and EIP can be accessed here). This standard for tokens is a specific set of functions which developers must use in their tokens to make them ERC-20 compliant. Without the ERC-20 standard, developers had to set rules for their tokens, while this approach did not provide a proper standardization. The standard defines six mandatory rules and three optional ones, which the smart contracts should implement. So, this standard was needed to provide a standardized and uniform interface. ERC-20 is the vanilla interface for the token contracts and is simple, easy to deploy and interoperable with the entire Ethereum universe. ERC-20 defines two types of events, Transfer(), triggered when tokens are transferred and Approve(), used for every successful call of the approve() method. For more information on ERC-20 Jim McDonald’s article can be a good start.

As opposed to vanilla ERC-20 tokens, transfer of securities tokens can fail for number of reasons other than the fact that the sender having an insufficient balance. These conditions could be related to the fact that there is an identity requirement for the transfer to take place, legal requirement for a mandatory lock-up period, maximum or minimum number of investors etc.

The following are the major problems with the vanilla ERC-20 Token standard to be used for the issuance of securities:

• Once the tokens are issued as per the vanilla ERC-20 standard tokens become freely transferable. So there is no transfer restriction. This means that even a non-identified person can transfer Security Tokens and receive the same. A transfer restriction is needed for a token owner to be KYC/AML* compliant
• ERC-20 tokens do not support KYC/AML rules, and does not allow restricting token holders to certain addresses
• Sharing of the profits/revenue/dividends by the ventures with the token holders holders are not possible, because the distribution is not automated
• ERC-20 token is ‘naturally’ fungible and so there is a possibility of multiple unauthorized voting (double voting problem)

*KYC (Know your customer): Verification process to identify its clients and assess potential risks of illegal intentions for the business relationship.

*AML (Anti money laundering): A set of procedures, regulations and laws to stop the practice of generating income through illegal actions.

Comparison between Security Token proposals

This section will list 8 Security Token proposals and provide a consistent overview of them.

To encourage the growth of tokenized securities an interoperable token standard is desirable that will bridge diverse ecosystem, both regulatory and technology wise, is desirable. This can only be achieved if issuers, investors, wallets, exchanges, developers and other stake holders work together using a uniform framework.

Fig. 2: Overview of Security Token Proposals

Here we will refer to 8 proposals, illustrated in Figure 2. All of these proposals can be found on GitHub and the respective hyperlinks are attached to the proposal names. Further, all the following proposals are designed for Security Tokens, tokenized securities and other tokens that carry complex compliance requirements. In addition to that, the following proposals are extensions to the ERC-20 standard and in some cases even combinations with other standards.

ST-20/ERC-1400: The most hyped and talked about Security Token proposal is Polymath’s ST-20, which aims to apply transfer restrictions to the vanilla ERC-20 standard. The ST-20 token is implemented on top of the ERC-20 standard, which provides the ability for tokens to control transfers based on certain rules. Recently the team at Polymath, along with Fabian Vogelsteller have additionally published the ERC-1400 proposal, which handles an interface for the issuance of Security Tokens, their management, and transfer restrictions. The original draft of ERC-1400 was based directly on ST-20. If ERC-1400 will be finalized, and passes the community review, ST-20 will be updated to be Polymath’s implementation of ERC-1400. This proposal provides additional functionality to manage different types of ownership of fungible tokens representing asset ownership. The motivation of the authors and participants is based on facts, that Security Tokens should be able to represent any asset class, issued and managed across any jurisdiction, and comply with the associated regulatory restrictions.

ERC-1410: This proposal is called the partially fungible token standard, which is compatible and also built on ERC-20 as well as ERC-777. It introduces an interface to support token owners, grouping them together into so called tranches, whereby each tranche is represented by a balance and identifying key. Security Tokens often require metadata to be attached to individual tokens. Metadata is data that describes other data. This means it is a description and context of the data. So, it helps to find, organize and understand data. For example the share, which is held with a certain token or the restrictions associated with it. Therefore, partially fungible token approach describes the functionality to associate metadata with individual fungible tokens, and attaching it to a partial balance of a token holder. A critical and productive discussion regarding the tranches can be read here.

ERC-1462: This proposal is developed by Atlant, which is a global real estate platform enabling tokenization of real estate ownership and P2P rentals. This proposal is called “The Base Security Token” and is an extension to the ERC-20 token standard. The proposal provides an extension compliance to securities regulations and legal enforceability. It includes a KYC/AML regulation, and a possibility to lock tokens for an account, and to restrict their transferability in case of a legal dispute. The ability to attach additional legal documentation is given, in order to set up a dual-binding relationship between the token and off-chain legal entities. Thus, Atlant intends to apply the ERC-1462 proposal to all property tokens created on the Atlant platform.

ERC-1404: Tokensoft has officially submitted this “Simple Restricted Token Standard. The ERC-1404 proposal brings benefits to the vanilla ERC-20 token standard, with improvements that allow issuers to enforce transfer restrictions within their smart-contract. Thereby, the issuers can control if a token recipient has been whitelisted, and for example verify if tokens are frozen in a lock-up period.

EIP-902: This proposal is developed by the Team of Finhaven, and describes a protocol for services providing token ownership and transfer validation. A registry contract method for authorizing token transfers is given. So, this covers issuing tokens to users, transferring tokens between them, and token spends.

R-Token: This proposal is called “Regulated Token System”, and has similarities with the EIP-902 proposal. The proposal is created by the Harbor team and handles smart contracts for applying regulatory compliance to tokenized securities issuance and trading. R-Token implements ERC-20 methods, and extends functions to KYC/AML requirements, tax laws, transfers between exchanges, persons and jurisdictions, as well as secondary trades.

DS-Token: This token proposal is submitted by Securitize. The DS Token aims to support in token issuance to verified investors, issue dividend/buyback payouts and provide voting rights. The tokens are compliant with the ERC-20 standard.

Table 1: Security Token Proposals and their features

P.S. although we mentioned throughout the article that there are 8 proposals. The reason for that is, that the proposals ST-20 and ERC-1400 are grouped together.

Interesting to observe, all of the proposals are only focused on US securities legal framework. In addition, most of the proposals have pause functions, which can be executed after the tokens are issued. The least developed functions are voting rights, automatic dividend and pause functions. Needless to mention, most of the proposals differ in their approaches, because every asset that needs to be tokenized is different and has a different use case. Very few proposals like ST-20 and ERC-1400 are focused on supporting all aspects of Security Tokens.

A notable mention is that all proposals have a transfer function included. Whereby each proposal has a completely different approach and no standardization is given. The transfer restriction functions for some of the proposals are the following:

• ERC-1400: function canTransfer(address _to, uint256 _value, bytes _data) external view returns (byte, bytes32);
• ERC-1404: function detectTransferRestriction (address from, address to, uint256 value) public view returns (uint8);
• EIP-902: function check(address token, address from, address to, uint256 amount) public returns (byte resultCode);
• R-Token: function _check(address _from, address _to, uint256 _value) private returns (bool);

A standardized transfer restriction function is the main prerequisite for a successful secondary market for Security Tokens. Since this is not given so far within the existing Security Token proposals, it can lead to difficulties for the interoperability in the Security Token Ecosystem.

Conclusion

As shown in the article there are several standards being proposed by various entities active in the securities token space. The 8 proposals illustrated above gives an overview of the existing Security Token proposals and the features behind them. Though the standards more or less aim to achieve the same objectives, the approach taken by all of them are quite divergent. In addition to that, we have also identified that all the proposals primarily focus only on the US securities legal framework. To sum it up, if we imagine having a robust secondary market in near future for the securities token. The community must agree on a standard as early as possible.

The STOKR team is excited to contribute within the community that may achieve a broad consensus across the security token ecosystem. Details about the same is kept for Part 2.

Closing Remarks

At STOKR we are primarily focusing on tokenizing the profit participation rights by the investors. We are targeting a very niche market of the entire Securities Token spectrum at the moment. Moreover, we restricted ourselves to the European market for the time being and our token model is based on the requirements provided under the MiFID structure. More detailed discussion about STOKR solution will be made in Part 2.

We hope that you like this article, and maybe it encourages people to participate more actively in the development of Security Token standards. Security Tokens definitely will extend the current token ecosystem and some standardization is very much needed. Further, the GitHub forums offer linkages between the mentioned proposals, which can be read regularly.

Thanks to Lukas Cremer and Arnab Naskar for reviewing and helping with this article.

Disclaimer: We always appreciate feedback, so feel free to contact Sergej Zumaev at sergej@stokr.io. Neither Sergej nor STOKR is associated with any of the above mentioned proposal. To learn more about STOKR, please follow us on Twitter or join our Telegram channel.