Proof of Humanity Group Token

[jaensen]

Picking up a question from Alex in https://aboutcircles.com/t/proposal-to-update-the-hub-contract-circles-v2/483/14

@alculexum

Ok, I would have to understand more about the Soul-ID thing and Token mapping. So looking up the Hub makes sense, but what to look for exactly and how to make sure that the current user is actually “allowed” to do this, so how to trustlessly assign the Soul-ID to the old and new Token - there are some pieces missing for me.

To quote Andrei:

@andrei

To check whether a wallet address belongs to someone registered on PoH, one can simply call isHuman(address) on the contract. In PoH v2 there will also be a soulbound id for each human (when re/registering the requester always have to point to the soulbound id corresponding to him, otherwise would be challenged). 1 human <-> 1 wallet address <-> 1 soulbound id. This could be used as social recovery

So we’ve got some facts that we can rely on:

• One CRC safe is always mapped to exactly one CRC token (so we can use the terms Token and Safe interchangeably for this purpose)
• Every (PoH) human got a soul-id that never changes and always identifies one individual
• We can lookup if a safe belongs to a PoH human by calling isHuman(safeAddress)

Also I make the assumptions that (@andrei is that right for v2 of PoH?)

• … we can look up a soul-id by a safe address
• … we can look up a safe address by soul-id

So I guess what we want, is a group currency that accepts all tokens of any PoH human as collateral.

I image the process as following:

1. a token is added to the GC
2. we retrieve the soul-id via the path “token → safe → soul-id” and store it together with the collateral token address
3. The token/safe is now a valid collateral/member.

So far so good. The problem appears when a user looses access to the safe or starts acting maliciously by creating multiple UBI safes and then wants to add the associated tokens as collateral.

PoH allows to assign a new wallet address to a soul-id after the user successfully re-validates that he/she is the person that is identified by the soul-id. Since the GC accepts all tokens that lead to a soul-id (using the previously described path) it would also accept all fake/bot tokens as long as the user goes trough the effort of re-validating for each fake safe/token. So there could be 100 parallel CRC tokens (all minting for e.g. 1 y) and the user just has to rotate the safe address by verifying a hundred times and re-registering every token at GC.

The easy way to prevent this would be, to let the user only add one token per soul-id but the person would then be locked out forever if he/she looses access to the safe.

The other way (that requires a change in the CRC contracts - see other thread) is to add a creation timestamp- and predecessor-field to the token. With these changes the process would look like the following:

1. a token is added to the GC
2. we retrieve the soul-id via the path “token → safe → soul-id” and store it together with the collateral token address
3. The token/safe is now a valid collateral/member.
4. User looses access
5. 3 month go by and the original token is automatically stopped
6. User creates a new token and sets the address of the old token as ‘predecessor’
7. User registers again at the GC
8. GC retrieves the soul-id via the path “token → safe → soul-id”
9. GC sees that there is already a registered token for the same soul-id
10. GC checks if the old token is stopped
11. GC checks if the new token is the successor of the old token
12. GC checks if the new token was created after the old was stopped
13. User is member again and can use the new token as collateral in the GC

P.S.: As of writing I see that a user would need to wait three month before a new token can be safely created which is not ideal