# Jomo Overview ## What Does Jomo Do By leveraging cryptographic technologies, Jomo provides developers with the tools to easily access verified self-sovereign user data from various sources, empowering them to create personalized experiences that cater to the user. ## Learn More #### [Why Use Jomo](/welcome-to-jomo/why-use-jomo) #### [Who Should Use Jomo](/welcome-to-jomo/who-should-use-jomo) #### [How It Works](/welcome-to-jomo/how-it-works) ## Contact Us # Why Use Jomo Traditionally user data is siloed across different applications. Only the user and the specific application that they use have access to those data (for good reasons). When an application needs to understand a user's outside activites however, they have very limited and imperfect options: * Ask the user for their credentials (login credentials, ownership proof over all their crypto wallets, etc) - requires a lot of trust from the user due to privacy concerns * Request the users to self report (download a bank statement, fill a form, etc) - which is tedious and prone to fraud * Direct integrations with data source applications - heavy overhead to negotiate the integration Now with Jomo, users can own and manage their own data across the different applications. Their trading activities on an exchange, which wallets did they use, where have they travelled to, what tv series are their favorite, which university did they graduate from, the list goes on and on. In additional to helping them manage their data, Jomo also utilizes cryptography such as Multi Party Computation and Zero Knowledge Proofs to help users prove the validity and authenticity of their data, without needing to reveal credentials or any raw details. This makes whatever information later shared with the applications verifiable and trustworthy. Finally Jomo provides easy integrations for developers so they only need to handle the verification results and not worry about the process. #### Below are some of the benefits of integrating with Jomo: * **Easy and verifiable data access.** No more need to negotiate complex direct integrations, nor hiring 100 agents to review bank statements. * **Comprehensive data types.** From off-chain data such as financial activities, account ownership and access, bank statements, activities on any websites, to on-chain data such as aggregated wallet ownership and interactions history. * **Complete privacy.** Jomo's privacy first solution means that your users will be more willing to verify to your product. By not accessing what we don't need, we can in turn learn more about our users from what they are willing to share. * **More cost effective.** Cut the middlemen and data brokers and get connected to the users themselves. With more granular data types and shorter distribution chains, money will be spent more efficiently whatever your objective is. # Who Should Use Jomo A wide range of businesses could benefit from Jomo's solution and get access to user data that are traditionally siloed on different platforms, and do so without worrying about harming user privacy and strict data regulations. Below are a list of example areas that Jomo could help with via bringing in user data that weren't easily and verifiably available before: * Targetted Growth and Marketing * Fraud Prevention Using Richer and Cross-Platform Data * More Granular and Accurate Ads Distribution * Verifiable Reputation on Social/Recruiting Platforms * Feature/Product Gating and Personalization * Customized AI Agents with Verifiable User Data If you are interested in any of the use cases above, or have new ideas on how we can collaborate, contact us via: ## Example Usecases ### Growth #### Targetted Promotion to Users with Certain Trading Activities Promotions or Incentives are great levers to encourage potential users to try out a fintech product and provides you a chance to earn the users using great product experiences. Historically these promotions are issued to the general public, or based on some rough user segmentations. What really should happen is to only issue the promotion to your potential users, or at least give them a higher reward so a better incentive to switch over from their existing solutions. However this requires you to understand user activities on other platforms, sometimes competitors. And there were no easy ways to do that. Now with Jomo, you can issue a promotion, which would only be available if the user can prove that they have a certain level of trading activities (amounts, frequencies, equity types, etc). Jomo's flow helps users generate a proof that they satisfy the requirements, without leaking or sharing any more than that. ### Financial #### Income and Asset Verification This happens whereever we go. Leasing offices, loan officers, accredited investor checks, etc. Today when proving that I have a certain amount of asset or income, you hire a team to review the bank statements users uploaded. The process is slow and users can easily fake the uploaded documents. Not to mention that during the process a lot of credentials and information are shared, and users drop off when they don't want to leak so much information. With Jomo, these verifications can be done without the need of a manual review team, as Jomo has proved it using cryptography. Besides, users would feel more comfortable because nothing else was leaked other than the user has a bank account with balance > $20k, or a W2 with more than $100k yearly income. ### Web3 #### EVM Bluechip NFT Holder/Whale Web3 social platforms can integrate with Jomo today and give their users a special UI, level, achievement badges etc, if the user verifies via Jomo that they hold certain amount of Bluechip NFTs aggregated across any of their wallets. NFT whales typically have multiple asset wallets, and likely wouldn't sign in to a social platform with any of them. In addition, they may not even want anyone to know that their social account is associated with those asset wallets to prevent social engineering attacks. Jomo allows users to connect and verify their wallet ownership, prove legitmacy of the results aggregated across wallets that they own, all while having nobody, including Jomo, know which wallets are owned by them. The integration is simple for dApp developers as well. Jomo handles all the heavylifting over Zero Knowledge Proofs and user experiences, and dApp only need to hand the user off to Jomo, and wait for the verification results. #### Gitcoin Donators, DAO Voters, etc Similar to the use case above, a wide range of onchain activites can be aggregated in a way that does not expose user's wallet associations or holding details. This could empower application builders to build on top of a user profile, customize experiences focusing on what the user has done in the past, regardless of what all wallets has the user used before and which wallet did they use to perform an action. ### AI #### Secure and Verifiable Data Connector With the boom of AI agents, a lot of efforts have been made to make them more personal and helpful to each individuals. This requires data to be connected to each user's personal spaces. What happens today is that the agent developers ask users to get various API keys from different data sources, and give the API keys to the agent. The process is both complex and not secure. Using Jomo, the AI agents can now ask the users to connect to a site of theirs, and grab data inside it via Jomo. The users don't have to deal with developer portals and complex flows. Further more, in some cases when the AI agents need verified data from the users, Jomo can help make sure of authenticity as well. # How It Works Jomo uses latest cryptographic technologies such as Multi Party Computation (MPC), Zero Knowledge Proofs (ZKP) and 3 Party Transport Layer Security (3p-TLS) to ensure that the generated proofs represent authentic data, while at the same time fully respects the user's privacy. To dive into more details, we will divide into 2 sections to introduce * [How Does Jomo Privately Prove My Data on Another Website](/welcome-to-jomo/how-it-works/how-does-jomo-privately-prove-my-data-on-another-website) * [How Does Jomo Privately Prove My Aggregated Onchain Activities](/welcome-to-jomo/how-it-works/how-does-jomo-privately-prove-my-aggregated-onchain-activities) # How Does Jomo Privately Prove My Data on Another Website First we will need to clarify a few terms and the different parties getting involved in the Proof. #### User/Frontend/Jomo Webpage/Browser They all mean the same thing, which is the device the user is holding and using to complete the flow. It has the highest data priviledges and only the user themselves get access to it. #### Application Server This is the backend server of the website you are connecting to. Think of Coinbase if you are proving your crypto trading activities, or Tesla if you are proving your ownership over a car. #### Jomo Notary Server This is a server that Jomo hosts, which plays a crucial part in the proof. It sits on the side when the frontend talks with the application server and notarizes that the communication did happen. However it does not see the unencrypted raw transcripts but instead only receives encrypted data blobs. Thus it knows nothing about what's being transmitted. #### Jomo Verify Server This is another server that Jomo hosts, which receives the substring proofs generated by the frontend and checks its validity, upon success, it generates an attestation about whatever data that was disclosed to it. #### Requester Some of the Jomo flows are initiated by an application or website which is requesting user's data from the application server, and the end of these Jomo flows would be users sharing selectively disclosed information and a proof of validity to the requester, who can then validate the proof with Jomo. ## Overview

How Jomo Works

## Key Flows Below is an abstracted description on what happens between the different parties when a proof is made. 1. In contrast to the normal TLS session that gets established whenever the browser talks with a server. Jomo's Notary Frontend sets up a 3 party TLS connection, among the browser, application server, and the Jomo Notary Server. 2. In this setting, Jomo Notary Server participated in the key exchange flows of the TLS session and thus is able to validate data that's being transferred, however it doesn't get the entire key, and thus is unable to read any unencrypted transcript. 3. After the TLS session is completed, Jomo frontend generates a zk proof to the Notary server about the TLS session. The notary validates the proof and issues a Notarization with signature over the merkle commitment of the transmitted bytes. 4. With the merkle commitments, the Frontend can selectively present certain sections of the bytes transferred, and prove to the Verifier that those bytes were actually transmitted. 5. After validating the proof, the Verifier then writes the data into a private EAS attestation. 6. On top of it the frontend prover can then choose to make a proof against the data in the attestation, to further hide or limit the information being shared to the Requester. Jomo uses [PSE](https://pse.dev/)'s [TLSNotary](https://pse.dev/) as the backbones of our proofs. You can read more on TLSNotary at [here](https://docs.tlsnotary.org/). # How Does Jomo Privately Prove My Aggregated Onchain Activities This section describes in detail how we are able to use Zero Knowledge Proofs to privately aggregate the same type of data across multiple wallets a user owns, and prove the aggregated values, all without knowing which wallets the user owns. ## User Model and ZK Accounts Management Every user gets a Jomo profile automatically when they land on Jomo's webpage. This user profile will be stored locally, and include all their accounts, crypto wallets etc. The detailed accounts information will not get exposed to anyone else, including Jomo. ### Account Ownership In order for us (Jomo) to attest and help the users prove that they own those accounts, Jomo frontend helps the users to generate a ZK proof, that all their accounts hash into a merkle root, and we only store the merkle root on the backend, associated with the user.
Now when a user wants to prove that they own one of the accounts, they can just prove that they know the user secret, the account hash, and a list of merkle paths, that will eventually compute to the account merkle root stored for their profile. ### Adding New Accounts When the user connects a new wallet and verifies a sign-in signature, or connects a social account via oAuth, Jomo does NOT associate this information with a user. Instead, we allow the user to attach a secret hash with the request, and essentially register that whoever knows the secret owns the account. All the registrations are then commited to a public merkle tree. Later the user only has to prove to us that they know a secret and an account, and that there is a registration about them in the merkle tree.
Together with this proof, they will also generate a proof to the backend that the merkle root should be updated to a new value, which includes all previous accounts, and adds this new account. ## Attestation Ownership Based on publicly available onchain data, we have made attestations to accounts connected on Jomo. This include things like bluechip nft ownership, for all the holder wallets. For each account that we attested, the detailed data is commited to a Pedersen hash, and together with the account hash, stored in a merkle forest.
When a user wants to prove that one of the attestations is about an account that they own, they would prove that * They know one account hash + pedersen hash that exists in the merkle tree * Their user profile owns the account hash (as described before) ## Aggregation Computation Next we allow the users to prove to us that they own multiple accounts, each has attested data, and these data aggregate to a certain value, all while not letting us know anything about which accounts, what data, and even the aggregated result.
With the proof, Jomo could verify that the user is speaking truth without knowing the underlying details. Thus we could issue the user a private verifiable credential (private VC), which basically says that the user owns multiple accounts that aggregate data to a sum value, and the sum value hashes into a meaningless public string. ## ZK Proofs over Private VCs Finally based on the application's requirements, the user is going to present their private VC, which is basically the meaningless public string, and generate a proof saying that the underlying data within the meaningless string meets the application's criteria. This is a relatively simple ZK proof where the user supplies the underlying data to the ZK circuits and run the range proofs against the criteria. # FAQs ## - Proving Data from Websites and Accounts ### Does Jomo or anyone get to know my username/password if I entered it during the Jomo flows? No. Your username/passwords are only used by the local webpage and are directly sent to the target application's backend servers. They are never sent to Jomo's backend services, so cannot be known to Jomo or anyone else. ### Why does Jomo ask me to enter my username/password if you don't need to access it on the back? Unlike other traditional services (such as Plaid), the data fetching and validation from Jomo happens on user's local device, not our backend. Jomo's webpage needs to use the credentials to establish connection with the target application's server so it can fetch the data that needs to be notarized. ### Does Jomo access all the request/response sent to/from my application during this process? No. Although the webpage processes the request/response stream, Jomo's backend doesn't see the transmitted data except for the desensitized parts the user decides to share and publish. ### How exactly is Jomo proving that the data is legit if you never saw the whole of it? This is where cryptography kicks in. Although Jomo's notary server only ever sees the encrypted streams, it's able to validate whether the selectively disclosed substrings of the stream presented by the user is legit. For more details, see link below. [How Does Jomo Privately Prove My Data on Another Website](/welcome-to-jomo/how-it-works/how-does-jomo-privately-prove-my-data-on-another-website) ## - Proving Onchain Activities Aggregated Across Multiple Crypto Wallets ### Does Jomo know and store that I own all the wallets I connected on Jomo? No. Jomo does not know which wallets a user owns nor which wallets are associated together under the same user. Jomo does know which all wallets came to the Jomo platform, this happens when you sign the message and prove your ownership. But then Jomo does not get any knowledge about which user is associated to the wallet. This can be proved by inspecting network requests coming out of Jomo Frontend, there is never any request that would expose user-wallet or wallet-wallet relations. Everything stays on user's device. ### Why does Jomo ask me to sign a message if you don't intend to know I own the wallet? The ownership signature serves as the basis of following Zero Knowledge Proofs over wallet related attestations. Jomo does not know, and is not interested in knowing which wallets are associated with a user id, but setting user id aside, Jomo needs to verify someone owns a wallet to issue them attestations related to a wallet. In short, signing the message proves to Jomo that `Someone` that is sending the request now owns the wallet address, but Jomo won't know which exact user is that `Someone`. ### How does Jomo prove aggregated activities (such as how many Azukis do I hold across all my connected wallets) if Jomo doesn't know which wallets do I have? This might sound confusing, but Jomo uses ZKP in many steps so that we can `Attest` for your ownership over all your connected wallets without knowing which exact wallets we are attesting for. To understand better we have to dive deeper into Jomo's account model. Jomo's backend does not store what wallets a user owns (because we don't know that). Instead, we store a `merkle root`, which corresponds to a merkle tree that contains all user's connected wallets. This allows Jomo to verify if an ownership claim is true, without knowing all the details. For more details on how ZKPs are linked together to prove aggregated activity information, check out this page: [How Does Jomo Privately Prove My Aggregated Onchain Activities](/welcome-to-jomo/how-it-works/how-does-jomo-privately-prove-my-aggregated-onchain-activities) ### How do I know signing in with Jomo is safe? The message that we requested you to sign when verifying wallet ownership is purely a signature over a message with a nonce generated with `persona_sign` method. It does NOT authorize any transactions nor approve any permissions. The only usage of the signature is to verify that the person making the request is indeed the owner of the wallet. ### Will Jomo store my wallet associations? No. Jomo doesn NOT know your wallet associations and thus cannot store it. This can easily be verified by inspecting network traffic coming out of Jomo frontend. Never will two or more wallets be sent in the same request. Never will a wallet be sent in a request that contains information identifies to a user. ### What is generated? Is Jomo making an attestation that others need to trust or does the proof prove it? Two things get generated when you complete a Jomo prove. An attestation in the form of `EAS Attestation` from Jomo about your aggregated wallet data. For example if you were proving BAYC Whale, the attestation could be about `you own 6 BAYCs across 3 wallets`. The beauty here is that Jomo doesn't even know the number (6) of BAYCs you have, but we were able to attest it by signing a piece of message which you can then use to derive the exact number out from. The user knows the exact number and the secret to be used to reveal the message, and these private information is only stored on user's local device. A `Zero-Knowledge Proof` that the attestation signed by Jomo contains information about how many BAYCs you own, and the `number is greater or equal than 3`. The exact number (6) is hidden from the public, as well as the secret to reveal the attestation. The only thing gets revealed is the threshold (3) and an unique ID of the attestation so it can't be reused again and again. At the moment, Jomo verifies the proof on our own backend and provides the verification results to our requesters. However we are going to expose both public APIs as well as Smart Contract method so that anyone can verify it anytime. ### What information is sent back to the proof's requester (such as icebreaker)? This depends on what type of proof has been done. For most of the cases, the only information being sent back is a `yes` meaning that the requested proof has been completed by you. Below is and example schema that is sent back to the requester: * `public_account_id`: The unique identifier to attach verification result with, sent from the requester to Jomo and agnostic to Jomo. * `type`: The type of the verification * `id`: The unique identifier for this type of verification. This will be a randomized unique id that cannot reverse identify to any user * `timestamp`: The timestamp verification is generated * `attester`: Person or entity who attested for the verification. This should be Jomo for most of the cases now but we are going to support other attesters in the future. * `signature`: The cryptographic signature from the attester on the verification ### Why should I use this vs something like delegate.xyz? delegate.xyz mainly solves the security part of the problem in that you make fewer transactions with your high value cold wallet. Jomo in addition to solving the same security problem, preserves your privacy at the same time too. Unlike when using delegate.xyz, on Jomo your wallet associations are never known or revealed to anyone, including Jomo. This means that not even can you keep your whale wallet secure, it also protects it from unfriendly eyes and excessive gawking and followings. Further more, using Jomo you can further hide your exact raw information and only present proofs of eligibility. For example instead of letting everyone know that you have 4 wallets and a total of 10 BAYCs, using Jomo you can prove that you own more than 5 BAYCs and present just that. No information about which wallets are those, nor exactly how many BAYCs do you own are exposed. ### Why should I use this vs just connecting the wallet with my tokens? Similar to answered above, mainly for security and privacy. We all know how scary crypto world can be :) Jomo allows you to link your whale wallet once and be able to prove things about it forever, which makes the cold wallet safer. At the same time, the wallet associations between your wallets are only known to yourself at all times. Even when you share a proof to a project, all they get is anonymized data. This saves you from unfriendly gawking and following and protects your privacy. # Privacy Policy Version 2023-10-03 One of the core principles and drivers behind building Jomo is to respect user's privacy and set users free from worrying about their information being leaked around. This Privacy Policy describes how we collect, use, and disclose information that we obtain about you through your journey with Jomo, including the [jomo.id](https://jomo.id) site and the use of our extension Jomo Helper. 1. **Information and Data** No personal data of our users is sent or stored on our servers. No credentials of any websites the users accessed via Jomo is accessible or shared with anyone including our servers. All unencrypted information stays on the user's local device and the local device only. 2. **How We Use Your Information** Since we don't have any of your information, we don't use it anywhere or sell it to anyone. 3. **Information Sharing** Since we don't have any of your information, we don't share it anywhere or to anyone. 4. **Data Retention** No personal data is retained on our server. Certain verifiable credentials are generated and stored on user's local device so they can choose to reuse it easily in the future. The user has full control over how and for how long they would like to keep those data. 5. **Security** We take reasonable measures to protect the information provided by our users, including ensuring that our Site is secure and using secure connections. 6. **Your Choices** Certain verifiable credentials are generated and stored on user's local device so they can choose to reuse it easily in the future. The user has full control over how and for how long they would like to keep those data. 7. **Changes to this Policy** We may update this Privacy Policy from time to time. We will notify you if we make material changes by posting the updated policy on our Site. 8. **Contact** If you have any questions or concerns about this Privacy Policy, don't hesitate to get in touch with us at ****. # Overview Jomo Connect enables applications to easily verify user data from various onchain or offchain sources via zero knowledge proof without getting user's raw data exposed to anyone. ## Glossary
TermDefinitionExample
VC

A verifiable credential is a statement about some piece of information, that is verifiably attested by an attester.

A VC could be about someone or something, or not be about a specific entity. It could be bound to an unique identifier, or could just be stored by anyone anywhere.

All VCs created for users by Jomo are stored in the form of EAS attestations.

  • Statement: The Earth is a sphere
  • Attester: Columbus
  • Signature: Columbus signing on the Statement
Private VCA private VC is a VC that nobody except for its owner, knows about its detailed contents in the statement. The general public only sees a deterministically encrypted form of the statement but not the raw data.
  • Actual content (only the VC owner knows): passport number, country, issue and expiry date, name, etc
  • Statement: Some sort of hash of the content above
  • Attester: Government
  • Signature: The NFC chip on the physical passport containing a signature of the statement
Attributes

A data attribute is a field→value pair within a VC content.

Note that for private VCs, other than the owners themselves, no one else should know what attributes and their values exist in a private VC

  • <company_name, Jomo>
  • <passport_issue_country, USA>
## Use Cases The private VC verification framework enables users to use their private data and get benefits by proving they qualify for them, without revealing any tangible private information. Example use cases include proving that: * I have donated to Gitcoin in total value of X (private information: all addresses I own) * Smart contracts I deployed over different chains have acquired activities of amount Y (private information: all addresses I own) * My Github repositories have a total stars of Z (private information: my github handle) * I have worked at company A for > B years (private information: who I am) * Owns a house valued > $1M (private information: my home address, house value) ## Example Experience * User is redirected to Jomo Connect when you try to verify the private information of a user
* User connects to the corresponding data source and have Jomo generate a private VC for them.
* Jomo Connect frontend generates zero knowledge proof based on the user's private VC
* You receive the zero knowledge proof and associated additional data
* You verify the proof and additional data are valid with Jomo Connect Smart Contract or Backend * (Optional) Jomo Connect backend verifies the proof and share with you the validness of the proof and any corresponding results via a callback or subsequent API calls * You customize the UX based on the result
# Quick Start A quick start guide to help you connect to any private user data onchain or offchain using Jomo Connect ## [Prerequisites](/build-with-jomo-connect/quick-start/prerequisites) ## Initiate Connection Initiate the connection by redirecting your users to the according Jomo Connect page. ```url https://jomo.id/prove?flowid=&publicaccountid= ``` Request parameters: * `flowid`: The uuid of the Jomo verification flow. * `publicaccountid`: The unique identifier to attach verification result with. Specified by the caller and agnostic to Jomo. ## APIs ### Handle Verification Result For clients that choose to have Jomo Backend validate the zk proofs for them, Jomo would send the validated results via the following 2 channels. #### Verification API Callback When the verification is done on Jomo Connect, Jomo sends the result back via the callback URL ``` POST {parameters} ``` *Request parameters* * `public_account_id`: The unique identifier to attach verification result with * `type`: The type of the verification * `id`: The unique identifier for this type of verification * `timestamp`: The timestamp verification is generated * `attester`: Person or entity who attested for the verification * `signature`: The cryptographic signature from the attester on the verification * `[additional_fields]`: Additional fileds containing additional information apart from whether user passed flow or not. Example: the boundry of the range proof (the user is proving that they earned more than $90K last year vs proving they earned more than $50K last year) #### Query Verifications API You can also query past verifications via Jomo API ``` POST https://jomo.id/api/verify/verifications ``` *Request parameters* * `api_key`: The api key for your project * `public_account_id`: The account that we are querying results for * `flow_id`: *\[optional]* The uuid of the Jomo verification flow. Specified when only results from one flow is requested (The flow must be associated to your project) * `with_eas_link`: \[optional] Boolean to indicate whether the reponse should contain an EAS link to the source private VC used to generate the proof *Response parameters* A list of public VCs with each public VC includes: * `public_account_id`: The unique identifier to attach verification result with * `type`: The type of the verification * `id`: The unique identifier for this type of verification * `timestamp`: The timestamp verification is generated * `attester`: Person or entity who attested for the verification * `signature`: The cryptographic signature from the attester on the verification * `[private_vc_eas_link]`: present if `with_eas_link` is set to true in request, contains a link to EAS page where the original private VC content can be seen. * `[additional_fields]`: Additional fileds containing additional information apart from whether user passed flow or not. Example: the boundry of the range proof (the user is proving that they earned more than $90K last year vs proving they earned more than $50K last year) ### Handle ZK Proofs For clients that choose to handle the ZK proofs yourself, Jomo also provides 2 approaches to pass back the proofs. #### Proof API Callback When the verification is done on Jomo Connect, Jomo sends the generated proof back via the callback URL ``` POST {parameters} ``` *Request parameters* * `public_account_id`: The unique identifier to attach verification result with * `type`: The type of the verification * `proof`: The zk proof generated via the frontend * `public_result`: The selectively disclosed public data associated to the proof. Example: the boundry of the range proof (the user is proving that they earned more than $90K last year vs proving they earned more than $50K last year) * `attestation`: The EAS attestation issued by Jomo which attests to the validity of original data which the zk proof is proving out of. #### Proof Verifications API You can also query past proofs via Jomo API ``` POST https://jomo.id/api/verify/proofs ``` *Request parameters* * `api_key`: The api key for your project * `public_account_id`: The account that we are querying results for * `flow_id`: *\[optional]* The uuid of the Jomo verification flow. Specified when only results from one flow is requested (The flow must be associated to your project) *Response parameters* A list of zk proofs: * `public_account_id`: The unique identifier to attach verification result with * `type`: The type of the verification * `proof`: The zk proof generated via the frontend * `public_result`: The selectively disclosed public data associated to the proof. Example: the boundry of the range proof (the user is proving that they earned more than $90K last year vs proving they earned more than $50K last year) * `attestation`: The EAS attestation issued by Jomo which attests to the validity of original data which the zk proof is proving out of. ### Verify ZK Proofs and Attestations Whether the client chooses to handle the zk proofs yourself or wants to perform additional validation. Jomo provides following tools for you or your users to validate whether a ZK proof or an attestation is valid. (Coming soon) * A public smart contract with a read only function that everyone can use * A public backend API * A dedicated frontend UI so users can easily copy paste a blob of attestation and zk proofs to validate them # Prerequisites Prepare the following to integrate with Jomo ### Information Prepare the following information before the Jomo Connect verification happens. * **verification type** - Indicates the conditions you would like your users to satisfy. Our infrastructure allows you to verify aggregated data from multiple wallets owned by the same user. E.g. Verify the user has a punk (usually in a cold wallet) as well as the user has made >100 transactions (usually in a hot wallet). Choose from a set of [pre-existing types](/build-with-jomo-connect/supported-verification-types), or talk with Jomo team about your specific requirements so we can build out a new type for you. * **flow id** - Create your verification flow or chat with the Jomo team to create one for you. Within the flow definition you will then specify the verification type being run, and other details * **public account id** - Every time a verification is initiated, in addition to the `flow_id`, Jomo also requests the caller to pass in a `public_account_id`. This is the identifier we will bind verification results to for easy query access later. You choose your own unique identifier schemes to be the public account id, we don't have to understand it. * \[optional] **redirect uri** - The URL to be redirected to after the Jomo Connect verification completes * \[optional] **callback uri** - The URL where Jomo Connect will post verification results to when it's completed * **jomo api key** - You will get this from Jomo, so you can then use this to query completed verifications any time ### Pre Redirect Page Your team will prepare this page where you present to your users what offers or benefits will be provided for passing the verification, the criterias, any additional information, and a primary CTA to redirect the user to Jomo's verification flow. ### Post Redirect Page Your team will prepare this page that corresponds to the redirectURI provided to Jomo. On this page you will either be pooling Jomo backend for results corresponding to a `public_account_id`, or listening to callbacks coming from Jomo backend. # Supported Verification Types Jomo already has a list of supported verification types that anyone can use. Talk to us if the verification you want to support is not listed! ### Aggregate onchain public data #### Verification Method Connect wallet #### Verification Types
Verification TypeNameDescriptionAdditional Fields
cryptopunks_sum_gte_1PunkHolderHolds at least 1 CryptoPunk
cryptopunks_sum_gte_3PunkWhaleHolds at least 3 CryptoPunks across at most 3 wallets
bayc_sum_gte_1BAYCHolderHolds at least 1 BAYC
bayc_sum_gte_3BAYCWhaleHolds at least 3 BAYCs across at most 3 wallets
mayc_sum_gte_1MAYCHolderHolds at least 1 MAYC
mayc_sum_gte_3MAYCWhaleHolds at least 3 MAYCs across at most 3 wallets
azuki_sum_gte_1AzukiHolderHolds at least 1 Azuki
azuki_sum_gte_3AzukiWhaleHolds at least 3 Azukis across at most 3 wallets
station3_patron_sum_gte_1Station3 PatronHolds at least 1 Station 3 NFT
mfers_sum_gte_1MfersHolderHolds at least 1 Mfers
mfers_sum_gte_3MfersLoverHolds at least 3 Mfers across at most 3 wallets
mfers_sum_gte_5MfersWhaleHolds at least 5 Mfers across at most 3 wallets
eth_class_of_yearCrypto Class of YearProves the year of the earliest transaction the user made on Ethereum class_of_year
member_of_powers_of_tauPowers of Tau Ceremony ParticipantParticipated in Powers of Tau Ceremony
### Connect offchain private data #### Verification Method Log in to web2 accounts #### Verification Types
Verification TypeNameDescriptionFieldsWebsites
us_brokerage_portfolio_movementStock Portfolio MovementGenerate a notarization of your portfolio movement percentage inside your brokerage accountbrokerage_id
time_span
total_return		Robinhood
yearly_gross_incomeYearly Gross IncomeGenerate a proof of your gross income using your tax software accounttax_source
user_id
gross_income		TurboTax
# Public Flows Here's a list of public flows showcasing what a user can do. These flows don't ask the user to pass verified data to any client, instead they can choose to share on social platforms. But you can build the exact same flow whilist asking the user to prove the data to your application!
flow_idverification_typeName
104us_brokerage_portfolio_movementRobinhood Investment Return
107yearly_gross_incomeProof of Gross Income