How do you build a Security Token?
Ethereum Request for Comment, or ERC as most people know it, is a document that builders use to write Smart Contracts on the Ethereum blockchain. These documents decide upon rules that various Ethereum-based tokens should comply with.
Standards are extremely important when building all the apps, UIs and services related to the smart contracts. The main reason is that standards unify programmers unders same rules and optimize efficiency and security so that builders don't have to worry about those aspects nor adapt everytime their code because of non-standard compliance.
Starting as an Ethereum Improvement Proposal (EIP) proposed within the community, the community itself reviews the documents, comments on them, and potentially implements them as an ERC. EIPs can address everything from tokens, registration names, and common standards for the ecosystem to build on.
ERC-20 is likely the most heard off with inherent properties of fungibility, meaning each token is exactly the same as any other derived from the same Smart Contract (SC). This scripting language was implemented in 2015 and dominated the ICO bull market back in 2017.
Fun Fact: Ether itself, the native Ethereum currency, is not an ERC-20.
To this day it’s one of the most widely used standards, with tokens such as Basic Attention Token (BAT), ApeCoin (APE), Brickken´s BKN, and a majority of other tokens built using it. It brings fungibility, divisibility, and composability with a wide range of dApps and infrastructure built to accommodate assets using this standard.
There are several functions that a compliant ERC20 token must have implemented, such as the provision of the total token supply, provision of account balances of the owner´s account, fungibility, and various other features.
Another standard Application Programming Interface (API) is ERC-721, specifically for Non-Fungible Tokens (NFT). NFTs are used to identify something or someone in a unique way, hence “non-Fungible”. Examples are collectible items, access keys, lottery tickets, concert- and sports tickets, and other assets with unique properties.
Then we have ERC-1155, a standard interface for contacts to manage multiple token types, including fungible and non-fungible tokens. This is a needed implementation because standards like ERC-20 and ERC-721 require separate contracts to be deployed for each token type or collection. By nature, this places a lot of redundant bytecode on the Ethereum blockchain and limits certain functionalities.
Different standards may be implemented depending on the inherent characteristics and features you want your token and smart contract to have. Naturally, the space is evolving with new EIPs being proposed on a regular basis to decrease friction and increase usability in all aspects of the blockchain space.
But what about Security Tokens?
As is the case with every other token, it depends on what you want to achieve. ERC-20 is certainly an option and offers some of the functionalities you want in a Security. Such as the fungible nature seen in the traditional financial world.
Every publicly traded share of the same category is identical to any other. Any fraction of a debt instrument is identical to any other fraction issued through the same debt instrument.
But let´s look at a few ERCs that has specifically been introduced as the Security Token space has grown and is expected to be an innovation central part of the blockchain ecosystem.
ERC-1400 – A Security Token Specific Standard
ERC-1400 is a standard specifically created with the goal of a unified framework for every Security Token. The main reason is to improve the security compliance of tokens on the Ethereum network. As Security Tokens follow that of traditional Securities laws, there are various laws that require some functionality. Some of which are KYC and AML regulations that must be followed for the industry of tokenized securities to ever find an established space in finance.
Some key features are:
• The crediting of tokens to a wallet can be reversed.
This is important as most other standards do not offer any optionality of recovering funds of force the transfer of tokens. By enabling a Token recovery optionality, token issuers (companies) gain the necessary control needed whilst still reaping the benefits of utilizing a blockchain to gain composability and automation in asset management. This also accounts for human errors and ensures there are no transfers to non-KYC´d wallets that may not follow local jurisdictions.
• Metadata can be attached to the token holder´s balance.
Examples are shareholder rights or various other restrictions on how and when transfers can occur. Again this not only helps in seamlessly providing necessary verifiable information to primary investors and on a secondary market but also ensures that the conditions and rights of the token holders are in place.
• Put Limitations on Investors
Under ERC-1400 you can regulate holding periods in a wallet, put thresholds on transactions and limit the number of tokens per wallet. This may be of importance if an issuer is looking for a maximum number of investors, a specific distribution, or simply to avoid the presence of whales. If one of the main reasons for fundraising in this way is the creation of a large community, such functionality decreases not only a concentrated token allocation over time but also market friction from large token movements.
ERC-1594 – an Expansion of ERC-1400
This standard was designed to provide some core functionality that is needed for any Security Token. One of which is the capability to inject off-chain data. It is vital to incorporate on-chain rules and data from the input and authorization of real-world data. Again this is important for conditions based on data that does not reside on the blockchain itself, such as KYC verification and token states like redemptions and utilities based on real events relating to the issuing corporation.
ERC-1400 is known as an umbrella standard under which ERC-1594 and various others sit.
The T-Rex Protocol
Previously known as the T-REX protocol, ERC-3643 is an injection from 2018. This is yet another standard that gives more control to the issuer and assets can be recovered even if the private key of the wallet is lost as the asset ownership is guaranteed by digital identity. This standard, just like ERC-1400, is compatible with the ERC-20 standard, meaning its interoperable with the same wallets and dApps in the Ethereum ecosystem.
As we can see, there are various standards even for the emerging Security Token industry. Whilst the notion of tokenized securities holds great promise and is advancing for each day as regulators start to realize its benefits, there are core components that need to be inherent for it to take off. Specific jurisdictional compliance, AML and KYC components, and a certain degree of investor protection all need to be natively present.
These standards all propose different or complementary ways of solving this in an ecosystem that so far praises anonymity and actionable freedom. What these standards show, however, is that there are ways for Traditional Finance (TradFi) and Decentralized Finance (Defi) to merge in the pragmatic way necessary to expand investment inclusivity and open up new business models for the web3 era.