# MEMBER TO MEMBER AND KYC USE CASE

## USER STORIES

### GROUP FOUNDERS (GROUPS USE CASE)

- `Founders` decide to constitute a new group with a specific purpose or mission
- They establish some governance rules and they consider each other as roots of trust
- `Founders` are entitled to provide a limited number of trust endorsements which includes `identity validation`to future members of the group as they ask for it but it can be only provided in person
- Once the requirements in number of member to member endorsements are achieved, the process will follow in the defined specific steps.
- An end `User` might be considered KYC'd from the group perspective and he can receive a specific reusable `credential`

### USER (MEMBERSHIP OR KYC)

- `User`wants to become member of the group or become KYC'd and they approach it to know the rules of acceptance
- Once understood that he needs a number of personal endorsements or validations, he discovers and contacts (it might be off-chain) one or more of the providers (listed `validators`) of trust in form of direct endorsement
- `User`endorsements might come directly from `Founders` or from other trusted members of the group acting as `validators` in the group use case. He can get KYC validations from listed `validators`
- Once the `user` achieves the required endorsements (KYC validations), it can apply for membership and he will receive the membership credential, which might be reusable as a KYC proof
- The credential will be renewed periodically / randomly by one or more `validators`, depending on the governance process
- `Users` will have some cost for the validation, in form of tokens. This cost might be covered by the group in this use case or a model to cover the cost from the KYC requestor can be put in place

### DECENTRALIZED VALIDATOR (MEMBERSHIP AND KYC USE CASE)

- The role of `validator` is the member or person which is enabling trust over other member by formally registering its trust on this person
- In case of KYC, `validator` is confirming that the `User` is a real person and accomplish KYC requirements
- Validation has to be performed in person via QR code scanning
- `Validators` have to be publicly listed in geo reference and time availability so `Users` can find them both at the onboarding process and on the credential renew process
- `Validators` will put some tokens at a stake so he has the incentives to do a correct validation, since he will lose them if it is not right

### CHECHER (KYC USE CASE)
- `Checker` is the role which has the objective to verify that validations are performed correctly
- This role may also challenge any existing validation from a `User` to by requiring him to be validated again
- It can be accepted that `User` act as checkers by trying to trick or bribe the `Validator`and after proving that, get the token stake. If not, a specific role has to be created to challenge validations

### DISPUTE RESOLUTOR (MEMBERSHIP AND KYC USE CASE)

- In case that some validations have been challenged, a dispute resolutor has to be addressed
- This might be a centralized role in the organization use case and even in the KYC scenario (maybe to start)

### FINANTIAL INSTITUTION
- At the beginning it might be a Decentralized Exchange as Ethfinex onboarding a `User`
- Reuse of credentials is key for these organizations in case it might be complemented with other type of claims (credentials) from other entities, not only to make sure their customer is a real person but also he is trustworthy
- A model of incentives to complement KYC credential with endorsements from other organizations is key
- The cost for KYC might be charged to the KYC requesting institution but we can define a model of income generation for `Users` and `Validators` if the credential is reused to other finantial institutions
- A different model to cover risk might be defined so decentralized validations can be backed with an insurance from insurace companies. It can be considered that insurance apply only to Trusted Verifiers (centralized `Validators`)

### LAW ENFORCEMENT
- Should be able to access original user information when required
- Storage of this private key is critical and can be shared with another actor as tthe DEX

### TAX COLLECTOR
- Maybe access to operations is required but not to full disclosure (to be discussed)

### REGULATOR
- A solution d be presented approved but a lawyer involved in the project
- Afterwards regulator should approve the full process

### CENTRAL BANK
- Not creating a new money supply
- Offering a KYC solution. As CB have different task force exploring the KYC solution further asteps can be explored
-