ERC-1400: Ethereum Security Token Standard Explained

ERC-1400: Ethereum Security Token Standard Explained

ERC-1400 is a proposed standard for the issuance and management of security tokens on the Ethereum blockchain. Security tokens can be thought of as any blockchain-based representation of value that is subject to securities regulation. This representation of value can include traditional assets such as: equity securities (stocks), debt securities (bonds) and derivatives (forwards, futures, options and swaps). Authors of ERC-1400 include:

  • Adam Dossa – Director of Technology at Polymath
  • Pablo Ruiz – VP Engineering at Polymath
  • Fabian Vogelsteller – Founder at LUKSO
  • Stephane Gosselin – Digital Securities Researcher

ERC-1400: Ethereum Security Token Standard

ERC-1400 can be thought of as being a library of security token standards, with these standards being known as the: Core Security Token Standard, Partially Fungible Token Standard, Document Management Standard and Controller Token Operation Standard. Each of these standards represent a different way of modelling the lifecycle, trading and management of securities on the Ethereum blockchain. Each of these standards are stand-alone, but can be integrated in a variety of ways to reflect the distinctness of a particular jurisdiction or asset class, whilst also maintaining interoperability.

The issuance and management of securities on a public blockchain such as Ethereum require that there be a standard manner with which to model securities, their ownership and also their on-chain properties. ERC-1400 proposes the following requirements:

  • MUST have a standard interface to query the successful execution of a transfer, and in the event of a failed transfer, return a reason for failure.
  • MUST be able to perform a forced transfer for legal action or fund recovery.
  • MUST emit standard events for issuance and redemption.
  • MUST be able to attach metadata to a token holder’s balance such as shareholder rights or data for transfer restrictions.
  • MUST be able to modify metadata at time of transfer based on off-chain data, on-chain data and the parameters of the transfer.
  • MUST support querying and subscribing to updates on relevant documentation for the given security.
  • MAY require signed data to be passed into a transfer transaction in order to validate its on-chain execution.
  • SHOULD NOT restrict the range of asset classes across jurisdictions which could be represented.
  • MUST be ERC-20 compatible.
  • COULD be ERC-777 compatible.

ERC-1594: Core Security Token Standard

It is expected that the core functionalities laid out in ERC-1594 will be needed for all security tokens created under the ERC-1400 umbrella standard. ERC-1594 serves as a standard to support off-chain injection of data into: transfers, issuance, redemption and also the ability to check the validity of a transfer.

Injecting Off-Chain Data

In order for securities to be properly integrated into a decentralized blockchain-based ecosystem, the transfer of these assets must incorporate both on-chain rules and data (such as smart contracts and global state), as well as off-chain input and authorizations. ERC-1594 is designed to support these off-chain inputs and authorizations, by facilitating for the off-chain injection of data.

Trading Restrictions

ERC-1594 also supports on-chain functionality that could determine whether a transfer will succeed, and in the event that it does not succeed, return details explaining the reason for the transfer’s failure. Such a failure could occur for a variety of reasons, such as:

  • Intended recipient of security tokens may not have been KYC’ed.
  • Securities are subject to a lock-up period.
  • Token contract enforces a maximum number of investors or a cap on the percentage held by any single investor.

A proposed advantage of this functionality is that it enables exchanges and wallet services to provide a more sophisticated user experience, as they are able to provide detailed explanations in case of a failed securities transfer.

Token Issuance and Redemption

This standard also provides functionality to enable a security token issuer to specify when issuance for the security token has finished, and also allows a token holder to redeem tokens. All redeemed tokens are subtracted from the total supply and the token holder’s balance. This set-up can be likened to existing token implementations under ERC-20, where token minting and burning is commonplace.

ERC-1410: Partially Fungible Tokens

A partially-fungible token allows for the attaching of metadata to the partial balance of a token holder. This standard describes an interface in which an owner’s tokens can be organized into a set of partitions, with each partition being represented by a corresponding key and balance. This partition functionality allows for the attaching of metadata to individual fungible tokens. This is significant, as it provides more flexibility in how one constructs the functionality of these tokens. For example, metadata such as the date that a token was minted allows for vesting and lock-up functionality to be implemented on a portion of a token holder’s balance.

ERC-1643: Document Management Standard

Securities, whether they have been issued digitally or traditionally will always be accompanied with corresponding documentation. ERC-1643 provides a standard to support the attaching of documentation to security token contracts, and a standard interface for querying and modifying these contracts. The standard also enables token holders to receive updates on these documents. An example of documents to be covered under this standard include offering documents. An attached document could also include a cryptographic hash of its contents to serve as an immutability guarantee.

ERC-1644: Controller Operations

This standard allows a party, for example the issuer, regulator or anyone else acting as a controller, to retain the ability to force the transfer of security tokens between addresses. Because security tokens are subject to regulation, an individual running afoul of regulatory rules e.g. fraudulent transactions, may require that the ability to force token transfers be exercised. Other instances in which this ability may be exercised is in the case of: lost private keys or responding to a court order.

More information on ERC-1400 can be found here: ERC-1400: Security Token Standard.