Security Tokens — An ERC-Standards Comparison

13 min readDec 13, 2018

micobo Market Research, December 2018

1 Basics

The Blockchain-Technology not only allows a decentralized transaction management, it furthermore allows the automation of processes, regulatory and organizational principles through the implementation of Smart Contracts. Such Smart Contracts are based on a defined rule system that specifies automatically how and when a transaction is legit as well as which activities are to be initiated. In that matter, Token Contracts are simply just Smart Contracts that emit and work with specific types of tokens.

This article will focus on approaches for the Ethereum Blockchain, since this technologies purpose was to allow a good use of Smart Contracts and is the current standard for most tokens emitted in ICOs. The most known example of such a standard would be the ERC20, which has six mandatory functions defined.

ERC is an abbreviation for “Ethereum Request for Comments”and defines a set of rules (template). This is Ethereum’s version of a “Request for Comments”, which is a type of publication based on the principal technical development and standards-setting bodies for the internet –the Internet Engineering Task Force and Internet Society. So, before an ERC becomes a standard, it has to be approved as Ethereum Improvement Proposal (EIP), evaluated, revised, commented and finally accepted by the community. These ERC documents defining guidelines to help create tokens with a standard set of rules. This is important to ensure compatibility of these tokens with the several wallets and crypto exchanges as well as other smart contracts.

Without such standards, developers of exchanges, wallets and other smart contracts would have to write custom code to support each individual token, which overall would require a lot of work and effort that could be avoided. Simply said, these standards make each piece speak the same language and therefore enable them to interact with each other, while at the same time it reduces work for developers and potentially leads to a better and cleaner finished code.

So, tokens that are compliant with a standard like ERC20 are supported without the need for any custom code and are therefore instantly monetize- and tradeable. Such standards also allow for developers to easily make use of the technology without doing everything from the scratch. Standards are highly important in order to promote mass adoption of tokens and minimize efforts developing or integrating them in existing DApps.

This article aims to briefly give an overview of what token standards are existing and describe some current ERC-standards and -proposals of large interest with focus on Security Tokens. For the purpose of evaluating the different ERC`s, they will be characterized in a comparison table.

Since the beginning of the ICO-Boom, most emitted tokens are classified as Utility Tokens (from a legal perspective, regardless of their technical design). Security Tokens (or Investment Tokens) are commonly treated like regular securities (e.g. stocks) and are therefore regulated by central authorities. Such regulations are for example related to Know Your Customer and Anti Money Laundry rules, which for example do not allow a free trade or transfer of Security Tokens dealing with unknown participants and also applies some regulations for trading the Security Token on the secondary market. These regulations as well as other factors lead to specific needs that have to be fulfilled by the token standard used in order to comply with the regulation requirements. Therefore, a Security Token (standard) in general needs other technical specifications then it would be necessary for a Utility Token (standard).

A token is usually classified as Security Token, when it derives its value from external, tradable assets. They can be backed by assets like gold or real estate, can represent a share of a company or can entitle to dividends from for example a power plant.

The classification and therefore strict regulation as Security Token is depending on the specific jurisdiction. The Howey Test is for example used in the US to determine whether a certain transaction qualifies as “investment contract”. And if this is the case, they are by the Securities Act of 1933 and the Securities Exchange Act of 1934 considered securities and hence subject to related requirements. An investment contract is characterized by the Howey Test as follows:

It is an investment of money
There is an expectation of profits from the investment
The investment of money is in a common enterprise
Any profit comes from the efforts of a promoter or third party

The specific regulations and requirements a Security Token has to fulfill are of course strongly correlated to the country of origin and business making. For the US, Security Token would have potentially to comply with related Regulation D, Regulation A+, Regulation S. Such regulation requirements can generally include e.g. a check and verification of the investors’ identification as well as their accreditation.

While Utility Token give access to a specific functionality of a platform or work as “internal currency”to pay for a service, Security Tokens have some sort of investment purpose and are related to an underlying, often physical asset, which contains some sort of value. Today, most tokens used are fungible, which means, that each token is identical in specification and type. Fungible tokens are interchangeable and divisible and don’t differ from one another. Security Tokens are for example fungible, when each token represents a specific share of a company — like a stock does. In this example every such token would represent the exact same share of the company and is therefore fungible with each other.

However, some token use cases have the need to make each of the tokens unique. Such non-fungible tokens (NFT) are therefore not interchangeable or divisible. They generally refer to a specific underlying asset. Such underlying asset could be for example cryptographical collectibles. An example for such a use is the DApp CryptoKitties, whereas each token represents a unique kitty, that can be sold, collected or used to breed other kitties with. CryptoKitties was the first adaption of the ERC721 standard for NFTs and gained broad popularity with some kitties sold for tens of thousands of USD. Other use cases of such NFT tokens can for example be tokenized certificates or licenses.

But tokens cannot just be fungible or non-fungible, they can also be semi-fungible/partially-fungible, which means that the tokens represent several classes, which has interchangeable members, but those members are not interchangeable with such of other classes.

Every token in the end is a smart contract. The way such is created in its functionalities can be set in a standard, which then can be adopted to the different wallets as well as exchanges and make it therefore e.g. tradable on the secondary market. Since Security Tokens are subject to strict regulation requirements, standards related to them have to offer some functionalities that make them able to comply with these requirements (and which extend the functionalities of the widely used ERC20 standard). Such functionalities are for example a transfer restriction, so that for example only transfers between parties that passed a KYC-process are possible. Other examples are the possibility of forced transfer for purposes of legal and fund-recovery procedures or the ability to attach metadata to a tokens holder balance (like identity information).

2 Standards

A List of ERCs in draft and final state can be found here: https://eips.ethereum.org/all, further proposals can be found on github.com.

To better understand what such standards are and how they work, let’s have a look at the example of the ERC20 standard below:

Tokens working with this standard have to implement the six mandatory functions seen below. Functions consist of the function name and the arguments within the parenthesis. For example, the function named balanceOf needs a given address of the owner to show the current balance regarding the specific token. The function transfer needs the address where the tokens are send to as well as the number of tokens that are to be send. Regarding ERC20-functions, their related arguments lead therefore to:

totalSupply () – to check the total number of tokens

balanceOf (owner) – to check the balance for an account

transfer (to, value)to – initially transfer tokens from the owner to another account

transferFrom (from, to, value) – to send tokens authorized from one address to another

approve (spender, value) – to allow spender to withdrawal from ones’ account

allowance (owner, spender) – to check how many tokens can be called by permission

Defines furthermore two events:

Transfer (from, value) – triggers when tokens are transferred

Approval (owner, spender) – triggers whenever approved is called

As one can see, the ERC20 standard that is currently used in most projects does not offer the various potentially needed functionalities of Security Tokens and is not able to deploy NFT. ERC20 tokens are freely tradable on the secondary market and have no mechanism to e.g. restrict transfers. Due to this as well as limitations and issues of the ERC20 standard, several other promising standards are upcoming, most of which still in draft state. These standards aim to serve a special use case, improve the ERC20 standard or extend the functionalities to for example fulfill the requirements of Security Tokens or NFT.

To illustrate the wide range of potential token standards, a list of some ERC standards as well as their description (that state the related use case) is included below. The name of each of these tokens includes a hyperlink to the related github.com page were the several standards are explained and discussed.

· ERC20 : Standard Token

· ERC223 : Fungible Token Standard

· ERC667 : transferAndCall Token Standard

· ERC721 : Non-fungible Token Standard

· ERC725 : Identity

· ERC735 : Claim Holder (claims about Identities)

· ERC777 : Operator Based Token Standard

· ERC809 : Renting Standard for Rival, Non-Fungible Tokens

· ERC827 :Pseudo-introspection using a registry contract

· ERC864 : Related to #981

· ERC865 : DelegatedTransfer (Related to #965)

· ERC874 : Weighted Non Fungible Tokens

· ERC918 : Minable Token Standard

· ERC965 : sendByCheque (Related to #964)

· ERC981 : Barter Token Standard

· ERC994 : Delegated Non-Fungible Token Standard

· ERC998 : Composable Non-Fungible Token Standard

· ERC1003 : Safe Transfer To Contract Extension

· ERC1155: Multiple Token Type

· ERC1400: Security Token Standard

· ERC1404: Simple Restricted Token Standard

· ERC1410: Partially Fungible Token Standard

The following table in section 3 aims to give a summarized comparison overview, whereas 8 different standards (in draft and final state) are compared. Three of those are especially designed for Security Tokens. The selected tokens chosen are:

ERC20 - the first and most established standard for basic functionalities regarding fungible tokens.

ERC223 - aims to serve the same purposes for fungible tokens that ERC20 does, but solves an ERC20 inherent issue that resulted in the loss of tokens if they were send to a smart contract that was not able to deal with them. Compared to ERC20, transfers with ERC223 only require half the gas (whereas gas is an equivalent to Ether and used to pay for transaction costs for each transaction that occurs on the Ethereum blockchain). This standard is still in draft state.

ERC777 - used for fungible tokens with an evolved interface over ERC20, while solving the lost token issue. It adds new functions like white-listed operators compared to ERC20 and implements the same logic tokens are send with like Ether does. Required gas (transaction costs) is somewhat higher compared to ERC20 but is lower in bulk transactions. Makes use of ERC820 for introspection which leads to (minor) security issues. This standard is still in draft state.

ERC721 - is the first NFT standard that is already in final state and used in ICO projects. It is currently most used in (collectible) crypto games to tokenize unique individual assets. This standard provides basic functionality to track and transfer ownership of NFT. Gas costs are slightly lower compared to ERC20. Uses ERC165 to ensure that a contract is compliant with the interface.

ERC1155 - is a multi-token standard that allows to manage fungible, semi-fungible and non-fungible token. It is still in draft state but already applied in games. In the example of gaming a multi-token approach has great application, since such games have fungible elements (like life/energy), but also non-fungible elements like weapons that all differ from one another. This standard allows multi-transfers/batch transfers with multiple token types (FT and NFT) possible and overall requires less gas compared to ERC20.

ERC1400 - is a standard specifically designed for Security Tokens. It does allow for example restricted transfers, the adding of transfer information, document library management and forced transfers. It does so by combining various ERC standards, which each fulfill another aspect of (potentially) needed Security Token functionality. It therefore has a wide range of functionality that enable a legal conform deployment of Security Token. This approach is comprehensive, but also complex.

ERC1404 - is an extension of ERC20 that allows the issuance of tokens with transfer restrictions to fulfill compliance requirements of Security Tokens. It for example allows the implementation of a whitelist, so that it can be selectively controlled who can own a token. Besides this and the implementation of transfer restrictions, it furthermore allows for human-readable messages to be implemented in case of a token transfer being reverted. This approach is comparably easy to deploy as ERC20, but has the downside, that enforceable restrictions cannot be modified throughout the lifecycle of the token.

ERC1462 - is also an extension of ERC20 for a general Security Token implementation to build compliant Security Tokens upon. Enables for whitelist and lock-up period checks to comply with Security Tokens legal requirements like KYC. The issuer would for example have to “onboard”the investors through letting them fill out and evaluate the needed documentary related to their identification. Every investor passed the KYC and allowed to invest can then be put on a whitelist, which can be checked to determine who is allowed to purchase tokens. It furthermore allows additional legal documents to be attached.

Most of these ERC standards are in draft mode. Before reaching final state and market implementation they are subject to potential edits, bug-fixing and further development. So, at this point in time it’s hard to finally compare the various potential new standards for Security Tokens. There are probably dozens of different approaches in this matter, whereas non reached a final state and is an accepted and established standard for the use case of Security Tokens.

Most of the chosen tokens are ERC20 compatible which means that potentially all wallets and exchanges supporting ERC20 will support these tokens as well. Tokens can be (backwards) compatible with another standard, meaning that the “new” standard implements all mandatory functions of the old standard and only extends them (through added functionalities). However, due to their nature Security Tokens are not allowed to be freely traded on every exchange.

There are already several initiatives such as an amended ERC20 referred to as ST20 to tackle the above described aspects of issuing a Security Token. The ST20 is implemented on top of an ERC20 protocol and adds the ability for tokens to control transfer based on specific rules. It works as a base token which gives the issuer the ability to add functionality through modules and allows to issue restricted Security Tokens in a regulated way. Another standard to be mentioned is the Regulated Token System (R-Token), which enables ERC20 tokens to be used for regulated securities through an implemented process of approvement by an on-chain Regulator Service.

As there is to see, standards, their use cases and the related functional requirements differ widely in general, whereas especially standards related to Security Token have to include specific functionality to make them legally compliant. Many standards are compliant to ERC20 to allow and easy integration in current wallets and exchanges to ensure tradability.

3 Comparison Table

General prominent and established token standards

Token standards specifically related to Security Tokens

4 Conclusion

There are plenty of approaches for token standards based on Ethereum, whereas the most used one is the ERC20. However, this standard lacks to fulfill the specific needs and requirements of Security Tokens like restricted trading, forced transfers, adding information to transfers as to manage documents and metadata. Issuers of Security Tokens have to fulfill legal requirements, since such are widely seen and regulated as securities (like stocks or bonds for example) by the national authorities. This fact leads to strict regulation requirements that are to be met.

Since the ERC20 does not offer functionalities to a degree that is sufficient for that purpose (as well as of course further reasons and issues increase the need for alternatives), a broad spectrum of (potential) Standards that are applicable for Security Tokens were proposed and are currently in draft state. Such approaches are whether extensions of ERC20 to add needed functionalities (like ERC1404 and ST20) or are more complex and might include several other standards that each add different aspects of Security Token functionality to it (like ERC1400).

In the end, the specific use case defines which standard fits best for the need of a specific project. The selection can depend on parameters like compatibility, fungibility, gas costs, degree of functionalities and the related jurisdiction(s). Another important aspect can be the complexity. While extension of ERC20 are commonly less complex due to the good knowledge and experience with ERC20 gained, new approaches involving various new functionalities and maybe using several underlying standards could reach a high degree of complexity. Such complexity can slow down the development as well as emitting process and should be avoided if a less complex and better understood approach is applicable and serves the purpose to the same degree.

In the end, the ERC1400 seems to be a very comprehensive standard, which potentially can fulfill all requirements of Security Tokens over potentially every jurisdiction. However, it is overall complex and has a huge variety of potential functionalities (more than maybe be needed in practice regarding the specific project). In contrast the ERC1404 adds the simple functionality of transfer restrictions, which could also be viable to fulfill the legal requirements of a Security Token depending on the specific project and jurisdiction.

We are at the very beginning of the up-rise of Security Tokens and it is likely that the relative portion of Security to Utility Token will increase and more Security Token Offerings will occur. With that development more (potential) standards will be proposed and reach a final state so that can be used in practice. It is likely that over time, some of these standards will become a “state of the art- status” and are therefore adopted by the vast majority -similar to how ERC20 is used today but related to specific use cases and considering different jurisdictions. Due to the lack of standards related to Security Tokens in final state and none current adopted in practice, a final advice on which standard to use cannot really be given at this point.

No legal or investment advice

About micobo GmbH

micobo GmbH is a leading European software company for Security Token Offerings and Blockchain Software Development. micobo provides fully compliant software solutions for Security Token Offerings and advises on structuring DLT- and Blockchain-based Securities.

Kai Lorberg is a FinTech Lead Analyst at micobo GmbH. He can be contacted via e-mail (kl@micobo.com).

Christian Labetzsch is Managing Director at micobo GmbH. He can be contacted via e-mail (cl@micobo.com).

Sources:

https://blog.atlant.io/atlants-proposed-base-security-token-standard-erc-1462-accepted-as-draft-by-ethereum-980a30b901bc

https://blog.enjincoin.io/erc-1155-the-crypto-item-standard-ac9cf1c5a226

https://consumer.findlaw.com/securities-law/what-is-the-howey-test.html

https://eips.ethereum.org/all

https://eips.ethereum.org/EIPS/eip-777

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md

https://github.com/ethereum/EIPs/issues/1404

https://github.com/ethereum/EIPs/issues/1411