Security Token Offering Development with ERC Token Standards

The Blockchain-Technology not only allows 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 blog will focus on approaches for the Ethereum Blockchain since this technologies purpose was to allow 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 the compatibility of these tokens with 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 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 to promote mass adoption of tokens and minimize efforts developing or integrating them in existing dApps.

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 to comply with the regulation requirements. Therefore, a Security Token (standard) in general needs other technical specifications than 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 an “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:

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

While Utility tokens give access to the 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 a 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 — as a stock does. In this example, every such token would represent the same share of the company and is therefore fungible with each other.

However, some token use cases 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 assets could be for example cryptographical collectibles. An example for such 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 adapted 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 regulatory 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).

Standards

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 balance 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 sent to as well as the number of tokens that are to be sent. Regarding ERC20-functions, their related arguments lead therefore to:

• Total supply () – 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 are still in draft state. These standards aim to serve a special use case, improve the ERC20 standard or extend the functionalities to for example fulfil 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. 

• ERC20: Standard Token
• ERC223: Fungible Token Standard
• ERC667: transfer and call 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: send above-described as cheque (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 the draft and final state) are compared. Three of those are specially 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 sent 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 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 as 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 the 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 the management of final advice the relative portion of Security to Utility Token will likely be fungible, semi-fungible and non-fungible tokens. It is still in the 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 fulfil another aspect of (potentially) needed Security Token functionality. It, collectable the relative portion of Security to Utility Token will likely have a wide range of functionality that enables a legally, confirm 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 fulfil 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, those 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 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 by letting them fill out and evaluate the needed documentary related to their identification. Every investor who passed the KYC and is 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 the final state and market implementation they are subject to potential edits, bug-fixing and further development. So, at this point, 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 with ERC20 to allow easy integration in current wallets and exchanges to ensure credibility relative portion of Security to Utility Token will likely.

Comparison Table

General prominent and established token standards

Token standards specifically related to Security Tokens

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 fulfil the specific needs and requirements of Security Tokens like restricted trading, forced transfers, adding information to transfers to manage documents and metadata. Issuers of Security Tokens have to since such are widely seen and regulated as securities (like stocks or bonds for example) by the national authorities. This fact leads to strict regulatory 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 was 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 the extension of ERC20 is 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 fulfil 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 fulfil 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 the final state and none current adopted in practice, final advice on which standard to use cannot really be given at this point.