Today, developer Stephane Gosselin posted a new proposal for a security token standard, titled ERC1400, on GitHub. The purpose of this new token standard is to better enable regulatory compliance for parties offering securities on the Ethereum network.
The standard was written by Gosselin, Adam Dossa, Pablo Ruiz, and Fabian Vogelsteller. Gosselin and Dossa work for Polymath, a "decentralized protocol that makes it easier to raise capital and create security tokens," while Ruiz has a background in international business and finance, and Dossa is an Ethereum developer and web designer.
The authors specify that the ERC1400 should be ERC20 and ERC777 compliant, but that security tokens differ considerably from utility tokens and require more complex interactions between on-chain and off-chain actors and therefore require their own standard.
The requirements laid out in the EIP include that such a standard must have the ability to force transfers "for legal action or fund recovery." The authors explain that "it may be that regulations require an issuer or a trusted third party to retain the power to transfer tokens on behalf of investors."
The tokens must also be non-fungible (or at least "partially-fungible") so they can allow for the attachment of modifiable metadata specifying unique conditions for transfer. In other words, ERC1400 tokens must allow parties offering securities to grant or deny transactions based on a set of conditions.
Partial-fungibility is a primary component of the ERC1400 token standard. That means one ERC1400 token issued by the same entity could be non-exchangeable with another ERC1400 token, because the tokens could have different properties. The most popular non-fungible tokens are, of course, CryptoKitties, which are based on the ERC721 standard: You wouldn't just trade one kitty for another straight up, because each one is unique and their prices vary. However, ERC1400 tokens are not necessarily as different from each other as CryptoKitties – hence their being "partially-fungible."
Whereas with ERC20-based tokens a transaction will only be rejected if the sender does not have enough funds, this token standard should allow for further (and modifiable) conditions. Some examples the authors provide are:
- Whether the security being transferred is subject to a lock-up period.
- Whether the sender and receiver have been through the KYC process.
- Whether the issuer is accredited.
- Whether the token contract enforces a maximum number of investors or cap on the percentage held by a single investor.
Another key component of the ERC1400 token standard and its modifiable metadata (read: partial-fungibility) is that the token standard specifies the ability for a token holder's balance to be separated between tranches. "A what?" you ask? A tranche is a way of structuring debt-based investments. These securities combine "slices" of high- and low-risk debts that have varying end dates into a pool to minimize the risk for an investor and provide a longer-term investment. For example, you might have a mortgage-backed security tranche that contains high- and low-risk mortgages varying from 5- to 30-year terms. The ERC1400 standard-based tokens would allow for this kind of investment opportunity.
The tokens must also allow the ability to query whether a party's transaction would be successful, as well as a reason in case of transaction failure. Reasons given must be based on EIP-1066 application-specific status codes, though the authors specify that reasons given may extend beyond the EIP1066 framework. EIP1066 status codes are listed below:
An ERC token standard is one Ethereum Improvement Proposal (EIP) subtype. EIPs go through a series of steps before they are considered final. ERC1400 is currently in draft stage, which means that it has been deemed fit for consideration and feedback by the Ethereum community by an EIP editor, and it has been assigned its official number (1400). Except in the case of core track EIPs, proposals must be implemented prior to entering the "last call" status. The time between a proposal entering draft status and reaching last call varies, but there is often a long period of development, edits, implementations, and bug-fixing, and many EIPs don't end up gaining the necessary traction. If a proposal makes it as far as last call, then it stays there for a minimum of two weeks in order to give the community time to provide commentary or raise concerns prior to finalization. In other words, this is only the start of what will likely be a long journey for ERC1400.