---
# System prepended metadata

title: Twitter zkCertificate

---

# Twitter zkCertificate

## Modifications
- A new instance of `KYCCenterRegistry` (if the sets of guardians for zkKYC and Twitter zkCertificate then we can use the current instance)
- Modify and deploy `KYCRecordRegistry`
- Modify circuit `zkKYC.circom` (remove some subcircuit and add one more)
- Add some circuits demonstrating simple proofs
- Generate and deploy verifiers corresponding to the circuits
## Explanation
- When user wants to create a Twitter zkCertificate he will need to determine a secret key `s` and calculate a secret commitment`hash(s, guardian_address)`, then sends it to the guardian.
- He then issues a Twitte OAuth token to share his twitter info with the guardian. In this step the guardian will have access to the following information:
    - Account id
    - Account creation date and it's age
    - Location
    - Is verified or not
    - Followers count
    - Friends count
    - Likes count
    - Posts count
- The guardian then calculates the hash of these information (plus some more infos like in the case of zkKYC) and stores it onchain. Moreover since we don't want to publish the TwitterID but still want to prevent user create multiple zkCertificate through multiple guardians. We will need a mapping where the key is hash of TwitterID and the value is the commitment `hash(s,guardian_address)`.
- If the sets of guardians for Twitter zkCertificate and zkKYC are the same then we can use the current contract `KYCCenterRegistry`, if not we will need to deploy a new instance, but in any case no code change is needed. Should we change the name `KYCCenterRegistry` to `GuardianRegistry`?
- We will need to deploy a new `KYCRecordRegistry` and add to the code a new mapping.
- Regarding the circuits we will need a modification of `zkKYC.circom` keeping the following subcircuit:
    - Ownership: to prove that the zkCertificate belongs to certain main account
    - Authorization: to prove that certain address is authorized by the main account to use the zkCertificate to avoid frontrunning
    - ProviderSignatureCheck: to make sure that the zkCertificate is approved by some guardian
    - MerkleProof: to prove the membership in the merkle tree
- Moreover we also should add some circuits to proving that the follower count is more than certain threshold or the twitter account is verified or not.
