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 Attestation Tx #186

Closed patrickdugan closed 4 years ago

patrickdugan commented 4 years ago

A very elegant tx with a lot of power in its implications.

The tx is empty except for its tx id, the protocol market, and an optional string. People can insert a hash of whatever information they thing is legally relevant into the string parameter.

If the tx is coming from an address that has registered itself as a KYC registar, the attestation is seen by the protocol as having a KYC ID# equal to that of the KYC registrar. If the attestation is from some random address, it is seen by the protocol as having KYC ID# 0. A 0 attestation could be someone self-certifying that they are legit to trade (which may not be good enough for the many regulated counter-parties out there), or it could be someone is doing a peer-to-peer KYC attestation.

patrickdugan commented 4 years ago

The way to implement this:

1) Add the addresses of the KYC registars to the data structure that lists them, for easy look-up. 2) Create the Attestation TX, in the parsing function, parse whether or not the tx came from an address on the list in 1) or not. If not then it's type 0. If yes, then it's id == KYC registrar w/ address. Be sure to look at all the addresses in the tx in case someone used multiple inputs. 3) Add a parameter to the transaction types described in the other ticket Dan opened, either an int or an array of ints, to correspond to what KYC types are acceptable for the tx. 4) Create the rules that look at the address, KYC type, does this correspond to the thing being traded? If yes valid, if not invalid. 5) Exceptions: native tokens don't need any KYC. Native contracts are also good with KYC 0.

patrickdugan commented 4 years ago

If an address have no KYC whatsoever you could assign it a code KYC = -1 for consistency.

santos177 commented 4 years ago

working on attestation branch

patrickdugan commented 4 years ago

Part 2.

Psuedo-code in psuedo-javascript:

If tx type == Attestation

var foo = checkFunction(txid)

checkFunction(txid){ var data = lookUpInputsOutputs(txid) var senderAddress = data.vin[0] if(KYCList.contains(senderAddress){ LevelDB.save(AttestationLists[senderAddres.id]}
}else{ LevelDB.save(AttestationLists[0]} }

patrickdugan commented 4 years ago

Part 3.

Add parameter to the following transaction types:

On-chain mDex trade On-chain cDex trade Instant mDex trade Instant cDex trade Create Managed Smarty Property Update Issuer Address Create Oracle Contract Update Oracle Admin Address

The parameter is either null (if null then 0), a single integer, or an array of integers.

The Contract object for Oracle addresses has a Property, KYCList, which becomes equal to the parameter.

The Smart Property object for Managed Smart Property has a Property, KYCList, which becomes equal to the parameter.

patrickdugan commented 4 years ago

Part 4.

In the rules.cpp or tx.cpp, make transactions valid or invalid:

On-chain mDex trade - if the trade was made with a KYC value, or one of the two propertyIDs has KYC values in the KYCList property of the smart property's objects, then the matching trade in xTrade must come from an address with an attestation from one of the KYC IDs included in both the trade and the smart property. If not, then invalid. If the trade has a null value for KYC, and thus can match with anyone, then the address must merely have a KYC from one of the lists included in the smart property object.

On-chain cDex trade - if the trade was made with a KYC value, the matching trade in xTrade must come from an address with an attestation from one of the KYC IDs. If not, then invalid. Same rules apply as above re: KYC in the trade vs. KYC in the contract.

Instant mDex trade- if the smart property's object's property: KYC Lists has a value, all the Commit tx's funding this trade channel must come from an address with an attestation from one of the KYC IDs. If not, then invalid.

Instant cDex trade - if the contract object's property: KYC Lists has a value, all the Commit tx's funding this trade channel must come from an address with an attestation from one of the KYC IDs. If not, then invalid.

SimpleSend - if the propertyid for the send has in its object any non-0 value in KYCLists, and the reference address doesn't have an attestation from one of the listed KYC IDs, then the send is invalid.

CreateNewRegistrarID - if the sending address is already included on the list, then the tx is invalid. Companies should use multiple addresses if they are running multiple whitelists.