Closed patrickdugan closed 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.
If an address have no KYC whatsoever you could assign it a code KYC = -1 for consistency.
working on attestation branch
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]}
}
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.
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.
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.