polymath-core-deprecated
polymath-core-deprecated copied to clipboard
fix #49 (Multiple KYC Providers) -> TBD in V2
I didn't re-write the test cases yet because of the high chance of modification in the logic. Please review it once with the logic. after approval, I will rewrite the test cases.
Bit confused by the function function addToWhitelist(address _KYC)
- this now adds msg.sender to the whitelist, rather than an address supplied as a parameter. Is this intentional? If so, please could you explain this bit of the logic a bit more.
Yes, I try to change the concept now the customer can whitelist themselves. It will make the process easy and more investor-oriented. if an owner can whitelist, the owner/issuer needs the KYC address of the investor and the investor address to a call the addToWhiteList(address _whitelistedAddress, address _KYC). Provide your suggestion which way we have to go the current one or the owner based.
Yes, I try to change the concept now the customer can whitelist themselves. It will make the process easy and more investor-oriented.
Unfortunately that doesn't make much sense. The only person that should be able to add someone to the whitelist is the Issuer. Even if the KYC provider verified someone, the issuer might have their own set of rules or reasons for not getting someone into the whitelist.
ok fair enough, So we are final that only issuer can call addToWhiteList(address _whiteListAddress, address _kyc)
function.
any more Suggestions for change @pabloruiz55 @adamdossa
Yeah agree with @pabloruiz55 , we need to remove KYC provider from adding to whitelist/blacklist on a security token. They can build their mapping of user verifications all they want, but should be up to the issuer to add them in.
Leaving this PR for V2