OmniLayer / spec

Omni Protocol Specification (formerly Mastercoin)
The Unlicense
341 stars 116 forks source link

Transaction Approval from Coin Issuing Address #171

Open zynis opened 10 years ago

zynis commented 10 years ago

https://github.com/mastercoin-MSC/Master_Protocol_Product_Requirements/issues/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.

kevingkday commented 10 years ago

For a private equity fund where investors would not likely have any interest in sends and trades (as their return is when the fund exits) this approval process would be perfect.

ABISprotocol commented 10 years ago

See also comment here relating to identities, unresolved terms and methods of implementations (identity, trans-identical communication, dispersal, etc.) The assertion is made that rather than "regulatory compliance," "onus," or "compliance" that the issues to be addressed are deeper and involve terms which include, but are not limited to, "authority," "identity," and other terms unresolved which have bearing on functions either not implemented or only partially implemented.

dacoinminster commented 10 years ago

Is the idea here to allow asset creation where a central authority has to approve every trade and transfer?

On Thu, May 22, 2014 at 9:17 PM, ABIS notifications@github.com wrote:

See also comment herehttps://github.com/mastercoin-MSC/Master_Protocol_Product_Requirements/issues/6#issuecomment-43948329relating to identities, unresolved terms and methods of implementations (identity, trans-identical communication, dispersal, etc.) The assertion is made that rather than "regulatory compliance," "onus," or "compliance" that the issues to be addressed are deeper and involve terms which include, but are not limited to, "authority," "identity," and other terms unresolved which have bearing on functions either not implemented or only partially implemented.

— Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/spec/issues/171#issuecomment-43969845 .

kevingkday commented 10 years ago

The issuer would have to approve every trade and transfer, because the issuer is the one who is ultimately responsible for ensuring regulatory compliance.

ABISprotocol commented 10 years ago

I should hope that there would not be a central authority involved at least with respect to the ideas raised in my comments, but I should also add I think that I may need to open up my ideas raised as a seperate issue, although they are relevant to both this issue #171 and also to the enhancement 6 as shown here. Thank you.

zynis commented 10 years ago

in some jurisdictions the issuer needs to maintain a list of shareholders, since we do not have the capability to attach identity to BTC addresses at this time, the simplest way to allow an issuer who needs to do this is to all them to only approve trades and transfers to BTC addresses where they have done some KYC.

also, in some jurisdictions, like with SEC Schedule D, there is a limit of 500 shareholders mainly of accredited investors, thus an issuer who wishes to remain a public company and not be forced to go public on a stock exchange would use this feature to limit the number of shareholders so that their company is not forced to go public prematurely.

Thanks,

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

On Sat, May 24, 2014 at 4:44 AM, ABIS notifications@github.com wrote:

I should hope that there would not be a central authority involved at least with respect to the ideas raised in my comments, but I should also add I think that I may need to open up my ideas raised as a seperate issue, although they are relevant to both this issue #171https://github.com/mastercoin-MSC/spec/issues/171and also to the enhancement

6 https://github.com/mastercoin-MSC/spec/pull/6 as shown herehttps://github.com/mastercoin-MSC/Master_Protocol_Product_Requirements/issues/6.

Thank you.

— Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/spec/issues/171#issuecomment-44075716 .

zynis commented 10 years ago

remain a private company

Thanks,

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

On Sat, May 24, 2014 at 1:08 PM, Dominik Zynis dominik.zynis@gmail.comwrote:

in some jurisdictions the issuer needs to maintain a list of shareholders, since we do not have the capability to attach identity to BTC addresses at this time, the simplest way to allow an issuer who needs to do this is to all them to only approve trades and transfers to BTC addresses where they have done some KYC.

also, in some jurisdictions, like with SEC Schedule D, there is a limit of 500 shareholders mainly of accredited investors, thus an issuer who wishes to remain a public company and not be forced to go public on a stock exchange would use this feature to limit the number of shareholders so that their company is not forced to go public prematurely.

Thanks,

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

On Sat, May 24, 2014 at 4:44 AM, ABIS notifications@github.com wrote:

I should hope that there would not be a central authority involved at least with respect to the ideas raised in my comments, but I should also add I think that I may need to open up my ideas raised as a seperate issue, although they are relevant to both this issue #171https://github.com/mastercoin-MSC/spec/issues/171and also to the enhancement

6 https://github.com/mastercoin-MSC/spec/pull/6 as shown herehttps://github.com/mastercoin-MSC/Master_Protocol_Product_Requirements/issues/6.

Thank you.

— Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/spec/issues/171#issuecomment-44075716 .

dacoinminster commented 10 years ago

I can see why regulations would require this. What I don't see is how a token like this could benefit from being on Master Protocol. If it is centrally controlled, why not just keep track of it using conventional means? Why use a decentralized system?

ABISprotocol commented 10 years ago

@dacoinminster Exactly.