A crypto token that passes the Howey Test is deemed a Security token. Security tokens are designed to represent complete or fractional ownership in an asset. While utility tokens have no limitations on who can send or receive the token, security tokens are subject to many restrictions based on identity and jurisdiction.
In the same way that the ERC20 token standard helped to create a boom in utility tokens, a security token standard would help drive the adoption of security tokens.
In this article, let’s look at the current state of security token standards in the Ethereum ecosystem and each of their approaches to build a self-regulatory governance mechanism for these tokens.
The Case for Tokenization
Security tokens offer the benefit of bringing transparency over traditional paper shares through the use of the blockchain and its associated public ledger. Security token structure, distribution, or changes that could affect investors ca be publicly accessible to all on the blockchain.
Tokenizing private securities also creates opportunities for greater efficiency. Decentralized exchanges enable trades to occur securely between two parties without a middleman. The process and timeline for settlement and clearing of transactions can be condensed significantly, and any reconciliation processes can be greatly simplified. Tokenizing private securities has the potential to significantly reduce costs, increase speed of settlement, and improve security.
Private securities must follow any applicable laws to avoid demanding public filing requirements. These laws can require limiting the number of total investors, only allowing specific types of investors (e.g. accredited investors), implementing a holding period, and applying many other rules.
Restrictions differ by jurisdiction, and compliance with both the issuer’s jurisdiction as well as each investor’s jurisdiction is required. Furthermore, these restrictions apply not only to the initial offering (where much of the responsibility lies on the issuer), but to all secondary trades where responsibility is also placed on the seller.
Enforcing regulatory requirements has been a significant roadblock in the adoption of blockchain-powered securities. Moving the issuance, trading and lifecycle events of a security onto a public ledger requires having a standard way of modeling securities, their ownership, and their properties on-chain.
In order for tokens to comply with securities regulations, tokens need a mechanism to impose transfer restrictions on Token Holders. For example, we may want to:
- Require only Token Holders who have successfully gone through KYC/AML to be able to buy tokens from the issuer during the initial offering, and prevent them from being able to subsequently buy or sell to other parties unless they both have been cleared to do so.
- Restrict transfers based on legal status, jurisdiction, sanctioned countries, global watchlists, and other rules.
- Limit the number of investors.
- Limit the maximum cap of each investor’s holdings.
- Potentially other requirements.
Token standards such as ERC20 does not come with a governance mechanism that ensures token transfers comply with these requirements. A minimum viable compliance layer is to have whitelists of addresses who are validated Token Holders, and only allow transfers between whitelisted addresses. However, for the security token ecosystem to be interoperable with each other a predefined set of standards is necessary.
To solve this problem, we want to devise a self-regulatory mechanism for tokens that is administered by the network and enforced on-chain, allowing parties that trust each other to transact securely. Ideally, we also want this governance mechanism to become more and more decentralized over time.
Security Token Standards
Token Standards such as ERC20 has gained widespread adoption and allowed the interoperability of all kinds of tokens on different exchanges. Security tokens standards builds on top of standards like ERC20 to add the ability to enforce transfer restrictions at the token level. For your reference, here is the ERC20 Standard Token interface that all of the security token standards builds on:
At a high-level, adding transfer restrictions to tokens is straightforward. Consider the ERC20
transfer() function that moves tokens between two addresses:
We can add a single line to add transfer restrictions:
We defined a
canTransfer() function that performs the authorization check of a transfer and require it to return successfully for the transfer to succeed. At minimum, the check would allow all transfers:
We could choose to disallow transfers beyond a certain volume:
The logic within the
canTransfer() function will depend on your specific use cases and securities regulations.
As of October 2018, there are a handful of distinct security token standards proposed and implemented by different parties. In this article we’ll look at each of these standards and see how each compares.
We will examine the following Ethereum security token standards:
An ST-20 token is an Ethereum-based token implemented on top of the ERC-20 protocol that adds the ability for tokens to control transfers based on specific rules. ST-20 tokens rely on Transfer Managers to determine the ruleset the token should apply in order to allow or deny a transfer, be it between the issuer and investors, in a peer to peer exchange, or a transaction with an exchange.
Below is the
IST20 token contract interface:
In ST-20, the
verifyTransfer() function calls external
TransferManager contracts that contains business rules related to transfer restrictions. This approach makes it possible for developers to upgrade these rules over time.
In the above function, the token’s
ITransferManager().verifyTransfer() to find out if a transfer is allowed or disallowed. This method will loop through all the transfer managers it contains and the transfer will be allowed if a transfer manager approves the transaction. Transfer managers implement the following interface:
TransferManager contracts such as Polymath’s
GeneralTransferManager can maintain a whitelist of allowed addresses and any timelocks assigned to that address. This effectively allows transfer restrictions and token holding periods to be implemented at the token level:
KYC/AML processes to verify these addresses are performed off-chain. Once the KYC passes, the results are set on the
TransferManager’s on-chain whitelist to be enforced in both initial and secondary transfers. Only authorized staff addresses are allowed to modify this whitelist of addresses.
R-Token is a permissioned token on the Ethereum blockchain, enabling token transfers to occur if and only if they are approved by an on-chain Regulator Service. The Regulator Service can be configured to meet relevant securities regulations, Know Your Customer (KYC) policies, Anti-Money Laundering (AML) requirements, tax laws, and more. Implemented with the correct configurations, the R-Token standard makes compliant transfers possible, both on exchanges and person to person, in ICOs and secondary trades, and across jurisdictions. R-Token enables ERC-20 tokens to be used for regulated securities.
Here is a reference
Similar to the previous ST-20 standard, the R-Token standard has a
_check(address _from, address _to, uint256 _value) function that is finds out if there are any transfer restrictions for the parties involved:
_check function calls an external
RegulatorService.check() function in a separate regulator contract. This is similar to the ST-20
Here is the
RegulatorService contract interface:
Note that the
uint8status code instead of a
The token stores a
ServiceRegistry contract address in a public variable
registry, and uses this registry contract to retrieve the regulator contract address.
RegulatorService, you can deploy a new version and change the address stored in the
The initial implementation of the Regulator Service relies on an off-chain Trade Controller to update its permissions as well as add newly approved participants.
The Trade Controller determines the status of the permissions. It maps participant data against relevant securities regulations, KYC/AML policies, and tax laws to determine whether each participant can send and/or receive the token. It also determines whether the token is locked/unlocked and whether partial trading is allowed/disallowed. These token-level permissions are then updated in the Regulator Service.
Only an approved Trade Controller with the correct private/public key pair can make changes to the Regulator Service.
The ERC1400 standard is split into several modular sub-standards:
- ERC1410 which defines partially fungible tokens where balances of tokens can have an associated metadata.
- ERC1594 which defines transfer restrictions and core security token functionality.
- ERC1643 which splits out document management functionality.
- ERC1644 which splits out controller operation functionality.
Taken together, the ERC1400 security token standards provide document management, error signalling, transfer restrictions, forced transfers, off-chain data injection, issuance / redemption semantics and expose partially fungible subsets of a token holders balance.
The ERC-1400 standard defines the following notable features:
- Stores legal documents on-chain for reference.
- Most of its token transfer functions accepts a
bytes _dataparameter which allows off-chain data to be entered to pass authorization. Functions also returns a sucess
bytecode with information about the success or failure of the transaction, and a
bytes32application-level response code.
- Unlike previous standards where the validator functions are only available internally, ERC-1400 exposes a standard interface to query if a transfer would be successful and return a reason for failure (with
- Partially fungible token: able to attach metadata to a subset of a token holder’s balance such as special shareholder rights or data for transfer restrictions.
- It defines forced transfers via ERC1644’s
controllerRedeemto allow issuers to reclaim tokens from token holders for legal action or fund recovery.
- The standard uses EIP-1066 compliant application-specific status codes.
Token issuers need a way to restrict transfers of ERC-20 tokens to be compliant with securities laws and other contractual obligations.
ERC-1404 Simple Restricted Token Standard is a simple and interoperable standard for issuing tokens with transfer restrictions. The following draws on input from top issuers, law firms, relevant US regulatory bodies, and exchanges.
Similar to other standards, ERC-1404 has a
detectTransferRestriction() function that returns a
uint status code such as
DISALLOWED. This function is called at the start of token movement functions such as
It also has a
messageForTransferRestriction() function which returns details about the
uint status code.
ERC-1462 is an extension to ERC-20 standard token that provides compliance with securities regulations and legal enforceability.
Similar to other standards, ERC-1462 defines:
- Transfer restriction functions such as
- Legal documentation functions such as
The four new
check*Allowed() functions are used to check that the actions are allowed for the provided inputs. The implementation details of each function are left for the token issuer, it is the issuer’s responsibility to add all necessary checks that will validate an operation in accordance with KYC/AML policies and legal requirements set for a specific token asset.
Each function returns a status code from the common set of Ethereum status codes (ESC), according to ERC-1066.
Bonus: Transaction Permission Layer (TPL)
As we’ve seen in previous standards, aside from the ability to moderate transfers of securities using either an on-chain codified rule set or off-chain approvals, we also want to associate some kind of public data to the addresses involved in the transaction.
However, the identity aspects of transfer restrictions are often outside the scope of a security token standard. This is because there are various identity standards (e.g. ERC725, Civic, uPort) which can be used to capture the party’s identity data, as well as other approaches which are centrally managed (e.g. maintaining a whitelist of addresses that have been approved from a KYC perspective). One such identity standard is TPL.
The Transaction Permission Layer protocol (TPL) is a method for assigning metadata (herein referred to as “attributes”) to Ethereum addresses. These attributes then form the basis for designing systems that enforce permissions when performing certain transactions. Security token transfers are one such transaction, where compliance with various laws and regulations will compel tokens to only permit a transfer once a set of conditions (e.g. identity verification, KYC/AML, or other attributes) have been met.
TPL allows for the creation of digital “jurisdictions” with requirements that are administered and regulated on-chain by one or more projects. Within these jurisdictions, third-party organizations operate as “validators” which identify whether a proposed token transfer is compliant with the requirements of the jurisdiction. Projects can tailor the TPL to limit transfers of their tokens on an ongoing basis, using any criteria that can be recorded in a registry by a validator.
At the core of TPL is the jurisdiction — a single smart contract that links attributes to addresses. It implements an
AttributeRegistry interface, where attributes are registered to addresses as a
uint256 => uint256 key-value pair, defined as follows:
Permissioned tokens and other contracts can then use this interface to identify and confirm attributes recognized by a jurisdiction without needing to take on the additional technical overhead of managing attribute assignment and revocation themselves.
To sum up, TPL allows contracts such as security tokens to verify claims from independent Cerificate Validators. While not a security token standard, TPL offers a key building block to implement decentralized address verifications for transfer restrictions.
Common Security Token Features
To summarize, here are some features that are common across the different security tokens we’ve examined.
KYC / Whitelisting
In the regulated world, almost every investor needs to be qualified with KYC/AML before you send them a security. All of the security token standards that described here can do whitelisting, which means that they keep a list of blockchain addresses that represent investors that are qualified to receive a security. Then, they prevent the transfer of the token to anyone that is not on the list.
If you are selling a private security, you will need to enforce transfer rules so that you send only to qualified investors, according to the different rules of various jurisdictions. You probably also want to enforce lockups, such as the one year lockup for private securities sold in the US. You may have other rules that are typically part of a “subscription agreement” signed by a shareholder.
During the multi-year life of a security, the rules change. The sets of qualified investors change. You may want to provide new features for compatibility with emerging exchanges. You may want to fix your implementation. It’s important to be able to update the source code of an existing token to adapt with evolving requirements.
Decentralized Identity Registries
Some standards use identity contracts that hold investor information and permissions for purposes of enforcing transfer restrictions. This aspect is usually handled by a separate standard such as ERC725 or ERC1484.
In this article, we learned about security tokens. Security tokens has requirements that are fundamentally different from the requirements of the typical cryptocurrency.
We’ve also looked at several security token standards. The open source ecosystem is full of activity, with new standards being published by many different organizations. More than a handful of teams are working towards the goal of regulated security tokens and tokenized assets.
Standards adoption amongst token issuers has the potential to evolve into a dynamic and interoperable landscape of automated compliance. Be sure to keep an eye on this space for new developments.
📬 Get updates straight to your inbox.
Subscribe to my newsletter to make sure you don't miss anything.