-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ERC 1400: Security Token Standard #1411
Comments
From @expede on September 10, 2018 19:55
|
From @darioAnongba on September 11, 2018 10:33
|
From @0age on September 11, 2018 15:18
|
From @dmdque on September 11, 2018 22:18
|
From @zingleton on September 12, 2018 03:23
|
From @0age on September 12, 2018 08:58
|
From @darioAnongba on September 12, 2018 09:30
|
From @fubuloubu on September 12, 2018 13:54
|
From @zingleton on September 12, 2018 15:21
|
From @seathemc on September 13, 2018 14:11
|
From @zingleton on September 13, 2018 14:41
|
From @darioAnongba on September 13, 2018 16:57
|
From @tomohiro-n on September 13, 2018 17:27
|
From @pakaplace on September 13, 2018 17:28
|
From @jllaw on September 13, 2018 18:16
|
From @fubuloubu on September 13, 2018 18:35
|
From @pabloruiz55 on September 13, 2018 19:16
|
From @jllaw on September 14, 2018 08:44
|
From @0age on September 14, 2018 10:30
|
From @rudolfix on September 14, 2018 11:32
|
From @zingleton on September 14, 2018 13:52
|
From @seathemc on September 14, 2018 14:00
|
From @thegostep on September 14, 2018 14:17
|
With regards to the return values of As an example, suppose that transfer failed due to: So the Thanks for providing so much concrete detail around US regulatory rules - very useful for the discussion! It should be possible to ignore the internals of tranches and instead use the ERC777 (or ERC20) send / transfer functions which would use default tranches and on-chain code to determine how to deal with tranches. This is what we were trying to describe in the "ERC20 / ERC777 Backwards Compatibility" section. If you go down this route, then tranches just become an internal implementation detail, but if you want to implement the full ERC 1400 specification you can do which would give users (e.g. token holders, exchanges) more flexibility if they did want to operate on the tranche level. Regarding I can see that getting all tranches (across all users) may have some use cases, although it may make implementations a bit more complex. There is also no guarantee in the standard that the same tranche key across different users would be attached to the same metadata, so tranche keys should generally be interpreted along with the token holder address (there may be implementations where this is not true). Taxation is interesting - possibly this should exist as a separate standard, or as an implementation detail. As an example we recently authored a dividend module which withholds appropriate tax. I love the idea of a communication channel, and communication between issuers and their security holders is critical - will think more about this ;-). We have spoken to some exchanges. Currently they are generally building on top of ERC 20 which makes sense as it is the industry standard for tokens. This EIP is an effort to move the conversation on from ERC 20 to a more specific token specification for securities, but we would expect discussion and adoption to take some time as everyone works through the limitations of ERC 20 and thinks about different ways to address these (of which this EIP is one proposal). Really appreciate your input on this EIP - there is lots to digest and definitely lots of ways to skin a cat here. We will keep thinking about how best to decompose the standard into more digestible chunks which are less constraining. With regard to using multiple tokens with a container, I guess this could be the way that you implement tranches (i.e. a separate token per tranche) in which case the partially fungible token standard still provides a standardised way to interoperate across a container of tokens. Switched over to |
In case it got lost in the issue migration, as per @thegostep there is a community call to discuss this issue kindly organised by @bmann from ETHMagicians and @expede from ERC-1066 #1066. To participate in the call, please sign up here. |
@zingleton we are going to be at Devcon and proposed a talk around Securities Tokens for the Council of Prague the days prior to the main event. You can join here: https://hackmd.io/DaJhrasLQteUk3IwX5bQAg?view |
thanks for listening to our feedback. Looking at the many voices that have chimed in here, it's apparent that the security token ecosystem is bigger and more diverse than maybe any of us realize. There are a number of security token issuers and many of them hail from different jurisdictions and are therefore subject to varying regulations. This impacts how securities are issued and traded and makes it even more imperative that we create a globally-accepted standard that is flexible enough to adapt to these changing circumstances. From my perspective, it appears that it's too soon for us to be discussing a particular interface and instead we need to take a step back and consider the various perspectives on the table. Just as an example, we at Neufund have been working hard on the issuance of security tokens for more than two years. Naturally, we have certain views as to how it should be standardized, some of which I elaborated on in my comments above. I am sure we are not the only ones, and we need to allow all voices to be represented. That said, we are very excited that this discussion is taking place and we want to push forward a security token standard that is sensible for all parties, regardless of geography or differences in legal jurisdictions. I think there are many other projects on Ethereum that are willing to do the same. While it sounds like there were some discussions had at the meeting in Barbados a few months ago, many of us learned about this meeting after the fact from the media, similar to how @zingleton described. In fact, my understanding is that the only major security token issuer represented was Polymath. Obviously, if we want to create a global standard we need input from players like Harbor, Securitize and TrustToken in the US, as well as European and Asian issuers like Neufund, Swarm Fund, SmartValor, Own, Blackmoon, just to name a few. My proposition would be as follow:
We still have time to get this right, and to ensure everyone is heard. Let me know what you think of the above. We will also join for the call on Monday and can discuss there too. |
I’m with rudoflix! Here we are working on creating security tokens for the african continent compatible with USSD and mobile money technology. Mobile phones not both a technological and regulatory challenge that change how security tokens should be created for *people* (I.e. mobile money users), and not just institutions like much of the security token space sometimes seems to prioritize.
We would be eager to contribute our standards to this community as well.
Right on everyone. This is exciting.
Marvin Coleby
Founder
Raise
m: 514 430 1973
w: raiseimpact.io
…On Sep 14, 2018, 7:46 PM +0300, rudolfix ***@***.***>, wrote:
thanks for listening to our feedback. Looking at the many voices that have chimed in here, it's apparent that the security token ecosystem is bigger and more diverse than maybe any of us realize. There are a number of security token issuers and many of them hail from different jurisdictions and are therefore subject to varying regulations. This impacts how securities are issued and traded and makes it even more imperative that we create a globally-accepted standard that is flexible enough to adapt to these changing circumstances. From my perspective, it appears that it's too soon for us to be discussing a particular interface and instead we need to take a step back and consider the various perspectives on the table.
Just as an example, we at Neufund have been working hard on the issuance of security tokens for more than two years. Naturally, we have certain views as to how it should be standardized, some of which I elaborated on in my comments above. I am sure we are not the only ones, and we need to allow all voices to be represented. That said, we are very excited that this discussion is taking place and we want to push forward a security token standard that is sensible for all parties, regardless of geography or differences in legal jurisdictions. I think there are many other projects on Ethereum that are willing to do the same.
While it sounds like there were some discussions had at the meeting in Barbados a few months ago, many of us learned about this meeting after the fact from the media, similar to how @zingleton described. In fact, my understanding is that the only major security token issuer represented was Polymath. Obviously, if we want to create a global standard we need input from players like Harbor, Securitize and TrustToken in the US, as well as European and Asian issuers like Neufund, Swarm Fund, SmartValor, Own, Blackmoon, just to name a few.
My proposition would be as follow:
1. > Create an alliance similar ERC725 alliance (https://erc725alliance.org/) where fundamentals of the standard could be discussed. (what's cool is that the audience seems to be similar including @frozeman, who has been one of our key advisors from the beginning and a prominent Neufund community member). Every project that has commented on this thread, plus everyone else we can think of, should be invited to this alliance.
2. > Organize a satellite event like a workshop at Devcon4 that will be open to all of us and where we can discuss these matters as an alliance, knowing there will be good representation from all sides.
We still have time to get this right, and to ensure everyone is heard. Let me know what you think of the above. We will also join for the call on Monday and can discuss there too.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Following feedback from the token ring, community calls, GitHub & the Telegram group, I have made the following changes: Motivation
Updates
The changes in this update along with some related conversation are collected in a GitHub PR at: |
Hi all, |
@adamdossa Interesting! This is very good stuff! I feel it'd make sense to have a |
Question: Is there a good reason for methods of IERC1594 to return "void"? I'd expect it to be inline with EDIT: |
With use of ERC-1643, can one remove the |
It is very good EIP. I vote for it. |
Hi, |
Can someone explain to me the difference between an "operator" and a "controller"? It seems that both these role are allowed to transfer tokens for other token holders, if authorised. |
I have a question about why ERC1400 is compatible with ERC20? |
Based on the consensys implementation, it would appear to me as if the controller is the "owner" of the token contract, and can therefore conduct forced transfers, set documents, etc, whereas the operators are authorized by the token holders to conduct transfers on their behalf. Can someone please confirm this is correct? |
Consensys Diligence recently made a suggestion or recommendation that Codedefi's implementation of ERC1400 use the Diamond Standard to handle the problem of maximum contract size limit. Would it make sense to mention the Diamond Standard in ERC1400 as a possible solution this problem? Also, of note, ERC-1155 Multi Token Standard, mentions using ERC1538 for upgrading ERC-1155 contracts. The Diamond Standard is an improved version of ERC1538, and like ERC1538 it can be used to create upgradable contracts. Also note that diamonds can be immutable or upgradeable, depending on how they are implemented. Diamonds are ideal for contract systems like tokens that deal with a lot of state and code, because they help you organize your code around contract state without running into the max contract size. An introduction to the Diamond Standard is here: Understanding Diamonds on Ethereum |
Hi everyone, Adrian from SignersTech / PayOnTerm here. Just wondering, has any of you seen or worked on a similar security token implementation but based on ERC-1155 (or any other NFT standard) instead of ERC-20 ? I'm thinking of use cases where creating a separate smart contract for each token seems a bit of an overkill in terms of compute (and cost), and where many different security tokens (issued by various issuers or at various points in time) may share the same ruleset for interoperability |
Great! Please consider using EIP-2535 Diamonds now which is based on ERC1538 and is better. |
There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
Closing this issue for housekeeping purposes. People are welcome to continue discussing in this thread, but for additional visibility an EIP should be created or the conversation should be migrated to https://ethereum-magicians.org/ |
eip: ERC-1400
title: Security Token Standards
author: Adam Dossa (@adamdossa), Pablo Ruiz (@pabloruiz55), Fabian Vogelsteller (@frozeman), Stephane Gosselin (@thegostep)
discussions-to: #1411
status: Draft
type: Standards Track
category: ERC
created: 2018-09-09
require: ERC-1410 (#1410), ERC-1594 (#1594), ERC-1644 (#1644), ERC-1643 (#1643), ERC-20 (#20), ERC-1066 (#1066)
Simple Summary
Represents a library of standards for security tokens on Ethereum.
In aggregate provides a suite of standard interfaces for issuing / redeeming security tokens, managing their ownership and transfer restrictions and providing transparency to token holders on how different subsets of their token balance behave with respect to transfer restrictions, rights and obligations.
Abstract
Standards should be backwards compatible with ERC-20 (#20) and easily extended to be compatible with ERC-777 (#777).
ERC-1410 (#1410): differentiated ownership / transparent restrictions
ERC-1594 (#1594): on-chain restriction checking with error signalling, off-chain data injection for transfer restrictions and issuance / redemption semantics
ERC-1643 (#1643): document / legend management
ERC-1644 (#1644): controller operations (force transfer)
Motivation
Accelerate the issuance and management of securities on the Ethereum blockchain by specifying standard interfaces through which security tokens can be operated on and interrogated by all relevant parties.
Taken together, these security token standards provide document management, error signalling, gate keeper (operator) access control, off-chain data injection, issuance / redemption semantics and expose partially fungible subsets of a token holders balance.
Requirements
Moving the issuance, trading and lifecycle events of a security onto a public ledger requires having a standard way of modelling securities, their ownership and their properties on-chain.
The following requirements have been compiled following discussions with parties across the Security Token ecosystem.
Rationale
ERC-1594: Core Security Token Standard
Transfers of securities can fail for a variety of reasons in contrast to utility tokens which generally only require the sender to have a sufficient balance.
These conditions could be related to metadata of the securities being transferred (i.e. whether they are subject to a lock-up period), the identity of the sender and receiver of the securities (i.e. whether they have been through a KYC process, whether they are accredited or an affiliate of the issuer) or for reasons unrelated to the specific transfer but instead set at the token level (i.e. the token contract enforces a maximum number of investors or a cap on the percentage held by any single investor).
For ERC-20 tokens, the
balanceOf
andallowance
functions provide a way to check that a transfer is likely to succeed before executing the transfer, which can be executed both on and off-chain.For tokens representing securities the standard introduces a function
canTransfer
/canTransferByPartition
which provides a more general purpose way to achieve this when the reasons for failure are more complex; and a function of the whole transfer (i.e. includes any data sent with the transfer and the receiver of the securities).In order to provide a richer result than just true or false, a byte return code is returned. This allows us to give a reason for why the transfer failed, or at least which category of reason the failure was in. The ability to query documents and the expected success of a transfer is included in Security Token section.
In order to support off-chain data inputs to transfer functions, transfer functions are extended to
transferWithData
/transferFromWithData
which can optionally take an additionalbytes _data
parameter.ERC-1410: Partially Fungible Tokens
There are many types of securities which, although they represent the same underlying asset, need to have differentiating data tied to them.
This additional metadata implicitly renders these securities non-fungible, but in practice this data is usually applied to a subset of the security rather than an individual security. The ability to partition a token holder's balance into partitions, each with separate metadata is addressed in the Partially Fungible Token section.
For example a token holder's balance may be split in two: those tokens issued during the primary issuance, and those received through secondary trading.
Security token contracts can reference this metadata in order to apply additional logic to determine whether or not a transfer is valid, and determine the metadata that should be associated with the tokens once transferred into the receiver's balance.
Alternatively a security token can use this mechanism simply to be able to transparently display to investors how different subsets of their tokens will behave with respect to transfer restrictions. In this case, the balances could be determined programatically.
ERC-1643: Document Management Standard
Security tokens usually have documentation associated with them. This could be an offering document, legend details and so on.
Being able to set / remove and retrieve these documents, and having events associated with these actions allows investors to stay up to date with documentation on their investments.
This standard does not provide any way for an investor to signal on-chain that they have read, or agree, with any of these documents.
ERC-1644: Controller Token Operation Standard
Since security tokens are subject to regulatory and legal oversight (the details of which will vary depending on jurisdiction, regulatory framework and underlying asset) in many instances the issuer (or a party delegated to by the issuer acting as a controller, e.g. a regulator or transfer agent) will need to retain the ability to force transfer tokens between addresses.
These controller transfers should be transparent (emit events that flag this as a forced transfer) and the token contract itself should be explicit as to whether or not this is possible.
Examples of where this may be needed is to reverse fraudulent transactions, resolve lost private keys and responding to a court order.
Specification
This standard does not specify any additional functions, but references ERC-1410 (#1410), ERC-1594 (#1594), ERC-1643 (#1643) and ERC-1655 (#1644) as an underlying library of security token standards, each covering a different aspect of security token functionality.
In order to combine these two standards, the additional constraints are specified.
operatorTransferByPartition
If the token is controllable (
isControllable
returnsTRUE
) then the controller may useoperatorTransferByPartition
without being explicitly authorised by the token holder.In this instance, the
operatorTransferByPartition
MUST also emit a ControllerTransfer event.Correspondingly, if
isControllable
returnsFALSE
then the controller cannot calloperatorTransferByPartition
unless explicitly authorised by the token holder.operatorRedeemByPartition
If the token is controllable (
isControllable
returnsTRUE
) then the controller may useoperatorRedeemByPartition
without being explicitly authorised by the token holder.In this instance, the
operatorRedeemByPartition
MUST also emit a ControllerRedemption event.Correspondingly, if
isControllable
returnsFALSE
then the controller cannot calloperatorRedeemByPartition
unless explicitly authorised by the token holder.Default Partitions
In order for
transfer
andtransferWithData
to operate on partially fungible tokens, there needs to be some notion of default partitions that these functions apply to. The details for how these are determined (e.g. either a fixed list, dynamically, or usingpartitionsOf
) is left as an implementation detail rather than defined as part of the standard.When transferring tokens as part of a
transfer
ortransferWithData
operation, these transfers should respect the invariant of partially fungible tokens, namely that the sum of the balances across all partitions should equal to the total balance of a token holder.Interface
Notes
On-chain vs. Off-chain Transfer Restrictions
The rules determining if a security token can be sent may be self-executing (e.g. a rule which limits the maximum number of investors in the security) or require off-chain inputs (e.g. an explicit broker approval for the trade). To facilitate the latter, the
transferByPartition
,transferWithData
,transferFromWithData
,canTransferByPartition
andcanTransfer
functions accept an additionalbytes _data
parameter which can be signed by an approved party and used to validate a transfer.The specification for this data is outside the scope of this standard and would be implementation specific.
Identity
Under many jurisdictions, whether a party is able to receive and send security tokens depends on the characteristics of the party's identity. For example, most jurisdictions require some level of KYC / AML process before a party is eligible to purchase or sell a particular security. Additionally, a party may be categorized into an investor qualification category (e.g. accredited investor, qualified purchaser), and their citizenship may also inform restrictions associated with their securities.
There are various identity standards (e.g. ERC-725 (#725), 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). These identity standards have in common to key off an Ethereum address (which could be a party's wallet, or an identity contract), and as such the
canTransfer
function can use the address of both the sender and receiver of the security token as a proxy for identity in deciding if eligibility requirements are met.Beyond this, the standard does not mandate any particular approach to identity.
Reason Codes
To improve the token holder experience,
canTransfer
MUST return a reason byte code on success or failure based on the EIP-1066 application-specific status codes specified below. An implementation can also return arbitrary data as abytes32
to provide additional information not captured by the reason code.0x50
0x51
0x52
0x53
0x54
0x55
0x56
0x57
0x58
0x59
0x5a
0x5b
0x5a
0x5b
0x5c
0x5d
0x5e
0x5f
These codes are being discussed at:
https://ethereum-magicians.org/t/erc-1066-ethereum-status-codes-esc/283/24
References
Copied from original issue: #1400
The text was updated successfully, but these errors were encountered: