Security Token Offering Development with ERC Token Standards

Developing security tokens with ERC token standards.

Blockchain technology not only enables decentralized transaction management, but also the automation of processes, regulatory and organizational principles through the implementation of smart contracts. Such smart contracts are based on a defined set of rules that automatically determine how and when a transaction is legitimate and what activities should be initiated. Token contracts in this context are simply smart contracts that issue and operate with certain types of tokens.

This blog will focus on approaches to the Ethereum blockchain, as this technology had the purpose of enabling good use of smart contracts and is the current standard for most tokens issued in ICOs. The best-known example of such a standard would be ERC20, which has defined six mandatory functions.

ERC is an acronym for “Ethereum Request for Comments” and defines a set of rules (template). This is the Ethereum version of a “Request for Comments,” a type of publication based on the main technical development and standardisation bodies for the Internet – the Internet Engineering Task Force and the Internet Society. So before an ERC becomes a standard, it must be approved, evaluated, revised, commented on, and finally adopted by the community as an Ethereum Improvement Proposal (EIP). These ERC documents define guidelines that help create tokens with a standard set of rules. This is important to ensure the compatibility of these tokens with different 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 would add up to a lot of work and effort that could be avoided. Simply put, these standards ensure that all the pieces speak the same language and can therefore interact with each other, while reducing work for developers and potentially making the finished code better and cleaner.

Tokens that are compliant with a standard such as ERC20 are therefore supported without the need for custom code and are therefore immediately monetizable and tradable. Such standards also allow developers to easily use the technology without having to make everything from scratch. Standards are very important to drive mass adoption of tokens and minimize the effort required to develop them or integrate them into existing dApps.

Since the beginning of the ICO boom, most tokens issued have been classified as Utility Tokens (from a legal perspective, regardless of their technical design). Security tokens (or investment tokens) are usually treated like regular securities (e.g., stocks) and therefore regulated by central authorities. Such regulations are, for example, related to customer knowledge and anti-money laundering rules, which do not allow, for example, the free trading or transfer of Security Tokens with unknown participants, and some regulations also apply to the trading of Security Tokens on the secondary market. These regulations, as well as other factors, result in specific requirements that the token standard must meet in order to comply with the regulations. Therefore, a Security Token (Standard) generally requires different technical specifications than a Utility Token (Standard).

A token is usually classified as a security token if it derives its value from external, tradable assets. They may be backed by assets such as gold or real estate, represent a stake in a company, or entitle the holder to dividends from a power plant, for example.

The classification and thus strict regulation as a security token depends on the jurisdiction. For example, the Howey test is applied in the U.S. to determine whether a particular transaction qualifies as an “investment contract.” If so, they are considered securities under the Securities Act of 1933 and the Securities Exchange Act of 1934 and are therefore subject to the relevant requirements. An investment contract is characterized by the Howey test as follows:

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

While utility tokens provide access to a specific functionality of a platform or serve as an “internal currency” to pay for a service, security tokens have some sort of investment purpose and are linked to an underlying asset, often a physical asset that contains some sort of value. Today, most tokens are fungible, meaning that each token is identical in specification and type. Fungible tokens are interchangeable and divisible and don’t differ from each other. Security tokens, for example, are fungible if each token represents a specific share of a company’s stock – like a stock. In this example, each of these tokens would represent the same share of the company and is therefore fungible with each other

However, in some token use cases, each token must be unique. Such non-fungible tokens (NFTs) are therefore not interchangeable or divisible. They generally relate to a specific underlying asset. Such underlying assets may be cryptographic collectibles, for example. An example of such use is the DApp CryptoKitties, where each token represents a unique kitty that can be sold, collected, or used to breed other kitties. CryptoKitties was the first adaptation of the ERC721 standard for NFTs and gained great popularity, with some kittens selling for tens of thousands of USD. Other use cases for such NFT tokens can be tokenized certificates or licenses, for example

But tokens can not only be fungible or non-fungible, they can also be semi-fungible/partially fungible, which means that tokens represent several classes that have exchangeable members, but these members are not exchangeable with those of other classes.

Every token is ultimately a smart contract. The way such a token is created in terms of its functionalities can be defined in a standard, which can then be adapted to the various wallets and exchanges, thus making it tradable on the secondary market, for example. Since security tokens are subject to strict regulatory requirements, the corresponding standards must offer functionalities that enable them to meet these requirements (and extend the functionalities of the widely used ERC20 standard). Such functionalities include a transfer restriction so that, for example, transfers are only possible between parties that have gone through a KYC process. Other examples include the ability to force transfers for legal purposes and to recover funds or the ability to attach metadata to a token holder’s account balance (e.g., identity information).

Standards

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

• Tokens using this standard must implement the six mandatory functions listed below. The functions consist of the function name and the arguments in parentheses. For example, the function named balance requires the owner’s specific address to display the respective token’s current balance. The function transfer needs the address to which the tokens will be sent and the number of tokens to be sent. For ERC20 functions the corresponding arguments therefore lead to:

• Total supply () – to check the total number of tokens balance of (owner) – to check the account balance transfer (to, value)to – to first transfer tokens from the owner to another account transfer from (from, to, value) – to send tokens authorized from one address to another approve (donor, value) – to allow the donor to withdraw from his account allowance (owner, donor) – to check how many tokens can be retrieved with approval

Further defines two events:

• Transfer (from, value) – triggered when tokens are transferred.
• Approval (owner, donor) – triggered when approved is invoked.

As can be seen, the ERC20 standard, currently used in most projects, does not provide the various potentially needed functionalities of security tokens and is incapable of using NFT.

ERC20 tokens are freely tradable on the secondary market and have no mechanism to restrict transfers, for example. For this reason, and because of the limitations and problems of the ERC20 standard, several other promising standards are in preparation, most of which are still in the draft stage. These standards aim to serve a specific use case, to improve the ERC20 standard, or to extend the functionalities to meet the requirements of security tokens or NFT, for example.

To illustrate the broad range of potential token standards, a list of some ERC standards and their descriptions (indicating the use case for each) is provided below.

• ERC20: Standard token
• ERC223: Fungible Token Standard
• ERC667: Transmission and call token standard
• ERC721: Non-fungible token standard
• ERC725: Identity
• ERC735: Claim Holder (assertions about identities)
• ERC777: Operator-based token standard
• ERC809: Rental standard for concurrent non-fungible tokens
• ERC827: Pseudo-introspection using a registration contract
• ERC864: Related to #981
• ERC865: DelegatedTransfer (Related to #965)
• ERC874: Weighted non-fungible tokens
• ERC918: Minable token standard
• ERC965: Send above as check (Related to #964)
• ERC981: Barter Token Standard
• ERC994: Delegated non-fungible token standard
• ERC998: Composable non-fungible token standard
• ERC1003: Secure transfer on contract extension
• ERC1155: Multiple token types
• ERC1400: Security token standard
• ERC1404: Simple restricted token standard
• ERC1410: Partially fungible token standard

The following table in Section 3 will provide a summary overview of the comparison, comparing 8 different standards (in both design and final states). Three of them are specifically designed for Security Tokens. The selected tokens are:

ERC20 – the first and most established standard for basic functionalities related to fungible tokens.

ERC223 – aims to serve the same purposes for fungible tokens as ERC20, but solves an ERC20 inherent problem that resulted in the loss of tokens when sent to a smart contract that was unable to process them. Compared to ERC20, transfers using ERC223 require only half the gas (gas is equivalent to Ether and is used to pay transaction costs for each transaction on the Ethereum blockchain). This standard is still in the draft stage.

ERC777 – used for fungible tokens with an enhanced interface compared to ERC20, solving the problem of lost tokens. It adds new features such as white-listed operators compared to ERC20 and implements the same logic used to send tokens as Ether. The required gas (transaction cost) is slightly higher compared to ERC20, but lower for bulk transactions. Uses ERC820 for introspection, which leads to (minor) security issues. This standard is still in the draft stage.

ERC721 – is the first NFT standard that is already in final stage and used in ICO projects. It is currently used primarily in (collectible) crypto plays to tokenize unique individual assets. This standard provides basic functionality to track and transfer ownership of NFT. The gas cost is 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 management of final advice the relative proportion of security to utility tokens will likely be fungible, semi-fungible and non-fungible tokens. It is still in the design stage, but is already used in games. In the example of games, a multi-token approach is of great use since such games have fungible items (such as life/energy) but also non-fungible items such as weapons, all of which are different. This standard allows multiple transfers/batch transfers with multiple token types (FT and NFT) and requires less gas overall than ERC20.

ERC1400 – is a standard designed specifically for security tokens. For example, it allows restricted transfers, adding transfer information, document library management, and forced transfers. This is done by combining different ERC standards, each fulfilling a different aspect of the (potentially) needed security token functionality. If you combine the relative proportion of security tokens to utility tokens, you are likely to have a wide range of functionality that enables legitimate, validated use of security tokens. This approach is comprehensive, but also complex.

ERC1404 – is an extension of ERC20 that enables the issuance of transfer restricted tokens to meet security token compliance requirements. For example, it allows the implementation of a whitelist so that it is possible to control who is allowed to own a token selectively. In addition to this capability and the implementation of transfer restrictions, it also allows the implementation of human-readable messages in case a token transfer is reversed. This approach is comparably easy to implement as ERC20, but has the disadvantage that these enforceable restrictions cannot be changed during the lifecycle of the token.

ERC1462 – is also an extension of ERC20 for a general security token implementation on which compliant security tokens can be built. Enables whitelist and revocation period checks to meet legal requirements for security tokens such as KYC. For example, the issuer would need to “onboard” investors by having them complete and evaluate the required documents identifying them. Each investor who passed KYC and is allowed to invest can then be placed on a whitelist that can be reviewed to determine who is allowed to purchase tokens. Additional legal documents can also be attached.

Most of these ERC standards are in the draft stage. Before they reach the final stage and are introduced to the market, they still need to be revised, errors corrected and further developed. So at this point, it is difficult to compare the various potential new standards for security tokens conclusively. There are likely dozens of different approaches to this issue, with none reaching a final status and being an accepted and established standard for the security token use case.

Most of the selected tokens are ERC20 compatible, meaning all wallets and exchanges supporting ERC20 will also support these tokens. Tokens may be (backward) compatible with another standard, which means that the “new” standard implements all the mandatory features of the old standard and only extends them (by adding additional features). However, security tokens may not be freely traded on any exchange due to their nature.

Several initiatives, such as a modified ERC20, or ST20, already handle the aspects of issuing a security token described above. ST20 is implemented on top of an ERC20 protocol and allows tokens to control transmission based on certain rules. It serves as a base token that allows the issuer to add functionality through modules and enables regulated issuance of restricted security tokens. Another standard worth mentioning is the Regulated Token System (R-Token), which allows ERC20 tokens to be used for regulated securities through an implemented approval process by an on-chain regulator service.

As can be seen, standards, their use cases, and associated functional requirements generally vary widely, with standards related to security tokens in particular needing to include specific functionality to make them legally compliant. Many standards are ERC20-compliant to allow easy integration with current wallets and exchanges and to ensure credibility of the relative proportion of security to utility tokens.

Comparison table – Commonly known and established token standardsToken standards that relate specifically 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 fulfill 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 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 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 fulfill all Security Tokens requirements over 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.

Brugu, an STO Development Service provider, is 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.