Enhancement: Transaction Approval from Coin Issuing Address

[zynis]

Spoke Kevin Day who runs an impact investment fund in Canada with a limited pool of investors.

As we are very far away from building securities trading capabilities, it might be appropriate to put the onus for compliance of regulated securities trading to the coin issuer. And build up the use cases from there.

Thus for small issuance where there is a limited trading pool of investors the coin issuer can approve sends and trades after he has done some KYC on the receiving address for his coin. This potentially would allow stock issuance in some jurisdictions, and for trading by accredited investors in a network.

We can also then use this to map out the regulatory compliance workflows from these coin issuers and embed them into the protocol depending on priorities.

[taariq]

This is very smart. I like it. Well said and lots of potential.

From: Dominik notifications@github.com Reply-To: mastercoin-MSC/Master_Protocol_Product_Requirements <reply+i-34099486-97196601d310eb73e630c55630b181991715515c-701864@reply.gith ub.com> Date: Thursday, May 22, 2014 at 9:36 AM To: mastercoin-MSC/Master_Protocol_Product_Requirements Master_Protocol_Product_Requirements@noreply.github.com Subject: [Master_Protocol_Product_Requirements] Enhancement: Transaction Approval from Coin Issuing Address (#6)

Spoke Kevin Day who runs an impact investment fund in Canada with a limited pool of investors.

As we are very far away from building securities trading capabilities, it might be appropriate to put the onus for compliance of regulated securities trading to the coin issuer. And build up the use cases from there.

Thus for small issuance where there is a limited trading pool of investors the coin issuer can approve sends and trades after he has done some KYC on the receiving address for his coin. This potentially would allow stock issuance in some jurisdictions, and for trading by accredited investors in a network.

We can also then use this to map out the regulatory compliance workflows from these coin issuers and embed them into the protocol depending on priorities.

‹ Reply to this email directly or view it on GitHub https://github.com/mastercoin-MSC/Master_Protocol_Product_Requirements/issu es/6 .

[zynis]

ideally this could be done via m-of-n signature where one of the sig's actually belongs to a service provider, a stock transfer agent for example. and they make some fee for providing this service.

ideally a mastercoin fee :P

Thanks,

Dominik Zynis Skype: dominik.zynis USA: +1-415-800-4155 dominik.zynis@gmail.com

On Thu, May 22, 2014 at 9:03 PM, Taariq Lewis notifications@github.comwrote:

This is very smart. I like it. Well said and lots of potential.

From: Dominik notifications@github.com Reply-To: mastercoin-MSC/Master_Protocol_Product_Requirements

<reply+i-34099486-97196601d310eb73e630c55630b181991715515c-701864@reply.gith ub.com> Date: Thursday, May 22, 2014 at 9:36 AM To: mastercoin-MSC/Master_Protocol_Product_Requirements Master_Protocol_Product_Requirements@noreply.github.com Subject: [Master_Protocol_Product_Requirements] Enhancement: Transaction Approval from Coin Issuing Address (#6)

Spoke Kevin Day who runs an impact investment fund in Canada with a limited pool of investors.

As we are very far away from building securities trading capabilities, it might be appropriate to put the onus for compliance of regulated securities trading to the coin issuer. And build up the use cases from there.

Thus for small issuance where there is a limited trading pool of investors the coin issuer can approve sends and trades after he has done some KYC on the receiving address for his coin. This potentially would allow stock issuance in some jurisdictions, and for trading by accredited investors in a network.

We can also then use this to map out the regulatory compliance workflows from these coin issuers and embed them into the protocol depending on priorities.

‹ Reply to this email directly or view it on GitHub < https://github.com/mastercoin-MSC/Master_Protocol_Product_Requirements/issu es/6> .

— Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/Master_Protocol_Product_Requirements/issues/6#issuecomment-43930589 .

[ABISprotocol]

There are a few items to cover.

1) In the open issue, one is described as: "onus for compliance" 1)a)This might be better said as the "decision whether to comply" with any laws, regulations, guidances, etc., that are generated by a legislative body in traditional frameworks of centralized power (democracies, oligarchies, monarchies, autocracies/dictatorships, and more) that may exist or that may come to exist now or in the future, 1)b) in such circumstances where (reference 1)a) above), with respect to said laws, regulations, guidances, etc.: someone might, now or in the future, assume that said laws, regulations, guidances, etc., have or hold the power of "authority" to the extent that said "laws," or particular "legislative bodies" and / or "governments," as the case may be, are believed in as a source of "authority" by the particular individuals being described in this case, where said "authority" extends over a decentralized sphere of affairs. (It is noted here that such a concept of "authority" as might be extended towards a decentralized sphere of affairs would be illusory, but it is noted in anticipation of various users' perceptions of "authority" that the assumption described here in 1)b) or similar assumptions which could arise in circumstances such as those described above will be useful to reference while characterizing a scope of limited issues relating to identity and authority.) 2) These (1)a) - 1)b)) also assume more traditional notions of identity for the purpose of this comment, and do not (for the moment) take into account distributed or decentralized identity, nor address questions raised by the possibility of swarms of facets where each microfacet may be shared by multiple entities in patterns that do not correspond to identity, or in circumstances where people may freely choose or associate between total anonymity, critical reputation and firm identity, various facets that also are shared with others, or some form of dispersal that involves multiple relationships between all three or more options relating to identity or potentially to transidentical issues and explorations. 3) The circumstances described in 1)a)-1)b) relate to previously valid concepts of "authority" and "identity" and as such, along with the issue as it was originally authored, appear to focus on a microscopically small aspect of a much larger issue. In Iight of this, the issue should indeed be reframed not to merely focus on "onus" or to focus on "regulatory compliance workflows," but indeed, to challenge the very assumptions surrounding what common terms are, what they mean, and whether or not they are valid at all. 4) What is authority? 5) What is identity? 6) If law exists, considering the diminishing relevance of traditional legal structures, what kinds of rule sets, guidances, or new systems of "governance," as it could be, may occur without coercion, use of force, or state sponsorship?

[petertodd]

Note that you don't actually need to change the protocol itself to achieve your goal - just publicly state that tokens traded to entities that are not on the approved list of investors are invalid and will not be honored. This does have implications with things like dividends though in cases where the protocol only allows, say, a dividend to be issued to all tokens rather than just some.