BlockPo / BlockPo-to-Tradelayer

Incubation Repo for the TradeLayer protocol, 0.2.0
http://www.tradelayer.org
Other
8 stars 8 forks source link

KyC not conected to actions #176

Closed Galuf1 closed 4 years ago

Galuf1 commented 4 years ago

The only 2 RPC i found that do something with KyC are tl_new_id_registration and tl_update_id_registration, but i don't see any conections with contracts, dcurrency redemption, or any other RPC that requests the KyC token to trigger any action.

patrickdugan commented 4 years ago

We need the issue KYC attestation tx. This can be done by anyone but only one issued from a KYC registrar will be considered legally legit. The self-certification tx or p2p KYC can be at least viable for allowing this protocol to work in the context of a Sybil prone, pseudonymous protocol like Bitcoin or Litecoin without being unnecessarily compromised, and people take legal liability on their own there.

Then, rules relating to transactions must be added to rules to invalidate tx if the KYC module doesn't check out, and the relevant tx RPCs and parsing logic must be updated for:

Issue Managed Smart Property Update Admin Address for Managed Smart Property Create Oracle Update Admin Address for Oracle cDex Trade mDex Trade UXTO Dex Trade (the original transaction from Mastercoin March 2014)

You just put in this extra parameter as an array of integers or a naked integer (to keep it user friendly-ish, your code should parse either way) and then the tx's are not valid if one:

Sends a token Attempts a trade

Where the recipient/trade counter-party doesn't have an identity token on their address issued by a KYC registrar whose ID number is included in the KYC parameter of the relevant transactions above.

Remember, p2p/self-certification KYC is KYC Registrar ID # 0. You cannot trade any contracts without at least having a KYC chip on your address of ID 0 or, some other more legit ID#. You can trade native tokens without any KYC ship however, but not create or redeem dCurrency (but can receive/hold it and trade it for other things).

So I can create a dollarcoin or a security token and specify that I only want people confirmed to be non-US residents to be able to receive/trade the tokens, according to registrars #23, #27, #34 etc., pass that array of integers into the KYC parameter when I create my token.

I could create an Oracle contract and specify the same, no US persons, etc.

I could post a trade for some ALL for LTC and specify that I only want non-US persons to be able to engage my order. Maybe I feel comfortable with the risk that some US person or other person in a restricted jurisdiction is going to not lie to me, or that if they do then I won't be liable, and I include the parameter 0 in my trade offer. 0 would be the default KYC parameter if I don't input a parameter (e.g. if null then 0). However if I post a token or UXTO trade with a null parameter, then someone without any KYC could trade with me as that is currently legal.

The rules.cpp needs to do a logic check:

Pull up the KYC list for this trade, or for the contract, or for this issued managed token, if contract.type == Oracle, then what is the KYC list, ok, now we have the integers, is there a KYC chip on this address, what KYC Registar ID# does it have? If the ID of the contract or token or trade != ID of the KYC chip on the address, then the trade or send is invalid. If ID of obj == ID of address, then valid.

It's just that simple!

patrickdugan commented 4 years ago

Trade Channel Tx also need rules as well, otherwise it would be a loophole.