ERC-1400: Security Token Standard

[thegostep]

Discussion moved to:
EIP 1400 [#1411] Security Token Standard
EIP 1410 [#1410] Partially Fungible Token Standard

[expede]

👍👍👍 This looks super awesome! I previously worked for a security token company, and am very, very happy to see this work being done 🎉 We also did some preliminary open work in this general space with ERC-902.

---

I'm the primary author of ERC-1066 (Hello! 👋) As of Sept 1, we're throwing a ton of time and energy into the ESC project (growing an FOSS team, my time at 100% for at least the next several months, we're in the FOSS track at the Tachyon Accelerator, etc). Expect big things 😉

Application-Specific Codes

The function will return both a ESC (Ethereum Status Code) following the EIP-1066 standard, and an additional bytes32 parameter that can be used to define application specific reason codes with additional details (for example the transfer restriction rule responsible for making the send operation invalid).

The 0xA* category range allows people to map their custom codes into the standard. This may or may not fit what you're thinking of using custom codes for. It may warrant more discussion, and at minimum some examples on our end to better describe that system.

Use Case Abstraction

Protocols are essentially abstractions over common use cases. We're doing a bunch of R&D around filling in the currently empty ranges in appropriate, flexible, reusable ways. Security tokens will almost certainly be a widely used standard, and common patterns will inspire other work in the ecosystem (like ERC20 -> ERC721).

We're gathering data from as many people as possible so that we can design the most useful code scheme. I'd love to hop on a call (phone or video), email thread, or even over at EthMagicians. We're going to be running regular community hangouts as well. Let me know what works for you!

[darioAnongba]

Awesome! I am also currently reviewing this EIP, looks good so far.

[0age]

Nice work! This is very thorough and addresses many of the most pressing issues concerning compliant securities tokens. One observation (and I doubt I am alone in this determination) is that this EIP comes with a great deal of complexity. Now, much of that is surely inherent to the problem space, but when it comes to ERC proposals in particular it's apparent that keeping it simple is of utmost importance, both for promoting widespread adoption and for encouraging secure best practices (and of course leaving the door open for extensibility). With that in mind, here are a few contrasting viewpoints:

• A ton of the complexity is derived from the logic around tranches, and setting, managing and transferring between them. The idea of "partial fungibility" seems a bit disingenuous - either an asset is fungible or it is not. Obviously, securities DO often have tranches and so should support it, but in cases where they DON'T, this pattern is going to add a lot of overhead (both gas and extra headaches). Why not just implement tranches as separate tokens (TOKEN-A-CLASS, TOKEN-B-CLASS, etc.) with their own logic, permissions, and balances, then issue, aggregate, and convert between them as needed? Maybe this portion of the EIP could be broken out into its own EIP, and tranchedSecurityToken could then attach to a number of tokens representing various classes where applicable and provide the various getters, setters, and view functions laid out in this section, including its own balanceOf & totalSupply methods that sum each referenced tranche / class.

• The provision requiring forced transfers could prove a poison pill for the proposal, and at a minimum will tend to politicize the debate around this standard and detract from the technical considerations. It also requires much of the ERC-777 functionality as structured now, but ERC-777 support is designated as optional (and should be - there are not many projects implementing the full spec in the wild as of yet). Why not just split it off into a dedicated EIP for forceableSecurityToken or the like?

• If securities tokens prefer to delegate the management of metadata and transfer permissions to an external contract or outside jurisdiction, there is still a great case for providing checkSecurityTokenSend directly from the token (I like canTransfer and canTransferFrom but that's just one opinion 😉). However, the requirement to be able to set and modify metadata, including at the time of transfer, right from the securities token could prove onerous and inefficient in many of those instances.

Basically, a slimmed-down proposal containing the key sections of this EIP would be much easier to build widespread consensus around. The goal is to promote interoperability between a diverse ecosystem, not full compliance for every conceivable securities token in every potential jurisdiction. From there, incremental ERCs could continue to enhance the features (or bugs, according to many crypto-maximalists 🐛) available to protocols around securities tokens - and of course any particular securities token could always go beyond the initial requirements.

Also, a small aside - unless I'm mistaken, the implementation is currently susceptible to integer overflow & underflow vulnerabilities.

Awesome work and thank you all for putting this proposal together!

[dmdque]

• I agree with 0age about the complexities of tranches. It's an ambitious effort, but tranches feel like a secondary priority, and would require a base security token standard to be finalized first anyway. I think a simplified version of this EIP will go much further.
• I love that you included EIP1066 here, they work really well together.
• Forced transfers are an important topic which needs to be explored further. This is a can of worms from an exploit perspective, but a necessary evil for adoption. Restricted transfers are straight-forward because of checkSecurityTokenSend (+1 for canTransfer) which allows checking ahead of time. Should we limit the transfers that can be forced to make them more predictable? I think there's value in exploring this.
• Should transfer freezes be considered as well? The crypto enthusiast in me doesn't want this, but trading halts are a common occurence.
• A note on the one-way nature of issuance: I consider this a "soft requirement" since it's difficult to enforce and impossible to verify on-chain. Soft requirements are too easily avoidable in practice, which causes a rift across implementations.
  • It reminds me of the many ERC20 "SHOULD" requirements that weren't implemented across the board, and resulted in tokens being "mostly" ERC20. (eg. returning false rather than reverting for transferring with insufficient balance.) This caused annoyances downstream, where token interaction proxies are required to bridge the gap.
  • There may be value in removing this since projects are likely to walk their own path. Future applications may incorrectly assume that issuable is one-way because it's in the standard, resulting in bugs and headaches. Also, there are valid reasons to issue again, such as secondary offerings. (It doesn't suffice to leave issuable on because it's hard to predict that a secondary offering will be had.)

Overall this is a great start. Companies are run by people who make mistakes, and need wiggle room. A big challenge for security tokens is the lack of flexibility on the blockchain. I think this EIP addresses this with the forced and restricted transfers.

[zingleton]

I think this is great stuff.

I like the tranches. I am new to this discussion and I have no idea what the original use case was, but I can make an informed guess. They are the best way that I have seen to implement US Reg D/Reg S rules. Under the Reg S rule, I can sell US securities to a non-US buyer, and they can trade those securities, but they can't sell them back to a US buyer until one year has passed from the issue date. If the Reg S sale from a particular date is in one tranche, we can track and enforce this rule. Almost any other way to do it is more complicated, and wrong. So, tranches are actually a simplification in this case.

Reg D lockups should also be handled by tranches for a particular issue date. The Reg D rules say that a US buyer of a private security should hold it as "restricted" for a year. This is almost always implemented with a lockup on the buyer, where the buyer can't sell the security until one year has passed. However, the lockup implementation is not accurate. A fund with more than $100M in assets under management (QIB or Qualified Institutional buyer) can buy the Reg D securities before the lockup has expired. They get this privilege from "rule 144a". The restriction on resale to anyone BUT a QIB continues for the remainder of the year - as measured by the properties of the security issue tranche, not the buyer. These rule 144a privileges are socially offensive, in giving special privileges to wealth, but they are likely to be quite important in the real world of US private market securities.

In this use case, multiple tranches represent the SAME security. That's important. They are not like the tranches of an asset backed security that are designed to be different. They are the same security with different transfer rules. They all add into the same cap table percentages for voting and distributions. So, splitting them into different tokens screws up all the numbers. Some people are splitting one security into different tokens so they can track a Reg S issue. This is a bad solution and a lot more complicated to put back together into relative percentages than just implementing these tranches. The tranches are a simplification.

You do want the ability to collapse two tranches into one. They represent the same security. For example, Reg D and Reg S tranches issued on different dates can often be collapsed when the US restrictions expire in a year.

The tranches can themselves be simplified. If they all represent the same security, then I can't see why you would want different permissions and operators. That feature could be eliminated. It would make sense to go through and remove extra tranche operations and features.

Security tokens need to be pausable (freeze transfers). Under any reasonable disclosure regime, if a company finds out some big news that will affect their traded securities, they should freeze transfers until they can make a public disclosure. If they don't they WILL get sued in the US. Lawyers file thousands of shareholder lawsuits every year alleging they bought securities without knowing some important thing that the company had not revealed yet. That's their standard "securities fraud" complaint about anything they don't like. A blockchain mechanism that allows issuers to "pause" or block transfers right on the token is a big step forward for securities that are traded in multiple venues and OTC. Maybe this doesn't need to be in this spec but it does need to be somewhere in the implementation. I think "pausable" is pretty common in the Zeppelin-derived ERC 20 implementations. So, I guess that shows it doesn't need to be in the standard. The standard needs to describe the functions that would be used by handlers like exchanges and wallets to deal with multiple types of securities. Maybe it doesn't need to describe features (like pause/freeze) that are only used by the issuer.

Forced transfers are required for real security. If an issuer sells securities to grandma, and she dies and leaves no key, the issuer still needs to deliver the securities to her estate under most securities regimes. Issuers have to be able to print up a new stock certificate. Maybe it doesn't have to be in the standard, but it has to be in the implementation. This standard makes it easy to add multisig governance to that, which is how we handle it. However, forced transfer is also something that the issuer does (with multisig arbitrators), and not the exchanges and wallets that rely on a standard.

[0age]

Great information, @zingleton - thanks for laying out lots of concrete details related to US Reg D / Reg S. You make a strong case for utilizing tranches to enforce these regulations, but i’m not yet convinced that it should be a mandatory part of the global standard - what about all the jurisdictions that don’t require adhering to these regulations?

Maybe a good place to start would be to specify a much simpler permissionedToken interface that addresses the following requirements:
• MUST have a standard interface to query if a transfer would be successful and return a reason for failure.
• MAY be able to modify metadata at time of transfer based on off-chain data, on-chain data and the parameters of the transfer.
• MAY require signed data to be passed into a transfer transaction in order to validate it on-chain.
• MUST be ERC20 compatible.
• SHOULD be ERC721 compatible.
• SHOULD be ERC777 compatible.

Then, these interface requirements can be utilized and expanded on by a wide variety of securities tokens (and other projects), including a securities token standard with all of the bells and whistles that a US-compliant securities token would need (and then optionally overloading the transfer check with a tranche argument as required would be a natural choice).

Concerning forced transfers, “grandma loses her key” is a strong analogy as well - i’m just pointing out that this will be a contentious issue that may benefit from isolation from the rest of the proposal.

[darioAnongba]

I agree with @zingleton on this:

The standard needs to describe the functions that would be used by handlers like exchanges and wallets to deal with multiple types of securities. Maybe it doesn't need to describe features (like pause/freeze) that are only used by the issuer.

The standard is needed for interoperability between different entities, potentially all across the globe. Implementation specifics shouldn't be part of the standard. Now, the question is, are tranches needed in the standard to facilitate interoperability? (even if using a single default tranche for tokens that don't need it). I personally believe that yes, tranches are necessary in the standard. This would ease integration instead of having to deal with multiple token classes.

[fubuloubu]

I believe the tranches approach is actually better than having separate classes of tokens. Both are equally viable options, but there might significantly complex reclassification rules for a token to change tranches, and the properties of that transfer would be more difficult to evaluate from a (software) security standpoint than if the logic were handled internal to the contract.

I also think this semi-fungible concept is very useful from other standpoints: one could imagine a reputation token that had different subcategories depending on how it was earned. Being able to subcategorize a token based on different properties a subset of holdings should have is very interesting. I think this should be separated into a different, dependent standard and developed separately to reduce the complexity of this proposal.

Just picture a pie chart of your holdings, denominated by tranches. Very useful concept.

---

I also think there should be a getAllTranches or similar that returns all possible tranches any holder in the contract could have. Right now, it is dependent on the holder to delineate what they personally could have, so I could see this as useful.

[zingleton]

It might be possible to hide the tranches so that you would have an option to:

• not use them (the default tranche is an implementation of this)

• include them in the security, but have the token code itself figure out how to use them. On "send", the script would try to figure out what tranche can be sent (has an appropriate balance, passes transfer rules). This would be an extension of the idea of a default tranche to a default send.

• Use them directly. I think they should appear in the standard because exchanges and wallets will want to understand what tranches are available.

[seathemc]

This was really cool to read through. Couple of questions:

1. Is there no room to include that there must be some kind of consideration/standard for the taxation of these securities - perhaps included in the metadata?

2. Also, what about a communication channel between the issuers, and the purchasers? One of the mainstays of public and private securities is that an issuer is meant to build a 'community' with their investors/shareholders - and there should be an open line of communication. In line with the thoughts by @darioAnongba, is it not appropriate to create standards for exchanges to follow to create some kind of communication channel/voting mechanism between issuers and shareholders/STO purchasers?

[zingleton]

I like the idea that the security standard provides some basic support for both public docs (as included) and private messaging.

Messaging would go into a different type of standard with a more general mission. Basically, the messaging that is needed is a global queue where you can post encrypted messages for an Ethereum address, or content hash pointers to encrypted messages. They would be posted for a specific public key, from a specific address. For this to work, you would also need a database that matches an Ethereum address or similar blockchain address to a full public key. Probably you would accept a variety of addresses to go cross-chain. There must be implementations of this since it is such a common need. The security token standard would then only require a way to show the address of an issuer or other party that would send and receive messages.

Voting would probably go into a different but similar queue. What you want is proxy assignment and proxy voting AKA "liquid democracy". That would not be part of the standard and it doesn't need to be decentralized.

[darioAnongba]

Is there no room to include that there must be some kind of consideration/standard for the taxation of these securities - perhaps included in the metadata?

I think you answered your own question. Taxation cannot be directly written in the standard as it is specific to jurisdictions

Also, what about a communication channel between the issuers, and the purchasers? One of the mainstays of public and private securities is that an issuer is meant to build a 'community' with their investors/shareholders - and there should be an open line of communication. In line with the thoughts by @darioAnongba, is it not appropriate to create standards for exchanges to follow to create some kind of communication channel/voting mechanism between issuers and shareholders/STO purchasers?

Would be interested to know if an EIP exists for that!

[tomohiro-n]

Great work!

I like the tranche's extensibility. Even if the token has solely default tranche at first but it may be going to have another.

On the other hand, I'd like to hear secondary markets' thoughts on this tranches-or-tokens discussion.
One thing which may go very complex is that prices can be set per tranche, per group of tranches, or per token. I don't think It would be necessary to include the practical manner in the standard but we may want to use tranches on the condition that all tranches under the token should have the same price? In other words, issuing another token may be better if we expect them to have different prices.

[pakaplace]

Really high-quality thread here. We at Meridio have been refining our security token contract- an upgradeable security token issued per-asset with modular validation checks on transfer(). We actually tokenized our first asset in Brooklyn just a few months ago.

Tranches

There's clearly a strong business case for closely resembling the nuances of security classifications via tranches, but also more complexity on validating transfers and interoperability (e.g. integrating with exchanges). The more I read through this thread (thanks @zingleton), I’m increasingly sold on the benefit of tranches.

While tranches may not be necessary for classes of securities (e.g. common vs preferred equity, which I think would be better served by a separate token issuance), tranches work well for different filings for the same underlying security e.g. Reg D for U.S. investors and Reg S for foreign, when additional securities are offered for the same class, or for allocating pools of tokens within the larger issuance for daily trading limits. The fundamental concept of having a token be “partially fungible” within the same security issuance is important because that’s how they operate in exchanges today.

Given their benefit but also the introduced complexity, I lean towards having one standard that would provide security tokens for individually issued common vs equity securities and one that would include tranches and could be used for Reg D/S securities. Both ERC-20 etc. compatible, of course.

###Additional data field on send()
I’m leaning against the idea of a _data input for an e.g. signed attestation based on off-chain data by the broker-dealer. I fear the coordination effort between exchanges/broker-dealers for reading and validating off-chain data would be too difficult. I’m in favor of keeping transfer validation on-chain whenever possible and limiting the attestor’s potential for error. I would need to see some simple and clever examples in practice of _data

checkSecurityTokenSend()

I’m with the other commenters that this is quite the mouthful, but otherwise, it’s great to see various security token projects (e.g. PolyMath, Harbor, Meridio) starting to converge on modular checks on transfer(). I would second the recommended language change to checkTransfer() or otherwise suggest validateTransfer().

Status Codes

I appreciate the analogy given in ERC-1066 of Ethereum Status Codes resembling HTTP status codes. Our team at Meridio would definitely support more industry convergence on error codes (ERC-1066), application specific codes, and reason coding (defined here).

Token Metadata

Regarding an inheritable metadata interface, I’d support either this (get/setDocument()) or a separate registry contract to get/set metadata for each contract address. In addition, perhaps a separate thread is needed for industry-specific metadata coding. At Meridio, we’re currently using traditional industry code standards such as NAICS and RESO’s data models specifically for real estate assets.

cc @corbinpage, @DavidConroy, @ashadakshi and the rest of the Meridio Team team for contributing.

[jllaw]

@0age

"Why not just split it off into a dedicated EIP for forceableSecurityToken or the like?" That's interesting; I've long been a begrudging fan of forced transfer (not ideal, but necessary for regulated tokens), so it always seemed like it had to be part of ERC1400. I'm trying to think if there's ever a use case where one wouldn't actually want forced transfer in a regulated token; if there aren't many times where it wouldn't be required, I'd assume we'd leave it in as part of 1400; otherwise, separate might make some sense.

"Basically, a slimmed-down proposal containing the key sections of this EIP would be much easier to build widespread consensus around." True. It's a bit difficult to figure out how slimmed down to go versus not so that those dealing with ERC1400 have reassurance that it supports all the expected functionality of regulated security tokens.

[fubuloubu]

It's a bit difficult to figure out how slimmed down to go

I think the partial-fungible token concept is a very clear example of how to reduce complexity. If you separate that, the security aspects of this proposal are easier to evaluate and in fact makes it possible for implementation via a PFT or multiple tokens, or even ERC20, if desired.

I would argue this proposal is really 3 related proposals in one:

1. Variable supply (ERC20 suggests guidelines but doesn't standardize them IMO)
2. Partially Fungible Tokens
3. Custodialship (e.g. forced transfers)

Each has their own use cases outside of securities and could benefit from coordinated conversation instead of pushing the security use case into one EIP, leaving the other use cases to implement their own standards without the extra stuff they don't need.

[pabloruiz55]

First of all, thanks for all the comments. Happy to see all the conversation going on over this proposal.
@fubuloubu after reading all the feedback, we are seriously considering splitting the EIP in a few pieces and have separate discussions given there are some topics that are more controversial than others (Forced Transfers, looking at you 👀 ).

[jllaw]

@pabloruiz55 There's merit in that, but if we split up into something like 3 EIPs that really need to work together, will we come into the scenario where many in the industry start saying something like, you must be ERC20 and ERC777 and ERC1400 and ERC-XXX and ERC-YYY for us to accept you? If that's the case, then wouldn't we essentially be better off just having it all covered in ERC1400? Taking forced transfer as an example, if essentially all security tokens (and I'm not sure that it is 100%) would require forced transfer, then wouldn't we want to include that in ERC1400 instead of breaking it apart into a separate optional EIP?

[0age]

@jllaw - splitting up this EIP wouldn’t fragment the ultimate canonical securities token EIP. Once the constituent EIPs are well-specified, the specification for ERC1400 compatibility becomes really straightforward: it just needs to state which EIPs it requires and how they intersect. From there, industry members can just require ERC1400 as shorthand for requiring all the EIPs it implements.

However, splitting it up would make securities tokens more compatible with a broader ecosystem, particularly with permissioned tokens that don’t have all the requirements of a full-fledged security. There are many interesting applications for utilities tokens that require unique identities, like governance tokens with voting mechanisms that go beyond 1 token : 1 vote. Some, but not all, of the interfaces needed for securities tokens will overlap with those needed by projects like these, and how cool would it be to have one method for checking if a given token transfer will go through?

(Still like canTransfer & canTransferFrom the best - seems the most like the OG, ERC20 😁)

In the case of securities tokens with tranches, I think this should in the default case check that the transfer is ok from some tranche or combination thereof (a default tranche specified by the securities token would be a sane choice) without needing to specify the tranche. To expect every interfacer to know details about all the tranches of all the various securities tokens seems unrealistic. Then, an extension to this method like canTransferFromTranche would provide more granular checks for those interfacers who require them.

[rudolfix]

Good to have this discussion started! Security tokens definitely will extend current token ecosystem and some standardization is very needed.

With this particular RFC I have a problem that it packs every required functionality in the token itself. If we are designing a protocol we should decide first what should go to the app layer and should not be mandatory part of standard. Over-defined protocol will be extremely limiting in the future.

Example: different stock classes are listed separately and have different market value on secondary markets because they give different rights to their holders. They are not fungible and naturally they represent separate tokens. Now I get that there could be a need to define something like token container that groups tokens form the same issuer that are connected via definable set of rules (like how to convert one token into another) but it's not a part of a token. it is rather part of token controller which represents issuer (for example a limited company with typical governance). Every issuer can deal with it as they wish. Some want one stock class and single token. Some will issue many tokens of different classes. Some may use this tranche proposal. Now we can have a standard token container for this things. However if it is implemented inside with separate tokens or with tranches should be irrelevant. By mandating it to be part of the token we are limiting future developers of apps based on security token standard to particular implementation, while I for example do not even see tranches as essential part of security token ecosystem.

Now what I think we should have as security token is something that is building and extending existing token ecosystem: is lean, simple, ERC-20 compatible, leaves as much as possible in the app layer and is useful beyond security token domain. This is my take on what we should do

• Security tokens must be legally binding tokens. Security tokens give holders off-chain rights and possession of a token should be easily enforceable off-chain. This RFC does a first take on that but it's really a separate domain that should be a separate standard. I totally see something like "legally binding smart contract" with standard interface to irrevocably link contracts to legal documents, sign them, retrieve who signed and with which smart contract state.
• Token controller. Please look at MiniMe token to see how powerful concept it is. We should separate token which is about ownership rights from token governance (like token transferability, vesting, lockins, forced transfers etc.). It's better to standardize simple token - controller interface than trying to define app layer stuff in the token! This way you have endless possibilities how this governance is implemented and you keep your token simple.
• Security tokens must enforce several rights that are earned via their possession. For example right to dividend, voting rights, information rights etc. are not transferred when you trade your token. You are still legally entitled to your past dividend. There is already extremely elegant and powerful solution to this in the MiniMe token (balanceOfAt and totalSupplyAt) which also let's you do tons of other things (Aragon is using this for example).

Now the thing I like about current standard is to have canTransfer as part of the token because it's simply practical. In scheme above token controller can answer this questions via standard interface but a little shortcut is not bad.

I summarized all of this with some code samples here, you can read this is you have a few minutes: https://blog.neufund.org/good-protocols-how-to-properly-standardize-security-tokens-95ff83c81c4a

[zingleton]

This discussion has momentum and it is pulling together separate groups to work on a standard. I want to learn more from the people on this thread. Should we schedule some meetups? I have heard that this proposal started with a small meeting that Polymath organized in Barbados. Now we have more participants that are interested in contributing. We can meet up at Ethereum or security token events. Maybe we can start with a meetup in New York around October 5, when some people will go to the "Security Token Academy" event. Maybe we can suggest similar meetups in Europe and Asia.

[seathemc]

Can it be virtual? We are working on mobile security tokens based out of Nairobi with mobile money. Happy to lead a session for the community too. Marvin Coleby Founder Raise m: 514 430 1973 w: raiseimpact.io

…

On Sep 14, 2018, 3:53 PM +0300, zingleton ***@***.***>, wrote: This discussion has momentum and it is pulling together separate groups to work on a standard. I want to learn more from the people on this thread. Should we schedule some meetups? I have heard that this proposal started with a small meeting that Polymath organized in Barbados. Now we have more participants that are interested in contributing. We can meet up at Ethereum or security token events. Maybe we can start with a meetup in New York around October 5, when some people will go to the "Security Token Academy" event. Maybe we can suggest similar meetups in Europe and Asia. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[thegostep]

Thank you all for the great response! It is thrilling to see hear from so many voices in the space and clear that many are thinking about these issues. My job is to involve a diverse set of opinions from across the ecosystem and shepherd the conversation towards some sort of consensus.

We have scheduled a community call for Monday, Sept 17th with @bmann from ETHMagicians and @expede from ERC-1066 to have a public discussion.

To participate in the call, please sign up here.

[adamdossa]

Thanks for all the great conversation and analysis - we are discussing all the points internally and will come back with responses and follow-ups.

Following some discussion here and on the Ethereum Magicians forum we are going to split this into two EIPs initially, and then possibly consider splitting out the force transfer function and other parts at a later date.

Whilst we think the partially fungible token standard can definitely stand alone as a useful standard, with use-cases outside of securities, @thegostep and others raised great points around whether further granularity would help or hinder adoption which is something we want to carefully consider.

EIP 1410: Partially Fungible Token Standard #1410
EIP 1400: Security Token Standard #1411

Comments copied over to the new issue for reference, and we'll close this issue shortly to make sure the conversation remains in a consistent place going forward.

[jllaw]

@zingleton I'm helping to organize that Oct 5 Security Token Academy event. If there's sufficient interest, I could speak with the organizer to have a breakout session to discuss after hours.
@seathemc Not sure we could find a time zone that will work perfectly for you, but will try.

This discussion has momentum and it is pulling together separate groups to work on a standard. I want to learn more from the people on this thread. Should we schedule some meetups? I have heard that this proposal started with a small meeting that Polymath organized in Barbados. Now we have more participants that are interested in contributing. We can meet up at Ethereum or security token events. Maybe we can start with a meetup in New York around October 5, when some people will go to the "Security Token Academy" event. Maybe we can suggest similar meetups in Europe and Asia.

[jllaw]

Let's try to invite as many people as we can to the call. I've sent emails to contacts at Harbor, Securities, SEC, Quoine, and Singapore Stock Exchange already and will be doing more invites as well as posting to social media. Urge you all to do the same.

Thank you all for the great response! It is thrilling to see hear from so many voices in the space and clear that many are thinking about these issues. My job is to involve a diverse set of opinions from across the ecosystem and shepherd the conversation towards some sort of consensus.

We have scheduled a community call for Monday, Sept 17th with @bmann from ETHMagicians and @expede from ERC-1066 to have a public discussion.

To participate in the call, please sign up here.

[zingleton]

@jllaw let's see if we can find a time for a lunch, breakout session, or beer in New York on Oct 4 or 5.

[jllaw]

@thegostep how come this is reopened? Didn't it migrate to #1411 and #1410?

[jllaw]

Ah man, I have to monitor both and make largely the same comments on both now. Hopefully the two standards converge at some point again as they are both community standards after all.

[pakaplace]

@jllaw let's see if we can find a time for a lunch, breakout session, or beer in New York on Oct 4 or 5.

@jllaw Folks at Meridio are in! @corbinpage

[jllaw]

@pakaplace @corbinpage can you comment on #1411? This issue has been closed and continued as #1411 (plus #1410).

[securitytoken]

New York Security Token Exchange is supporting the ERC 1400 and would like to foster the rapid adoption of a unified standard for Security Tokens.

In that regard, the NYSTX can contruibute a working space for the discussions @ www.securitytoken.foundation

To contact NYSTX on Github - just use @securitytoken