Share with your friends:

The team at Polymath, along with external contributors including Stephane Gosselin, published ERC-1400 around two months ago, following an extensive discussion and round table.

Since then we’ve had a huge amount of interest and discussion on the GitHub ERC issueEthereum MagiciansTelegramcommunity calls and the Security Token Ring session during the Council of Prague.

The engagement from the community has been overwhelming and reinforced the need for a flexible, consensus-driven, standard for security tokens. We’ve also seen a number of other ERCs published in the same space; some with overlapping functionality and others with a different perspective or focus.

The conversation around ERC-1400 has reached a level of consensus on a number of issues, and we have updated the standard to reflect these. These are discussed in more technical detail below — we will shortly be releasing some additional guidance around ERC-1400 aimed at less technical audiences.

TLDR

Motivation

  • Clarify use of tranches / partitions primarily as a mechanism to add transparency to the non-fungible subsets of a token holders balance.
  • Ease adoption by providing a security token standard that does not include partitions.
  • Move to ERC-20 from ERC-777.
  • Provide a route to adoption / implementation which is more incremental.

Updates

  • Modify ERC-1410 to make it un-opinionated on ERC-20 vs. ERC-777rather than a direct descendant of ERC-777.
  • Rename “tranches” to “partitions” in ERC-1410.
  • Create ERC-1594 which splits out the core security token functionality.
  • Create ERC-1643 which splits out document management functionality.
  • Create ERC-1644 which splits out controller operation functionality.
  • Modify ERC-1594 to be based on ERC-20 rather than ERC-777.
  • Modify ERC-1400 to be an umbrella of ERC-1410ERC-1594ERC-1643and ERC-1644 with a few additional constraints to make these standards interoperate.

The changes in this update are collected in a GitHub PR at https://github.com/SecurityTokenStandard/EIP-Spec/pull/6.

To Tranche Or Not To Tranche?

The standard introduced the concept of a partially fungible token that provides transparency over the partitions of a token holder’s balance that may be treated differently by the security token for the purposes of transfer restrictions.

The term “tranche” was used to describe one of these partitions, but led to some confusion as this term is already in wide usage in capital markets, generally to represent subsets of securities with different investment or risk characteristics.

Whilst this is similar to our aim with incorporating the partially fungible standard in the security token standard, there is a subtle difference. Each tranche in a security token represents the same underlying asset (with the same investment / risk characteristics) — instead, each partition represents differentiated ownership over those tokens, which are reflected in different transfer restrictions and related attributes.

For example, tranches (partitions) may partition a token holder’s balance into those securities which are locked on a vesting schedule versus those which are fully unlocked.

To address this confusion, the update renamed “tranches” to “partitions” and added some additional description around its intended usage and interpretation.

Standard Decomposition

Whilst we believe it is important to provide transparency into how different partitions of a token holder’s balance may be treated, this may not be applicable to all security token use-cases, and is complex to implement.

In order for this not to be a barrier to adoption we have split out the core security token standard interface into a separate ERC-1594. This ERC contains the security token functionality without the partially fungible token portion (aka tranches / partitions) and should be an easier target for adoption whilst still providing standardisation across core securities functionality.

We have also split out two other areas of security token functionality — document management and controller operations (aka forced transfers). These are collected in ERC-1643 and ERC-1644 respectively with a similar rationale.

ERC-1400 then becomes an umbrella standard that incorporates ERC-1594(core functionality), ERC-1410 (partially fungible tokens), ERC-1643(document management) and ERC-1644 (controller token operation) with some additional constraints to ensure these standards interoperate in a consistent manner.

In the future we envisage new standards related to security tokens (e.g. dividends, governance, exchange related) being added to ERC-1400, with the requirement that each standard can interoperate with other standards in the library and represents a level of consensus in the ecosystem.

ERC-20 vs. ERC-777

When we first put together ERC-1400 we decided to base it on ERC-777 rather than ERC-20. This was motivated by several improvements that ERC-777introduced, most notably around the interaction between tokens and smart contracts.

However it remains the case that the vast majority of token implementations today conform to ERC-20 rather than ERC-777, and the ERC-777 specification is still being debated and finalised. Being compliant with ERC-777 also puts some additional constraints on smart contracts that want to interact with tokens which adds additional complexity.

To address this reality, ERC-1594 has been updated to be based off ERC-20 rather than ERC-777. The partially fungible token standard (ERC-1410) has been modified to be un-opinionated on ERC-20 vs. ERC-777 and can be used in conjunction with either.

It would be relatively straightforward to extend ERC-1400 to also incorporate ERC-777 (backwards compatibility with ERC-20 being one of the design drivers for ERC-777) but this is not enforced by the standard.

Summary

It has been a great experience to see so many different groups, individuals and companies come together to try and reach consensus around a sensible security token standard, and we’re looking forward to the road ahead.

The (non-exhaustive) list of groups participating in this effort can be seen at https://thesecuritytokenstandard.org/, and thanks goes to all of those who have contributed across the many forums and discussions.

(This article is originally posted by Adam Dossa on Polymath Blog.)