Standards for token and KYC


#1

Several interfaces have been developed to create new tokens. Interfaces aim at having a standard that is understandable by anyone.

In Ethereum based tokens, a major interface is the ERC 20. But ERC 20 suffers from not identifying the owners of tokens.

Actually, investors need to be identified for legal reasons. It is the KYC norm (know your customer). Basically, KYC mandate to prove the veracity of the customer’s existence by submitting the Proof of Identity and Proof of Address.

This one of the reasons that push the development of new standards:

On the top of that, several projects (Sovrin, Taqanu, uPort, Civic, KYC Legal, …) offer new way to identify a user.

A good introduction to uPort is this Medium post. Though it is considered in their roadmap, uPort is still not available on mainnet and the application is still in beta mode.


Image taken from the documentation.

It works generally with these simple steps: 1) the application requiring data about a user makes a query to a service. 2) A QR-code is presented to the user. 3) If the user scans the code from his/her smartphone, the service delivers the information to the application.

My first guess would be to build an ERC20 token, but accepting only recognized and validated users with a validation step done with uPort for example.


#2

Good analysis. I just browsed through the Polymath whitepaper and it seems at 1st sight that their standard proposal for Security Tokens (ST-20) is pretty lightweight and flexible.

Even though CO issue fully digital securities that are not tied to any physical asset and does not belong to any jurisdiction [ndlr:to be confronted with legal advisors], it might make sense to use their standard for CO tokens. What I like is that they did not tie their POLY token to their ST-20 standard (obviously because it would have killed the standard aspect of it) so the standard seems pretty open. What do you think?

Regarding identity, as a 1st step, I think we should use a whitelist in the smartcontract as you suggested and as they are doing in the ST-20 standard. The problem with this approach is that investors will have to re-KYC for every CO they want to invest in as, as far as I understood, the whitelist is specific to each contract.

In a 2nd step, we could indeed include something like uPort by allowing the investor to save its KYC certification for CO in uPort app (it will also be interesting to see the plans of coinbase in that matter). I feel it is a bit early now to think about this 2nd step as the ecosystem is moving quickly and it seems pretty sure that identity will be soon tied to wallets themselves… so I’d say it’s urgent to wait on that particular aspect :slight_smile:


#3

A good point for Polymath is their KYC provider marketplace: when an issuer initializes an STO, the issuer can the choose between several KYC providers. Offering a choice in the provider is necessary for Polymath as the STO has to follow local juridictions, but a choice remains relevant for COs, as it avoids a centralized bottleneck.

Actually, POLY could not use the ST-20 standard, because POLY is a utility token for creating STOs, and is not a security token. The ST-20 standard is like an over-layer of ERC-20 with securities to restrict who owns the tokens (the function verifyTransfer), in order to follow juridictions.

Another point to discuss is whether or not we need to restrict the number of investors, as explained here.
The point is to follow the rule “number of investors < 2000” in the USA (you can have more than 2000 but with a more complex structure). This also impacts the limit on the minimum number of tokens (if you can have only 2000 investors, you don’t want to have investors with 0.0001 tokens).
What do you think about it?


#4

I think we should think at belonging to the Internet jurisdiction. By default, CO have no legal entity attached, they can have as many investors as they want investing as much or as little as they want. It does not mean that it is the optimal choice but we should not impose constraints on that aspect. It will be up to the CO founder to decide if/what boundaries he wants to implement.

Regarding POLY, I know it’s an ERC20 token but I was afraid at first that they had required POLY-only interaction with their ST-20 contracts in the hope to find a utility for their token. It would have been stupid but in the ICO world, there’s a lot of stupidity :slight_smile: Good point is they did not do it.


#5

Alright! To sum up, we want to following properties:

  1. Getting the balance of a token owner.
  2. Getting the total supply.
  3. Approving a new token owner based on a whitelist/blacklist.
  4. Transfer from a token owner to another one.
  5. Buying/selling tokens.
  6. Setting initial tokens and distributing them at the construction.
  7. Setting the parameters of the slope, fraction of revenue and investors.
  8. Upgradability of the smart contract.
  9. Setting the min/max limit for a number of tokens.