UserRegistry Extended Keys -> new data

[quinoah]

Hello!

Extended keys (array of uint256) are presently used in the following way:

extendedKeys_[0] is the validated Tier
extendedKeys_[1] is the maximum accepted purchase amount in CHF
extendedKeys_[2] has reserved use for AML recovery

Could it be relevant to add two keys (non-personal data):

extendedKeys_[4] as a uint256 encoding the user's country of residence
extendedKeys_[5] as a uint256 encoding the user's nationality

Regarding encoding, first intuition was to use international phone country code (e.g. 41 for Switzerland) unfortunately some countries have the good idea to share codes (e.g. 1 for both Canada and the US). It looks more convenient to use UN codes or encoded ISO 3166-1.

I'm also thinking of other parameters which are useful in a user context:

• seeded hash of ID picture
• seeded hash of signed TPA (or digital signature)
• internal mongoDB identifier

[sirhill]

Thanks @quinoah. This is a very interesting request.

As you mentionned correctly, the user attributes are identified by an Id and the corresponding values is stored in a map.
The values are defined by convention. Both the UserRegistry.sol and OracleEnrichedTokenDelegate.sol support a remapping of attributes if needed. UserTokensale.sol does not as the contract is much shorted lived.

1- Used attributes

• Extended Key 0 refers to the validated Tier. This value is only used at the moment to allow generic contribution limits based solely on the validated tier.
• Extended Key 1 refers to the all time reception AML limit. This limit correspond to the maximum of token that a user may receive in the core. This limit is defined in the base currency of the UserRegistry. For compatibility and historical reason, this limit is also used in UserTokensale. Whenever the limit is reached, the user must request an increase of his limit.

2- More AML attributes

It was envisioned to support more advanced control AML attributes for both reception and emission.
In a simplified approach, it is proposed to used a reception recovery rate which would represent the proven recurrent incomes of the user. It was also considered to provide a max recovery that the recovery rate will never be allowed to exceed.
The reception would then be used in the following formula:: receptionAllowance = allTimeReceptionLimit - totalReceived + Min((now - lastAllTimeReceptionLimitUpdate) * receptionLimitRecoveryRate, maxReceptionRecoveryLimit)

This AML setup will requires these three new following attributes:

• lastReceptionLimitUpdate
• receptionLimitRecoveryRate
• maxReceptionRecoveryLimit

3- More KYC attributes

Now you are suggesting, two very interesting attributes

• Country of Residence
• Nationality
  It is worth noting that countries do change overtime: they may be renamed, divided, merged, ...

4- Documents hashes

It seems very relevant to also to be able to link users with their document hashes.
It should be seen how the hash would be used onchain.
One use case is to only allow some services if a document is signed. The user can enable the service at any time onchain by submitting the signed hash of the document.

Note for implementation: the current structure of the UserRegistry does not seems ideal to store document hashes. We could either add a new structure in existing contract mapping(uint256 => bytes32) documentsHash or add a new contract UserDocuments to handle this specific concerns.
It shall also be seen if the hashes need to be stored in the state or only in transaction logs.

Important notes

Storing data onchain and keeping them accurate is costly.
Therefore, the focus should be on what features can be enabled by having the data onchain and how the benefits of the feature compare to the cost of maintaining this data.