STO Token standards
There are various takes on standardizing STO token in: ST-20 from Polymath team, R-Token from the Harbor team, and proposals from the community, like ERC1400/ERC1410 and ERC1404 standards. In this article, we will briefly introduce these five standards. We must also note that tZERO did not not adopt the draft of the ERC1400 protocol, but implements the securities-based token functions on the basis of ERC20 standard.
— About ERC-1404
According to the description, ERC-1404 has all the advantages of the ERC-20 standard, like ease of deployment and interoperability with the Ethereum network, as well as some key improvements that allow issuers to implement transfer restrictions. Based on the ERC-20 standard, the ERC-1404 adds two key functions: detectTransferRestriction and messageForTransferRestriction.
detectTransferRestriction: This function is where an issuer enforces the restriction logic of their token transfers. Some examples of this might include, checking if the token recipient is whitelisted, checking if a sender’s tokens are frozen in a lock-up period, etc.
messageForTransferRestriction: This function is effectively an accessor for the “message”, a human-readable explanation as to why a transaction is restricted. By standardizing message look-ups, we empower user interface builders to effectively report errors to users.
More information about the standard can be found here: https://github.com/ethereum/EIPs/issues/1404
— About ERC-1400
ERC-1400, in the contract, the tokens are divided into different tranches, so that not only specific addresses can be restricted, but also restrictions on tranches, such as allotment, voting, dividends, dividends and other complex functions can be defined through contract layer tranche to achieve differentiation and transformation difference.
The main points of the ERC-1400 agreement are the following:
• MUST have a standard interface to query if a transfer would be successful and return a reason for failure.
• MAY be able to modify metadata at time of transfer based on off-chain data, on-chain data and the parameters of the transfer.
• MAY require signed data to be passed into a transfer transaction in order to validate it on-chain.
• MUST be ERC20 compatible.
• SHOULD be ERC721 compatible.
• SHOULD be ERC777 compatible.
Please visit the official proposal page for more details on this standard: https://github.com/ethereum/EIPs/issues/1400
— About ERC1410
The ERC-1410 standard is also known as Partially-Fungible Token. This standard is an extension of ECR-777 and is implicitly compatible with ERC-777 and ERC-20. ERC-1410 describes an interface to support grouping passes into multiple tranches, each represented by an identification key and a balance, which allows for some operational limitations.
More information about the standard can be found here: https://github.com/ethereum/EIPs/issues/1410
— About ST-20
The ST-20 is the ST-20 standard that Polymath introduced in February 2018, basically copying ERC-20 and supplementing it with a mandatory qualified investor certification for individual and institutional investors. It allows legitimate investors to participate in STO in compliance with government regulations. In addition to the basic functions, new functions can be added to verifyTransfer by means of additional modules.
The most important function in the T-20 protocol is verifyTransfer, that features the following modules:
• Support for whitelisting.
• Set transfer amount limit.
• Token transfer restrictions.
• Support for blacklisting.
More information about the standard can be found here: https://polymath.network/st20.html
— About R-Token
R-Token implements ERC-20 methods transfer() and transferFrom() with an additional check to determine whether or not a transfer should be allowed to proceed. The implementation of check() can take many forms, but a default whitelist approach is implemented by TokenRegulatorService. Token and participant-level permissions, when used in different combinations, can be used to satisfy multiple regulatory exemptions. The ServiceRegistry is included as a mechanism to facilitate upgrading the R-Token check logic as rules change over time.
● RegulatedToken
○ Permissioned ERC-20 smart contract representing ownership of securities
○ Compatible with existing wallets and exchanges that support the ERC-20 token standard
○ Overrides the existing ERC-20 transfer method to check with an on-chain Regulator Service for trade approval
● RegulatorService
○ Contains the permissions necessary for regulatory compliance
○ Relies on off-chain trade approver to set and update permissions
● ServiceRegistry
○ Accounts for regulatory requirement changes over time
○ Routes the R-Token to the correct version of the Regulator Service
— in conclusion
ST-20 and R-Token are designed by Polymath and Harbor respectively, and are mainly promoted by these companies. If they prove the ability to create a successful securities tokenization, they could possibly be recognized in the future. ERC-1404 and ERC-1400 are adopted by EIP to widely adopt community opinions and jointly develop standards. But these standards are currently in the Draft phase, and it usually takes a long period of time to get into the Last Call phase.
These proposals may be just the beginning of a road to securities tokenization. In actual application scenarios, there may be differences between the securities issued by the same company, such as restricted shares / non-restricted shares, preferred shares / common shares, these different types of securities in dividends, voting rights, liquidity is not the same, its nature may also be very different, so can expect more standards to appear in the future.
Follow us：
Twitter：https://twitter.com/CoindyOfficial
Facebook：https://www.facebook.com/CoindyOfficial/
Instagram：https://www.instagram.com/p/Bp9jkuUnCPP/
Telegram：https://t.me/coindyofficial
