TBD: Add the possibility of having multiple KYC providers for an STO instead of just one
Yes, It should be
Yes will add this in. Closing as it is mentioned elsewhere
I believe you mean #47, but that refers to something else. Bypassing KYC provider vs having multiple KYC providers. Reopening but moving it to V2 milestone
This was mentioned as being an item which was needed for v1 (i.e. the 31st Jan mainnet deployment).
I think the most straightforward approach is to change KYC in Template.sol to be a fixed length array (say of size 10), and have the constructor take an array of valid KYC addresses.
SecurityToken can then receive this array from the chosen template and loop over these and turn them into a mapping for subsequent O(1) access.
@pabloruiz55 @Everhusk WDYT? This would be a minimal change that allows multiple (e.g. up to 10) KYC providers to be used for a single ST.
@Everhusk it is different from the issue #79. It is about to add multiple KYC providers for the security token and @adamdossa proposed the solution is the minimal changed solution in current code as per the time crunch. @Everhusk should I change as per the suggestion?
Two ways to achieve this task.
1. Adding an array of whitelisted KYC providers(i.e whiteListedKYC[]) in the constructor of the Template having length >1 always and KYC[0] is always the address of the delegate provider.
If we are adding both parameters KYC[] and current KYC provider of the delegate then I am facing the stack too deep error because of this error I suggest doing as above. In that way, anyone who is verified by the whitelisted KYC providers can propose STO and Template and Investors can whitelist themselves by selecting their KYC providers from the whitelist mapping of KYC providers. (way of doing same as 2.a or 2.b)
2. Using current pattern of template constructor, Issuer add the list of whitelistedKYC providers as an argument at the time selectTemplate() and we will convert that array as mapping in mapping(address => bool) public allowedKYC then
a. Investors can call the addToWhiteList(_KYCProvider) with parameter KYCProvider of their choice and if that KYC provider exists in the allowedKYC mapping then only investors get whitelisted in the STO.
OR
b. Owner or KYC provider will call addToWhiteList( _whitelistCandidateAddress, _KYCProvider).
In both a and b, we are giving the leverage to investors. So they can whitelist themselves with their KYC providers but for proposing offering contract we are restricted to one KYC providers i.e delegate KYC provider.
@Everhusk @pabloruiz55 which way do you suggest the final way.
The way I was thinking about this to keep it simple and not have to redo a lot of code was to modify Template.sol and Compliance.sol so instead of passing a KYC address, an array could be passed.
Then, in addToWhitelist, instead of having it called by KYC, it should be called by the Issuer/Owner. Instead of doing
var (jurisdiction, accredited, role, verified, expires) = PolyCustomers.getCustomer(KYC, _whitelistAddress);
We would loop through the KYC array executing the function above for each element, until a customer is found. The problem with the above is what happens if the investor is in more than one KYC provider, they could have different data in each one.
Another possibility is doing what I described above, holding an array of KYC providers for each template, but have only 1 active at any given time, and that's the one used to check when adding to the whitelist.
As an issuer I can have many KYC providers, but only choose one to be used. If I want to switch, I can do so. Though, I'm not sure what to do with whitelisted addresses held by one KYC provider if it is switched out.
@Everhusk your views?
@pabloruiz55 Yes, We will be going to add an array of whitelisted KYC provider addresses. but for the function addToWhiteList() it should be like
function addToWhitelist(address _whitelistAddress, address _KYC) public returns (bool success) {
require( owner == msg.sender && Template.KYC(_KYC));
var (jurisdiction, accredited, role, verified, expires) = PolyCustomers.getCustomer(_KYC, _whitelistAddress);
KYC is mapping mapping(address => bool) public KYC; which is a one time process for a template
and if we provide investors have the capability to add themselves to the whitelist then we can change the function as
function addToWhitelist(address _KYC) public returns (bool success) {
require(Template.KYC(_KYC));
In my opinion, the last one is the best approach to handle the situation.
This way we don't need to loop every time because it will increase the gas cost and we also get rid of the problem
The problem with the above is what happens if the investor is in more than one KYC provider, they could have different data in each one.
This sounds sensible to me - do you want to do this in a standalone PR and we can then all review?
I did it, please review the PR @adamdossa
Still on the fence with this, let's move to V2 after getting more feedback.