diff --git a/README.md b/README.md index 3c5bb40..4f538af 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,5 @@ --- -description: Sovereign Identity Aggregator and Cryptonative SSO +description: Sovereign identity aggregator and crypto-native SSO cover: .gitbook/assets/Gibook Banner1_1900x400.png coverY: 0 layout: @@ -22,7 +22,7 @@ layout: Sismo leverages zero-knowledge proofs (ZKPs) and privacy-preserving technologies to **enable** **users to aggregate their identities and selectively disclose personal data** to applications. -By using Sismo Connect, an easy-to-integrate SSO, applications **can now obtain personal data that was previously inaccessible, while respecting users' privacy.** +By using Sismo Connect, an easy-to-integrate single sign-on (SSO), applications **can now obtain personal data that was previously inaccessible, while respecting user privacy.** [Sismo Connect](./#sismo-connect-the-crypto-native-sso) aims to replace non-sovereign SSOs such as Google Connect and improve limited SSOs such as Wallet Connect. @@ -30,9 +30,9 @@ By using Sismo Connect, an easy-to-integrate SSO, applications **can now obtain ## Data Vault: Sovereign Identity Aggregator -Users aggregate their identity by adding Data Sources to their sovereign, local and private [Data Vault](how-sismo-works/core-components/what-is-the-data-vault.md). +Users aggregate their identity by adding Data Sources to their private, local and sovereign [Data Vault](how-sismo-works/core-components/what-is-the-data-vault.md). -The Data Vault currently supports the following types of Data Sources: Ethereum wallets, GitHub, Twitter or Telegram accounts. Users can generate ZK Proofs from their Data Sources, enabling them to reveal data to applications in a sovereign way. +The Data Vault currently supports the following types of Data Sources: Ethereum wallets, GitHub, Twitter or Telegram accounts. Users can generate ZK proofs from their Data Sources, enabling them to reveal data to applications in a sovereign way.

What a Data Vault looks like

@@ -40,9 +40,9 @@ The Data Vault currently supports the following types of Data Sources: Ethereum You can create your own Data Vault and start aggregating your identity [here](https://vault-beta.sismo.io/). {% endhint %} -## Sismo Connect: The Cryptonative SSO +## Sismo Connect: The Crypto-Native SSO -Sismo Connect is a cryptonative single sign-on method (SSO) for onchain and offchain apps. Sismo Connect makes it easy for developers to obtain users' personal data by requesting and verifying ZK proofs. +Sismo Connect is a crypto-native single sign-on (SSO) for onchain and offchain apps. Sismo Connect makes it easy for developers to access personal data without infringing on user privacy by requesting and verifying ZK proofs. {% hint style="success" %} Experience Sismo Connect on the [Demo App Store](https://demo.apps.sismo.io)! @@ -50,20 +50,20 @@ Experience Sismo Connect on the [Demo App Store](https://demo.apps.sismo.io)!
-Integration is simple with just a few lines of code: import the front-end package or React button to make Sismo Connect requests, and verify proofs in your backend/ smart contracts using Sismo’s Solidity or TypeScript package. +Integration is simple with just a few lines of code: import the front-end package or React button to make Sismo Connect requests, and verify proofs in your back end/smart contracts using Sismo’s Solidity or TypeScript package. -Applications can request many data at once. There exist two types request that can be made: +With Sismo Connect, applications can request data from multiple sources at once. There are two types of requests that can be made: -* authentication: ZK Proof of Data Source ownership. (Ethereum wallets, GitHub, Twitter or Telegram accounts) -* disclosure of anonymised personal data: ZK Proofs of Data Source inclusion in a specific Data Group (+ claim about its value in the group). +* **Authentication**: ZK proof of Data Source ownership (e.g. Ethereum wallets, GitHub, Twitter or Telegram accounts). +* **Disclosure of anonymized personal data**: ZK proofs of Data Source inclusion in a specific Data Group (e.g. GR15 contributor). {% hint style="info" %} -Data Groups are sets of Data Sources where each Data Source has an associated value. +Data Groups are sets of Data Sources in which each Data Source has an associated value. {% endhint %}
-Concrete examples Data Groups and ZK Proofs you can request from users +Concrete examples Data Groups and ZK proofs you can request from users ```json { // "Stand With Crypto" NFT Minters Data Group @@ -81,12 +81,12 @@ Data Groups are sets of Data Sources where each Data Source has an associated va } ``` -* All owners of these wallets can create a ZK Proof that they are part of this group +* All owners of these wallets can generate a ZK proof attesting that they are part of this group -* owner of `0x70ddb5abf21202602b57f4860ee1262a594a0086` can create a ZK Proof that they are part of the group with value > 10 (e.g minted more than 10 NFTs) -* owner of 0xa2bf1b0a7e079767b4701b5a1d9d5700eb42d1d1 can create a ZK Proof that they are part of the group with value = 21 (e.g minted exactly 2 NFT) +* The owner of `0x70ddb5abf21202602b57f4860ee1262a594a0086` can generate a ZK proof attesting that they are part of this group with a value > 10 (e.g, minted more than 10 NFTs) +* The owner of 0xa2bf1b0a7e079767b4701b5a1d9d5700eb42d1d1 can generate a ZK proof attesting that they are part of this group with a value = 2 (e.g, minted exactly 2 NFTs) @@ -108,12 +108,12 @@ Data Groups are sets of Data Sources where each Data Source has an associated va } ``` -* All owners of these wallets can create a ZK Proof that they are part of this group +* All owners of these wallets can generate a ZK proof attesting that they are part of this group -* owner of `dhadrien.eth` can create a ZK Proof that they are part of the group with value > 2 (e.g community member with level > 2) -* owner of @wojtekwtf on twitter can create a ZK Proof that they are part of the group with value = 3 (e.g community member with level 3) +* The owner of `dhadrien.eth` can generate a ZK proof attesting that they are part of the group with a value > 2 (e.g, community member with level > 2) +* The owner of @wojtekwtf on Twitter can generate a ZK proof attesting that they are part of the group with a value = 3 (e.g, community member with level 3) @@ -123,26 +123,25 @@ Examples of Data Groups: | Data Group Examples | Members (Data Sources) | Value for each Data Source | | --------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | ---------------------------------------- | -| ["Stand With Crypto" NFT Minters](https://factory.sismo.io/groups-explorer?search=0xfae674b6cba3ff2f8ce2114defb200b1) | Wallets of minters | number of NFT minted | -| [Gitcoin Passport Holders](https://factory.sismo.io/groups-explorer?search=0x1cde61966decb8600dfd0749bd371f12) | Wallets of Gitcoin Passport holders | sybil-resistant score | -| [Sismo Hub Github Contributors ](https://factory.sismo.io/groups-explorer?search=0xda1c3726426d5639f4c6352c2c976b87) | Github accounts of contributors to sismo-core/sismo-hub repo | number of contributions | -| [ENS DAO Voters](https://factory.sismo.io/groups-explorer?search=0x85c7ee90829de70d0d51f52336ea4722) | Wallets of voters in ENS DAO | number of votes | -| [Sismo Community Members](https://factory.sismo.io/groups-explorer?search=0xd630aa769278cacde879c5c0fe5d203c) | Wallets, GitHub, Telegram and twitter accounts of all people that helped Sismo | level of their contributions (1, 2 or 3) | +| ["Stand With Crypto" NFT Minters](https://factory.sismo.io/groups-explorer?search=0xfae674b6cba3ff2f8ce2114defb200b1) | Wallets of minters | Number of NFT minted | +| [Gitcoin Passport Holders](https://factory.sismo.io/groups-explorer?search=0x1cde61966decb8600dfd0749bd371f12) | Wallets of Gitcoin Passport holders | Sybil-resistant score | +| [Sismo Hub GitHub Contributors ](https://factory.sismo.io/groups-explorer?search=0xda1c3726426d5639f4c6352c2c976b87) | GitHub accounts of contributors to sismo-core/sismo-hub repo | Number of contributions | +| [ENS DAO Voters](https://factory.sismo.io/groups-explorer?search=0x85c7ee90829de70d0d51f52336ea4722) | Wallets of voters in ENS DAO | Number of votes | +| [Sismo Community Members](https://factory.sismo.io/groups-explorer?search=0xd630aa769278cacde879c5c0fe5d203c) | Wallets, GitHub, Telegram and Twitter accounts of all people that helped Sismo | Level of their contributions (1, 2 or 3) | {% hint style="info" %} -Anyone can [create a new Data Group](data-groups/data-groups-and-how-to-create-them/). +Anyone can [create a new Data Group](data-groups/data-groups-and-creation/). {% endhint %}
Broken linkBuild with Sismo Connect.png
https://apps.sismo.ioAppStore.png
https://case-studies.sismo.ioCase Studies.png
## Case Study: Sybil-Resistant Airdrop from Privately Aggregated Data -SafeDrop is a Sybil-resistant and privacy-preserving ERC20 airdrop that distributes AIR tokens to users proportionally based on their reputation, aggregated from diverse sources of data (EVM wallets, Telegram, Twitter and GitHub accounts). +SafeDrop is a Sybil-resistant and privacy-preserving ERC20 airdrop that distributes $AIR tokens to users proportionally based on their reputation, aggregated from diverse sources of data (EVM wallets, Telegram, Twitter and GitHub accounts).
-By integrating Sismo Connect, SafeDrop users can generate a ZK proof to establish they own data in their accounts that make them eligible for the airdrop. \ -No connection between these accounts and the airdrop destination address is ever made. +By integrating Sismo Connect, SafeDrop users can generate a ZK proof to establish ownership of the data that makes them eligible for the airdrop. No connection between these accounts and the airdrop destination address is ever made. {% hint style="success" %} Read the full case study [here](https://case-studies.sismo.io/db/safe-drop). diff --git a/SUMMARY.md b/SUMMARY.md index cffc2ac..a796573 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -13,9 +13,9 @@ * [Onchain Boilerplate](build-with-sismo-connect/run-example-apps/onchain-sample-project.md) * [Offchain Boilerplate](build-with-sismo-connect/run-example-apps/offchain-sample-project.md) * [Tutorials](build-with-sismo-connect/tutorials/README.md) - * [Get your appId - Create a Sismo Connect App](build-with-sismo-connect/tutorials/create-a-sismo-connect-app.md) - * [Onchain Tutorial (1/2): code your Airdrop contract with privately-aggregated data](build-with-sismo-connect/tutorials/tuto.md) - * [Onchain Tutorial (2/2): deploy your Airdrop contract](build-with-sismo-connect/tutorials/deploy-your-contracts.md) + * [Get Your appId - Create a Sismo Connect App](build-with-sismo-connect/tutorials/create-a-sismo-connect-app.md) + * [Onchain Tutorial (1/2): Code Your Airdrop Contract With Privately-Aggregated Data](build-with-sismo-connect/tutorials/tuto.md) + * [Onchain Tutorial (2/2): Deploy Your Airdrop Contract](build-with-sismo-connect/tutorials/deploy-your-contracts.md) * [Technical Documentation](build-with-sismo-connect/technical-documentation/README.md) * [Sismo Connect Configuration](build-with-sismo-connect/technical-documentation/sismo-connect-configuration.md) * [Auths](build-with-sismo-connect/technical-documentation/auths.md) @@ -31,10 +31,10 @@ ## Data Groups -* [Data Groups & How to Create them?](data-groups/data-groups-and-how-to-create-them/README.md) - * [Factory Guide: Create a Data Group in 5 Minutes](data-groups/data-groups-and-how-to-create-them/create-your-data-group.md) - * [Sismo Hub Guide: Create Data Groups Programmatically](data-groups/data-groups-and-how-to-create-them/create-your-group-generator.md) - * [Sismo Hub Guide: Add a Data Provider to the Sismo Factory](data-groups/data-groups-and-how-to-create-them/create-your-data-provider.md) +* [Data Groups & Creation](data-groups/data-groups-and-creation/README.md) + * [Factory Guide: Create a Data Group in 5 Minutes](data-groups/data-groups-and-creation/create-your-data-group.md) + * [Sismo Hub Guide: Create Data Groups Programmatically](data-groups/data-groups-and-creation/create-your-group-generator.md) + * [Sismo Hub Guide: Add a Data Provider to the Sismo Factory](data-groups/data-groups-and-creation/create-your-data-provider.md) ## How Sismo Works @@ -55,21 +55,22 @@ * [Command Line Interface](how-sismo-works/resources/sismo-hub/command-line-interface.md) * [Sismo API](how-sismo-works/resources/sismo-api/README.md) * [API Links](how-sismo-works/resources/sismo-api/api-links.md) - * [Query from a client](how-sismo-works/resources/sismo-api/query-from-a-client.md) + * [Query From a Client](how-sismo-works/resources/sismo-api/query-from-a-client.md) * [Group](how-sismo-works/resources/sismo-api/group/README.md) * [Get groups](how-sismo-works/resources/sismo-api/group/get-groups.md) * [Get group snapshots](how-sismo-works/resources/sismo-api/group/get-group-snapshots.md) - * [Common parameters](how-sismo-works/resources/sismo-api/common-parameters.md) - * [Advanced filtering](how-sismo-works/resources/sismo-api/advanced-filtering.md) - * [Other models](how-sismo-works/resources/sismo-api/other-models/README.md) - * [Transaction](how-sismo-works/resources/sismo-api/other-models/transaction.md) + * [Common Parameters](how-sismo-works/resources/sismo-api/common-parameters.md) + * [Advanced Filtering](how-sismo-works/resources/sismo-api/advanced-filtering.md) + * [Transaction](how-sismo-works/resources/sismo-api/transaction.md) * [Deployed Contract Addresses](how-sismo-works/resources/sismo-101.md) ## Links +* [Sismo Landing Page](https://www.sismo.io/) * [Sismo Factory](https://factory.sismo.io/) * [Sismo App Store](https://apps.sismo.io) -* [Sismo Builders Resources](https://resources.sismo.io) +* [Sismo Builder Resources](https://resources.sismo.io) * [GitHub](https://github.com/sismo-core) * [Discord](https://discord.gg/xKTMeRUX6u) * [Twitter](https://twitter.com/sismo\_eth) +* [Blog](https://blog.sismo.io/) diff --git a/build-with-sismo-connect/getting-started-1.md b/build-with-sismo-connect/getting-started-1.md index b2ee189..0493789 100644 --- a/build-with-sismo-connect/getting-started-1.md +++ b/build-with-sismo-connect/getting-started-1.md @@ -1,17 +1,20 @@ # Quickstart -This section targets developers experienced with installation of new tools to their own repositories. + If you have difficulties, head over to the pre-configured [boilerplates](run-example-apps/) or [tutorials](tutorials/). Neither demand experience in our tech stack to get you setup. - If you have difficulties, head over to the pre-configured [boilerplates](run-example-apps/) or [tutorials](tutorials/). Neither demand experience in our tech stack to get you setup. +This section is intended for developers who have prior experience with incorporating new tools into their existing repositories. -## Step 1 - Setup: Create your Sismo Connect App +{% hint style="info" %} +Having difficulties? Head over to the pre-configured [boilerplates](run-example-apps/) or [tutorials](tutorials/). Neither demand experience with Sismo's tech stack to get set up. +{% endhint %} + +## Step 1 - Setup: Create Your Sismo Connect App -You must create a Sismo Connect App in the [Sismo Factory](https://factory.sismo.io) ([tutorial](tutorials/create-a-sismo-connect-app.md)) and get your appId. this appId will be required both in your frontend and smart contracts/ backend. +You must create a Sismo Connect app in the [Sismo Factory](https://factory.sismo.io) ([tutorial](tutorials/create-a-sismo-connect-app.md)) and get your appId. This appId will be required both in your front end and smart contracts/back end. -## Step 2 - Request: Integrate Sismo Connect in your frontend +## Step 2 - Request: Integrate Sismo Connect in Your Front End -Your frontend must make a Sismo Connect request, users will be redirected to their Data Vault to generate a ZK Proof and your frontend will receive a Sismo Connect Response from them. \ -This response, containing the ZK Proof, will be verified on your backend/smart contract. +Your front end must make a Sismo Connect request for users to be redirected to their Data Vault to generate a ZK proof and send your front end a Sismo Connect Response. This response, containing the ZK proof, will be verified on your back end/smart contract. {% hint style="success" %} Check the [Sismo Connect Cheatsheet](sismo-connect-cheatsheet.md) to see examples of requests. @@ -34,19 +37,20 @@ npm install @sismo-core/sismo-connect-react {% endtabs %} {% hint style="info" %} -`@sismo-core/sismo-connect-client` is also available for non react frontend. ([docs](technical-documentation/packages/client.md)) +`@sismo-core/sismo-connect-client` is also available for non-React front ends. ([docs](technical-documentation/packages/client.md)) {% endhint %} 2. Create your Sismo Connect config ```typescript +// sismo-connect-config.ts import { SismoConnectConfig } from "@sismo-core/sismo-connect-react"; -const config: SismoConnectConfig = { +export const config: SismoConnectConfig = { appId: "0xf4977993e52606cfd67b7a1cde717069", // replace with your appId // vault: { - // // For development purposes insert the Data Sources that you want to impersonate here + // // For development purposes, insert the Data Sources that you want to impersonate here // // Never use this in production // impersonate: [ // // EVM @@ -63,85 +67,50 @@ const config: SismoConnectConfig = { // ], // }, // displayRawResponse: true, + }; ``` {% hint style="info" %} -[Learn more](technical-documentation/sismo-connect-configuration.md) about Sismo Connect config and impersonation mode +[Learn more](technical-documentation/sismo-connect-configuration.md) about Sismo Connect config and impersonation mode. {% endhint %} 3. Use our React Button to make Sismo Connect Requests ```typescript +// Component.tsx -// in nextjs page.tsx -"use client"; - -import { - SismoConnectButton, - AuthType, - SismoConnectResponse, -} from "@sismo-core/sismo-connect-react"; - -export default function Home() { - return ( - { - await fetch("/api/verify", { - method: "POST", - body: JSON.stringify(response), - }); - // to call contracts - // onResponseBytes={async (response: SismoConnectResponse) => { - // await myContract.claimWithSismo(response.responseBytes); - // } - }} - /> - ); -} +import { SismoConnectButton, AuthType, SismoConnectResponse } from "@sismo-core/sismo-connect-react"; +import { config } from "./sismo-connect-config.ts"; + + { + // call your contract/back end with the response as bytes + }} +/> ``` {% hint style="success" %} -Check the [Sismo Connect Cheatsheet ](sismo-connect-cheatsheet.md) to get a large set of interesting requests +Check the [Sismo Connect Cheatsheet ](sismo-connect-cheatsheet.md)to get a large set of interesting requests. {% endhint %} -## Step 3 - Verify: Sismo Connect in your Smart Contracts/ Backends +## Step 3 - Verify: Sismo Connect in Your Smart Contracts/Back Ends -Your backend/smart contract will receive a Sismo Connect Response forwarded from your frontend that you must verify. +Your back end/smart contract will receive a Sismo Connect Response forwarded from your front end that you must verify. 1. Install the Sismo Connect Library
-EVM Chains supported +Supported EVM Chains #### Mainnets @@ -170,7 +139,7 @@ Your backend/smart contract will receive a Sismo Connect Response forwarded from Make sure to have [Foundry](https://book.getfoundry.sh/getting-started/installation) installed. {% endhint %} -Install the forge dependency: +Install the Forge dependency: ```bash foundryup @@ -192,7 +161,7 @@ yarn add @sismo-core/sismo-connect-solidity #### Import the library -In your solidity file: +In your Solidity file: ```solidity import "@sismo-core/sismo-connect-solidity/contracts/libs/SismoLib.sol"; @@ -201,7 +170,7 @@ import "@sismo-core/sismo-connect-solidity/contracts/libs/SismoLib.sol"; {% endtabs %} {% endtab %} -{% tab title="Offchain - Verify in a Backend" %} +{% tab title="Offchain - Verify in a Back End" %} Install the TypeScript library {% tabs %} @@ -214,10 +183,10 @@ yarn add @sismo-core/sismo-connect-server {% endtab %} {% endtabs %} -2. Reuse your Sismo Connect config and verify Sismo Connect responses sent from your frontend +2. Reuse your Sismo Connect config and verify Sismo Connect responses sent from your front end {% hint style="warning" %} -The config you use in your smart contract/ backend must exactly match the one from your frontend. +The config you use in your smart contract/backend must exactly match the one from your front end. {% endhint %} {% tabs %} @@ -247,8 +216,8 @@ contract Airdrop is SismoConnect { {% endtab %} -{% tab title="Offchain - Verify in a Backend" %} -Reuse the Sismo Connect configuration from your frontend +{% tab title="Offchain - Verify in a Back End" %} +Reuse the Sismo Connect configuration from your front end ```solidity // sismo-connect-config.ts @@ -260,7 +229,7 @@ export const config: SismoConnectConfig = { }; ``` -Create an api route to receive the Sismo Connect response and verify it. +Create an API route to receive the Sismo Connect response and verify it. ```typescript // my-api.ts @@ -273,7 +242,7 @@ const sismoConnect = SismoConnect(sismoConnectConfig); app.post('/api', (req, res) => { const { response } = req.body; const result: SismoConnectVerifiedResult = await sismoConnect.verify(response, { - / request proof of Data Sources ownership (e.g EVM, GitHub, twitter or telegram) + / request proof of Data Sources ownership (e.g EVM, GitHub, Twitter or Telegram) auths=[{ authType: AuthType.GITHUB }] // request group membership (e.g NFT ownership, Dao Participation, GitHub commits) claims=[{groupId: ENS_DAO_VOTERS_GROUP_ID}] @@ -298,4 +267,3 @@ const sismoConnect = SismoConnect(sismoConnectConfig); ``` {% endtab %} {% endtabs %} - diff --git a/build-with-sismo-connect/getting-started.md b/build-with-sismo-connect/getting-started.md index a71cc81..1ad52aa 100644 --- a/build-with-sismo-connect/getting-started.md +++ b/build-with-sismo-connect/getting-started.md @@ -2,15 +2,15 @@
-Integrating Sismo Connect means 3 main steps: +Integrating Sismo Connect has three main steps: -* Create a **Sismo Connect Application in the Sismo Factory** -* **In your Frontend: Use our React button or client library to request ZK Proofs from users** (like you would request a signature with Wallet Connect) -* **In your Backend/Smart Contracts: Use our Solidity/TypeScript library to verify those ZK Proofs** (like you would verify a signature with ethers/viem/ecrecover) +* Create a Sismo Connect application in the [Sismo Factory](https://factory.sismo.io/) +* In your front end: Use our React button or client library to request ZK proofs from users (like you would request a signature with Wallet Connect) +* In your back end/smart contracts: Use our Solidity/TypeScript library to verify those ZK proofs (like you would verify a signature with ethers/viem/ecrecover)
-EVM Chains supported +Supported EVM Chains #### Mainnets @@ -31,6 +31,4 @@ Integrating Sismo Connect means 3 main steps:
- -
#sismo-connect-the-crypto-native-ssoWhat is Sismo Connect (2).png
run-example-appsBoilerplates.png
tutorialsTutorials.png
diff --git a/build-with-sismo-connect/run-example-apps/README.md b/build-with-sismo-connect/run-example-apps/README.md index fe15778..9196735 100644 --- a/build-with-sismo-connect/run-example-apps/README.md +++ b/build-with-sismo-connect/run-example-apps/README.md @@ -4,19 +4,19 @@ description: Get a feel for Sismo Connect. # Boilerplates -You can use two boilerplates to be setup with Sismo Connect in minutes. +You can use two boilerplates to be set up with Sismo Connect in minutes. -1. The[ **onchain** boilerplate ](onchain-sample-project.md)— implementation of simple Airdrop Contract using Sismo Connect: - * Next.js for frontend, Foundry for smart contract - * Sismo Connect React Button to request ZK Proofs - * Sismo Connect solidity library to verify ZK Proofs onchain -2. The [**offchain** boilerplate](offchain-sample-project.md) — implementation a simple authentication to a server using Sismo Connect: - * Next.js for frontend and backend - * Sismo Connect React Button to request ZK Proofs - * Sismo Connect typescript library to verify ZK Proofs in a backend +1. The[ **onchain** boilerplate ](onchain-sample-project.md)— implementation of a simple airdrop Contract using Sismo Connect: + * Next.js for front end, Foundry for smart contracts + * Sismo Connect React Button to request ZK proofs + * Sismo Connect Solidity library to verify ZK proofs onchain +2. The [**offchain** boilerplate](offchain-sample-project.md) — implementation of a simple authentication for a server using Sismo Connect: + * Next.js for front end and back end + * Sismo Connect React Button to request ZK proofs + * Sismo Connect TypeScript library to verify ZK proofs in a back end {% hint style="success" %} -Like Sismo Connect? Dive deep into the codebase or jump into this [hands-on tutorial](../tutorials/tuto.md) on integrating a Sybil-Resistant gated airdrop for Sismo Community members. +Like Sismo Connect? Dive deep into the codebase or jump into this [hands-on tutorial](../tutorials/tuto.md) on integrating a Sybil-resistant gated airdrop for Sismo Community members. {% endhint %} {% content-ref url="onchain-sample-project.md" %} diff --git a/build-with-sismo-connect/run-example-apps/offchain-sample-project.md b/build-with-sismo-connect/run-example-apps/offchain-sample-project.md index a965c7f..c7bbff9 100644 --- a/build-with-sismo-connect/run-example-apps/offchain-sample-project.md +++ b/build-with-sismo-connect/run-example-apps/offchain-sample-project.md @@ -1,16 +1,16 @@ # Offchain Boilerplate -This boilerplate can be used as a base to start coding offchain applications that use Sismo Connect. It is using Next.js for frontend and backend. +This boilerplate can be used as a base to start coding offchain applications that use Sismo Connect. It is using Next.js for front ends and back ends. -You are invited to modify: +You are invited to modify the following: -* `front/src/app/page.tsx` , the code of the frontend using Sismo Connect React Button to request ZK Proofs from users. -* `src/app/api/verify/route.ts` , the backend code using Sismo Connect Typescrip library to verify ZK Proofs +* `front/src/app/page.tsx` , the code of the front end using the Sismo Connect React Button to request ZK proofs from users. +* `src/app/api/verify/route.ts` , the back-end code using the Sismo Connect TypeScript library to verify ZK proofs. This boilerplate implements a simple user authentication to a server. {% hint style="success" %} -Use the [Sismo Connect Cheatsheet](../sismo-connect-cheatsheet.md) to chose your own data requests +Use the [Sismo Connect Cheatsheet](../sismo-connect-cheatsheet.md) to choose your own data requests {% endhint %} ## Prerequisites @@ -29,7 +29,7 @@ In a first terminal: git clone https://github.com/sismo-core/sismo-connect-boilerplate-offchain.git cd sismo-connect-boilerplate-offchain -# install frontend / backend dependencies +# install front-end/back-end dependencies yarn ``` @@ -39,7 +39,7 @@ In a new terminal: ```bash # this will start your Next.js app -# the frontend is available on http://localhost:3000/ +# the front end is available on http://localhost:3000/ # it also starts a local backend yarn dev ``` @@ -49,5 +49,5 @@ After this command, you will have your local application running on [http://loca

Running app on http://localhost:3000

{% hint style="success" %} -By default, the boilerplate lets you impersonate accounts to be eligible, if you want to learn more about it you can read about the [Sismo Connect Configuration](../technical-documentation/sismo-connect-configuration.md). +By default, the boilerplate lets you impersonate accounts to be eligible for the airdrop. If you want to learn more about it, you can read about the [Sismo Connect Configuration](../technical-documentation/sismo-connect-configuration.md). {% endhint %} diff --git a/build-with-sismo-connect/run-example-apps/onchain-sample-project.md b/build-with-sismo-connect/run-example-apps/onchain-sample-project.md index fa600eb..dbc778a 100644 --- a/build-with-sismo-connect/run-example-apps/onchain-sample-project.md +++ b/build-with-sismo-connect/run-example-apps/onchain-sample-project.md @@ -1,21 +1,18 @@ # Onchain Boilerplate -This boilerplate can be used as a base to start coding onchain applications that use Sismo Connect. It is using Next.js for frontend and Foundry for smart contracts development. +This boilerplate can be used as a base to start coding onchain applications that use Sismo Connect. It is using Next.js for front end and Foundry for smart contract development. You are invited to modify: -* `front/src/app/page.tsx` , the code of the frontend using Sismo Connect React Button to request ZK Proofs -* `src/Airdrop.Sol` , the code of the smart contract using Sismo Connect Solidity Library to verify ZK Proofs\ - +* `front/src/app/page.tsx` , the code of the front end using the Sismo Connect React Button to request ZK proofs +* `src/Airdrop.Sol` , the code of the smart contract using Sismo Connect Solidity Library to verify ZK proofs {% hint style="success" %} -Use the [Sismo Connect Cheatsheet](../sismo-connect-cheatsheet.md) to chose your own data requests +Use the [Sismo Connect Cheatsheet](../sismo-connect-cheatsheet.md) to choose your own data requests {% endhint %} -This boilerplates implements SafeDrop, a Sybil-resistant airdrop from privately-aggregated data explained. - {% hint style="info" %} -Read the [full case study](https://case-studies.sismo.io) of SafeDrop or complete its [tutorial](../tutorials/tuto.md) +This boilerplate implements SafeDrop, a Sybil-resistant airdrop from privately-aggregated data. Read the [full case study](https://case-studies.sismo.io) of SafeDrop or complete its [tutorial](../tutorials/tuto.md). {% endhint %} ## Prerequisites @@ -23,7 +20,7 @@ Read the [full case study](https://case-studies.sismo.io) of SafeDrop or complet * [Node.js](https://nodejs.org/en/download/) >= 18.15.0 (Latest LTS version) * [Yarn](https://classic.yarnpkg.com/en/docs/install) * [Foundry](https://book.getfoundry.sh/) (see how to install it [here](https://book.getfoundry.sh/getting-started/installation)) -* Metamask installed in your browser +* MetaMask installed in your browser ## Installation @@ -64,14 +61,14 @@ yarn yarn dev ``` -After this command, you will have your local application running on [http://localhost:3000](http://localhost:3000) and all the contracts have been deployed on your local blockchain. +After this command, you will have your local application running on [http://localhost:3000](http://localhost:3000), and all the contracts have been deployed on your local blockchain.

Running app on http://localhost:3000

-If you wish to see the frontend code, you can go to the `front/src/app/page.tsx` file. The contract code is in the `src` folder. +If you wish to see the front-end code, you can go to the `front/src/app/page.tsx` file. The contract code is in the `src` folder. {% hint style="success" %} -By default, the boilerplate lets you impersonate accounts to be eligible, if you want to learn more about it you can read about the [Sismo Connect Configuration](../technical-documentation/sismo-connect-configuration.md). +By default, the boilerplate lets you impersonate accounts to be eligible for the airdrop. If you want to learn more about it, you can read about the [Sismo Connect Configuration](../technical-documentation/sismo-connect-configuration.md). {% endhint %} ## Important note @@ -82,7 +79,7 @@ The interaction with the fork network can become quite unstable if you stop the If so: * keep the local anvil node running, -* make sure to delete your activity tab for the fork network in Metamask by going to "Settings > Advanced > Clear activity tab data" when connected to the fork network. +* make sure to delete your activity tab for the fork network in MetaMask by going to "Settings > Advanced > Clear activity tab data" when connected to the fork network. * relaunch the anvil node and the application See [FAQ](../faq.md) for more information. diff --git a/build-with-sismo-connect/sismo-connect-cheatsheet.md b/build-with-sismo-connect/sismo-connect-cheatsheet.md index 8c45f68..7af16fa 100644 --- a/build-with-sismo-connect/sismo-connect-cheatsheet.md +++ b/build-with-sismo-connect/sismo-connect-cheatsheet.md @@ -1,30 +1,30 @@ # Sismo Connect Cheatsheet -This cheatsheet presents all types of requests you can make with Sismo Connect. It should be a great companion when developing a Sismo Connect App. +This cheatsheet presents all of the types of requests you can make with Sismo Connect. It should be a great companion when developing a Sismo Connect app. It contains: -* How to impersonate Data Sources in your dev vault when developing a Sismo Connect App - * Impersonating Data Sources enables you to be part of Data Groups and be able to make ZK Proofs claims. +* How to impersonate Data Sources in your dev Vault when developing a Sismo Connect app + * Impersonating Data Sources enables you to be part of Data Groups and generate ZK proofs. * Request a large and diversified request: - * authentication: Data Sources ownerships - * claims: Data Group memberships -* Verify them in a backend and access verified data + * Authentication: Data Source ownership + * Claims: Data Group membership +* Verify them in a back end and access verified data {% hint style="success" %} -To understand Data Groups and how to create new ones Data Groups, [visit this section](../data-groups/data-groups-and-how-to-create-them/) +Visit [this section](../data-groups/data-groups-and-creation/) to understand Data Groups and how to create them. {% endhint %}
-How the Request and Response look like 👉 https://test-request.sismo.io +What the Request and Response looks like 👉 https://test-request.sismo.io \ -SIsmo Connect Response generation (ZK Proof generation) +SIsmo Connect Response generation (ZK proof generation) -SIsmo Connect Response (with ZK Proof in it) +SIsmo Connect Response (with a ZK proof in it) @@ -32,7 +32,7 @@ SIsmo Connect Response (with ZK Proof in it)
-### Frontend: Make a Sismo Connect Request with React Button +### Front End: Make a Sismo Connect Request with React Button {% hint style="info" %} As an alternative to the React Button, you can use the [`@sismo-core/sismo-connect-client`](technical-documentation/packages/client.md) [library](technical-documentation/packages/client.md) @@ -52,7 +52,7 @@ import { const config: SismoConnectConfig = { appId: "0x32403ced4b65f2079eda77c84e7d2be6", vault: { - // For development purposes insert the Data Sources that you want to impersonate + // For development purposes, insert the Data Sources that you want to impersonate // Never use this in production impersonate: [ // EVM Data Sources @@ -100,9 +100,9 @@ return ( { authType: AuthType.TELEGRAM, userId: "875608110", isOptional: true }, ]} - // Claims = prove groump membership of a Data Source in a specific Data Group. + // Claims = prove group membership of a Data Source in a specific Data Group. // Data Groups = [{[dataSource1]: value1}, {[dataSource1]: value1}, .. {[dataSource]: value}] - // When doing so Data Source is not shared to the app. + // When doing so, the Data Source is not shared with the app. sclaims={[ { // claim on Sismo Hub GitHub Contributors Data Group membership: https://factory.sismo.io/groups-explorer?search=0xda1c3726426d5639f4c6352c2c976b87 @@ -124,16 +124,16 @@ return ( // claim on Stand with Crypto NFT Minters Data Group membership: https://factory.sismo.io/groups-explorer?search=0xfae674b6cba3ff2f8ce2114defb200b1 // Data Group members = minters of the Stand with Crypto NFT // value for each group member = number of NFT minted - // request user to prove membership in the group with value = 10 + // request the user to prove membership in the group with a value = 10 groupId: "0xfae674b6cba3ff2f8ce2114defb200b1", claimType: ClaimType.EQ, - value: 10, // dhadrin.sismo.eth minted exactly 10, eligible + value: 10, // dhadrien.sismo.eth minted exactly 10, eligible }, { // claim Gitcoin Passport Holders Data Group membership: https://factory.sismo.io/groups-explorer?search=0x1cde61966decb8600dfd0749bd371f12 // Data Group members = Gitcoin Passport Holders // value for each group member = Gitcoin Passport Score - // request user to prove membership in the group with value > 15, user can reveal more if they want + // request the user to prove membership in the group with a value > 15, the user can reveal more if they want groupId: "0x1cde61966decb8600dfd0749bd371f12", claimType: ClaimType.GTE, value: 15, // dhadrien.sismo.eth has a score of 46, eligible. Can reveal more. @@ -161,7 +161,7 @@ return ( groupId: "0xda1c3726426d5639f4c6352c2c976b87", claimType: ClaimType.GTE, value: 1, - isSelectableByUser: true, // can selectively disclose more if user wants + isSelectableByUser: true, // can selectively disclose more if the user wants isOptional: true, // can chose not to reveal }, ]} @@ -178,8 +178,6 @@ return ( )} ``` - - ### Verify the Sismo Connect Response in a simple backend
@@ -399,11 +397,11 @@ import { } from "@sismo-core/sismo-connect-server"; (async () => { - // reusing the exact same config as the frontend's + // reusing the exact same config as the front end's const sismoConnect = SismoConnect({ config }); const result: SismoConnectVerifiedResult = await sismoConnect.verify( - sismoConnectResponse, // copied from previous step or received from api call + sismoConnectResponse, // copied from the previous step or received from API call { auths, claims, @@ -415,16 +413,16 @@ import { // vault anonymous identifier = hash(vaultSecret, AppId) // ['0x225c5b67c39778b40ef2528707c9fbdfed96f31b9a50826b95c2ac40e15e4c6b'] console.log(result.getUserIds(AuthType.GITHUB)); - // [ '35774097' ] github id of @dhadrien + // [ '35774097' ] GitHub id of @dhadrien console.log(result.getUserIds(AuthType.TWITTER)); - // [ '2390703980' ] twitter id of @dhadrien_ + // [ '2390703980' ] Twitter id of @dhadrien_ console.log(result.getUserIds(AuthType.EVM_ACCOUNT)); // [ // '0x8ab1760889f26cbbf33a75fd2cf1696bfccdc9e6', // dhadrien.sismo.eth // '0xa4c94a6091545e40fc9c3e0982aec8942e282f38' // requested wallet auth // ] console.log(result.getUserIds(AuthType.TELEGRAM)); - // [ '875608110' ] // telegram id of @dhadrien + // [ '875608110' ] // Telegram id of @dhadrien })() ``` @@ -460,8 +458,8 @@ contract MyContract is SismoConnect { {} function verifySismoConnectResponse(bytes memory response) public { - // Recreate the request made in the fontend to verify the proof - // We will verify the Sismo Connect Response containing the ZK Proofs against it + // Recreate the request made in the front end to verify the proof + // We will verify the Sismo Connect Response containing the ZK proofs against it AuthRequest[] memory auths = new AuthRequest[](6); auths[0] = _authRequestBuilder.build({authType: AuthType.VAULT}); auths[1] = _authRequestBuilder.build({authType: AuthType.EVM_ACCOUNT}); @@ -535,7 +533,7 @@ contract MyContract is SismoConnect { uint256[] memory evmAccountIds = SismoConnectHelper.getUserIds(result, AuthType.EVM_ACCOUNT); console.log("Vault ID: %s", vaultId); - console.log("Github ID: %s", githubId); + console.log("GitHub ID: %s", githubId); console.log("Telegram ID: %s", telegramId); console.log("First EVM Account ID: %s", evmAccountIds[0]); console.log("Second EVM Account ID: %s", evmAccountIds[1]); @@ -543,4 +541,4 @@ contract MyContract is SismoConnect { } ``` -Refer to the [Sismo Connect Solidity Library](technical-documentation/packages/solidity.md), the [onchain app boilerplate](run-example-apps/onchain-sample-project.md) or the [Onchain Tutorial](tutorials/tuto.md) for more information. +Refer to the [Sismo Connect Solidity Library](technical-documentation/packages/solidity.md), the [onchain app boilerplate](run-example-apps/onchain-sample-project.md) or the [onchain tutorial](tutorials/tuto.md) for more information. diff --git a/build-with-sismo-connect/technical-documentation/README.md b/build-with-sismo-connect/technical-documentation/README.md index d2bddc3..44d111c 100644 --- a/build-with-sismo-connect/technical-documentation/README.md +++ b/build-with-sismo-connect/technical-documentation/README.md @@ -1,10 +1,6 @@ ---- -description: The packages for Sismo Connect. ---- - # Technical Documentation -[Sismo Connect](../../#sismo-connect-the-crypto-native-sso) is a crypto-native single sign-on method (SSO) for applications—whether on web2 or web3. Integration is simple with just a few lines of code: import the front-end package or React button for data requests, and verify proofs using Sismo Connect Solidity library in your smart contract OR server package in your backend. Once integrated, applications can **request** private and granular data, while users can **authenticate** and **selectively disclose** their personal data with the power of zero-knowledge proofs (ZKPs). +[Sismo Connect](../../#sismo-connect-the-crypto-native-sso) is a crypto-native single sign-on method (SSO) for applications—whether on web2 or web3. Integration is simple with just a few lines of code: import the front-end package or React button for data requests, and verify proofs using the Sismo Connect Solidity library in your smart contract OR server package in your back end. Once integrated, applications can **request** private and granular data, while users can **authenticate** and **selectively disclose** their personal data with the power of zero-knowledge proofs (ZKPs). {% hint style="warning" %} In order to use Sismo Connect, you will need to have an `appId` registered in the [Sismo Factory](https://factory.sismo.io/). [Here is a tutorial](../tutorials/create-a-sismo-connect-app.md). @@ -16,10 +12,10 @@ In the schema below, you can observe how Sismo Connect functions with both **onc ### Sismo Connect Flow Walkthrough -1. The Sismo Connect App requests some proofs to its users by integrating the Sismo Connect React button from [`@sismo-core/sismo-connect-react`](https://github.com/sismo-core/sismo-connect-packages/tree/main/packages/sismo-connect-react) or using the [`@sismo-core/sismo-connect-client`](https://github.com/sismo-core/sismo-connect-packages/tree/main/packages/sismo-connect-client)package. Users are redirected to their Sismo Vault to generate proofs. -2. After successful proofs generation, users are redirected back to the Sismo Connect App with their generated proofs. The app frontend can either call a smart contract or its backend to verify the proofs. +1. The Sismo Connect app requests proofs from its users by integrating the Sismo Connect React button from [`@sismo-core/sismo-connect-react`](https://github.com/sismo-core/sismo-connect-packages/tree/main/packages/sismo-connect-react) or using the [`@sismo-core/sismo-connect-client`](https://github.com/sismo-core/sismo-connect-packages/tree/main/packages/sismo-connect-client)package. Users are redirected to their Data Vault to generate proofs. +2. After successful proof generation, users are redirected back to the Sismo Connect app with their generated proofs. The app's front end can either call a smart contract or its back end to verify the proofs. 3. The proof is received by the smart contract OR the backend and verified. -4. Some logic is then executed if proofs are valid, successfully ending the Sismo Connect flow. +4. Certain logic is then executed if proofs are valid, successfully ending the Sismo Connect flow. {% hint style="info" %} Learn how to integrate Sismo Connect via these [**tutorials**](../tutorials/) or gain more in-depth knowledge of Sismo Connect by learning what is a [**Sismo Connect Configuration**](sismo-connect-configuration.md), an [**Auth**](auths.md), a [**Claim**](claims.md) and a [**Signature**](signature.md). @@ -27,9 +23,9 @@ Learn how to integrate Sismo Connect via these [**tutorials**](../tutorials/) or ### **Packages** -Here are the different GitHub links to Sismo Connect packages, you can find their documentation [**here**](packages/). +Here are the different GitHub links to Sismo Connect packages. You can find their documentation [**here**](packages/). -* [`@sismo-core/sismo-connect-client`](https://github.com/sismo-core/sismo-connect-packages/tree/main/packages/sismo-connect-client): the frontend [package](packages/client.md) to easily request ZKPs from users in a privacy-preserving manner. -* [`@sismo-core/sismo-connect-react`](https://github.com/sismo-core/sismo-connect-packages/tree/main/packages/sismo-connect-react): the React frontend [package](packages/react.md) to easily integrate the sismoConnectButton and sismo-connect-client in your React app. -* [`@sismo-core/sismo-connect-server`](https://github.com/sismo-core/sismo-connect-packages/tree/main/packages/sismo-connect-server): the backend [package](packages/server.md) to easily verify ZKPs offchain. +* [`@sismo-core/sismo-connect-client`](https://github.com/sismo-core/sismo-connect-packages/tree/main/packages/sismo-connect-client): the front-end [package](packages/client.md) to easily request ZKPs from users in a privacy-preserving manner. +* [`@sismo-core/sismo-connect-react`](https://github.com/sismo-core/sismo-connect-packages/tree/main/packages/sismo-connect-react): the React front-end [package](packages/react.md) to easily integrate the sismoConnectButton and sismo-connect-client in your React app. +* [`@sismo-core/sismo-connect-server`](https://github.com/sismo-core/sismo-connect-packages/tree/main/packages/sismo-connect-server): the back-end [package](packages/server.md) to easily verify ZKPs offchain. * [`@sismo-core/sismo-connect-solidity`](https://github.com/sismo-core/sismo-connect-packages/tree/main/packages/sismo-connect-solidity) : the [Solidity Library](packages/solidity.md) to easily verify ZKPs onchain. diff --git a/build-with-sismo-connect/technical-documentation/auths.md b/build-with-sismo-connect/technical-documentation/auths.md index 84e16fc..3e9b64f 100644 --- a/build-with-sismo-connect/technical-documentation/auths.md +++ b/build-with-sismo-connect/technical-documentation/auths.md @@ -7,8 +7,8 @@ Sismo Connect can be used to authenticate a user from multiple sources, either f The `AuthRequest` is an object with the following properties: * `AuthType` (required): defines the type of authentication required. The following authType are currently supported: - * `VAULT`: Sismo Connect returns the user's vaultId for the application the requested it. It is a deterministic anonymous identifier (hash(userVaultSecret, AppId, ..))\ - More information about Vault Identifiers [here](vault-and-proof-identifiers.md). + * `VAULT`: Sismo Connect returns the user's vaultId for the application that requested it. It is a deterministic anonymous identifier (hash(userVaultSecret, AppId, ..))\ + See more information about Vault Identifiers [here](vault-and-proof-identifiers.md). * `GITHUB`: Sismo Connect returns the user's GitHub account id. * `TWITTER` Sismo Connect returns the user's Twitter account id. * `EVM_ACCOUNT`: Sismo Connect returns the user's Ethereum address. @@ -35,14 +35,12 @@ type AuthRequest = { ## Integrations -Authentication requests are made in the front end using either the [`sismo-connect-react` package](packages/react.md) or the [`sismo-connect-client` package](packages/client.md). - -Requests are then verified either in a back end using the [`sismo-connect-server` package](packages/server.md) or in a smart contract using the [`sismo-connect-solidity` package](packages/solidity.md). +Authentication requests are made in the front end using either the [`sismo-connect-react` package](packages/react.md) or the [`sismo-connect-client` package](packages/client.md). Requests are then verified either in a back end using the [`sismo-connect-server` package](packages/server.md) or in a smart contract using the [`sismo-connect-solidity` package](packages/solidity.md). ### Making an AuthRequest - Front-end integration {% hint style="info" %} -Making an `AuthRequest` is only possible in the front end as the request redirects users to the Sismo Data Vault app where users can generate a zero-knowledge proof. +Making an `AuthRequest` is only possible in the front end as the request redirects users to the Sismo Data Vault app, where users can generate a zero-knowledge proof. {% endhint %} {% tabs %} @@ -110,10 +108,10 @@ import { SismoConnectButton, AuthType, SismoConnectClientConfig, SismoConnectRes {% endtab %} {% tab title="React Hook" %} -The `useSismoConnect` hook is available from the [sismo-connect-react package](packages/react.md). It is a wrapper of the [sismo-connect-client package](packages/client.md). The `useSismoConnect` hook exposes the `sismoConnect` variable. +The `useSismoConnect` hook is available from the [sismo-connect-react package](packages/react.md). It is a wrapper of the [sismo-connect-client package](packages/client.md). The `useSismoConnect` hook exposes the `sismoConnect` variable. * One or multiple AuthRequests can be made using the `sismoConnect.request()` method available on the `sismoConnect` variable. -* Response could be received through either: +* The response could be received through either: 1. the `sismoConnect.getReponse()` method for offchain verification or, 2. the `sismoConnect.getResponseBytes()` method for onchain verification. @@ -176,11 +174,11 @@ if(response || responseBytes) { {% endcode %} {% endtab %} -{% tab title="Typescript" %} +{% tab title="TypeScript" %} The [`sismo-connect-client` package](packages/client.md) exposes a `SismoConnect` variable. * One or multiple AuthRequests can be made using the `sismoConnect.request()` method available on a `SismoConnect` instance. -* Response could be received through either: +* The response could be received through either: 1. the `sismoConnect.getReponse()` method for offchain verification or, 2. the `sismoConnect.getResponseBytes()` method for onchain verification. @@ -245,9 +243,7 @@ if(response || responseBytes) { ### Verifying an AuthRequest -{% hint style="info" %} -Once a user has generated the proof on the Sismo Data Vault App, your application must verify it. This can be made either offchain in your back end or onchain in your smart contract. -{% endhint %} +Once a user has generated a ZKP on the Data Vault app, your application must verify it. This can be achieved in onchain smart contracts or offchain back ends. {% tabs %} {% tab title="offchain verification - Node.js" %} @@ -321,11 +317,11 @@ async function verifyResponse(sismoConnectResponse: SismoConnectResponse) { {% endtab %} {% tab title="onchain verification - Solidity" %} -The [`sismo-connect-solidity` package](packages/solidity.md) exposes a Sismo Connect Library which can be inherited by your contract either using Foundry or Hardhat. +The [`sismo-connect-solidity` package](packages/solidity.md) exposes a Sismo Connect Library, which can be inherited by your contract either using Foundry or Hardhat. The Sismo Connect Library exposes: -* a `verify()` function which allows you to verify a proof generated by the [Sismo Vault app](broken-reference) with respect to some requests directly in your contract. The verify() function takes an object containing: +* a `verify()` function, which allows you to verify a proof generated by the [Sismo Vault app](broken-reference) with respect to some requests directly in your contract. The verify() function takes an object containing: 1. a `responseBytes` send from the front end, 2. an `auth` or `auths` corresponding to the authentification request made in the front end. * a `buildAuth()` helper to recreate the `AuthRequest` made in the front-end diff --git a/build-with-sismo-connect/technical-documentation/claims.md b/build-with-sismo-connect/technical-documentation/claims.md index 7911f02..cba4131 100644 --- a/build-with-sismo-connect/technical-documentation/claims.md +++ b/build-with-sismo-connect/technical-documentation/claims.md @@ -1,6 +1,6 @@ # Claims -Sismo Connect can be used to request users for zero-knowledge proofs attesting group memberships. +Sismo Connect can be used to request zero-knowledge proofs (ZKPs) that attest group membership from users. ## Type definitions @@ -11,7 +11,7 @@ The `ClaimRequest` holds all the information needed to generate such a proof. It * `claimType` (optional): by default `ClaimType.GTE`. Defines the type of group membership required. The following claim types are currently supported: * `ClaimType.GTE`: the user must prove that they own an account with at least the requested value. * `ClaimType.EQ`: the user must prove that he owns an account with the exact requested value. -* `groupTimestamp` (optional): by default set to “latest”. Groups are composed of snapshots generated either once, daily, or weekly. Each Group Snapshot generated has a timestamp associated with them. By default, the selected group is the latest Group Snapshot generated. But you are free to select a Group Snapshot with a different timestamp than the latest generated one. +* `groupTimestamp` (optional): set to “latest” by default. Groups are composed of snapshots generated either once, daily, or weekly. Each Group Snapshot generated has a timestamp associated with them. By default, the selected group is the latest Group Snapshot generated. But you are free to select a Group Snapshot with a different timestamp than the latest generated one. * `isOptional`(optional): by default set to `false`. If set to `true` the user can optionally prove their group membership. * `isSelectableByUser`(optional): by default set to `false` and only available for `ClaimType.GTE`. This allows users to selectively choose the value used to generate the proof. @@ -44,7 +44,7 @@ Requests are then verified either in a backend using the [`sismo-connect-server` ### Making a ClaimRequest - Front-end integration {% hint style="info" %} -Making an `ClaimRequest` is only possible in the front end as the request redirects users to the Sismo Vault app where users can generate a zero-knowledge proof. +Making an `ClaimRequest` is only possible in the front end as the request redirects users to the Sismo Vault app, where users can generate a zero-knowledge proof. {% endhint %} {% tabs %} @@ -248,7 +248,7 @@ if(response || responseBytes) { ### Verifying a ClaimRequest {% hint style="info" %} -Once a user has generated the proof on the Data Vault App, your application must verify it. This can be made either offchain in your backend or onchain in your smart contract.The [`sismo-connect-server` package](packages/server.md) exposes a `SismoConnect` variable. +Once a user has generated the proof on the Data Vault app, your application must verify it. This can be made either offchain in your backend or onchain in your smart contract. The [`sismo-connect-server` package](packages/server.md) exposes a `SismoConnect` variable. {% endhint %} {% tabs %} @@ -308,14 +308,14 @@ async function verifyResponse(sismoConnectResponse: SismoConnectResponse) { {% endtab %} {% tab title="Onchain verification - Solidity" %} -The [`sismo-connect-solidity` package](packages/solidity.md) exposes a Sismo Connect Library which can be inherited by your contract either using Foundry or Hardhat. +The [`sismo-connect-solidity` package](packages/solidity.md) exposes a Sismo Connect Library, which can be inherited by your contract either using Foundry or Hardhat. The Sismo Connect Library exposes: -* a `verify()` function which allows you to verify a proof generated by the [Sismo Vault app](broken-reference) with respect to some requests directly in your contract. The verify() function takes an object containing: +* a `verify()` function, which allows you to verify a proof generated by the [Sismo Vault app](broken-reference) with respect to some requests directly in your contract. The verify() function takes an object containing: 1. a `responseBytes` send from the front end, 2. an `claim` or `claims` corresponding to the claim request made in the front end. -* a `buildClaim()` helper to recreate the `ClaimRequest` made in the front-end +* a `buildClaim()` helper to recreate the `ClaimRequest` made in the front end **One ClaimRequest - code example** diff --git a/build-with-sismo-connect/technical-documentation/packages/README.md b/build-with-sismo-connect/technical-documentation/packages/README.md index d1a6c7e..f46716b 100644 --- a/build-with-sismo-connect/technical-documentation/packages/README.md +++ b/build-with-sismo-connect/technical-documentation/packages/README.md @@ -1,10 +1,8 @@ # Packages -Sismo Connect integration is simple with just a few lines of code: import the front-end package or React button for data requests, and verify proofs using Sismo Connect Solidity library in your smart contract OR server package in your backend. You can find the GitHub links of the packages below. +Sismo Connect integration is simple with just a few lines of code: import the front-end package or React button for data requests, and verify proofs using the Sismo Connect Solidity library in your smart contract OR server package in your back end. You can find the GitHub links of the packages below. -* [`@sismo-core/sismo-connect-client`](https://github.com/sismo-core/sismo-connect-packages/tree/main/packages/sismo-connect-client): the frontend [package](client.md) to easily request ZKPs from users in a privacy-preserving manner. -* [`@sismo-core/sismo-connect-react`](https://github.com/sismo-core/sismo-connect-packages/tree/main/packages/sismo-connect-react): the React frontend [package](react.md) to easily integrate the sismoConnectButton and sismo-connect-client in your React app. -* [`@sismo-core/sismo-connect-server`](https://github.com/sismo-core/sismo-connect-packages/tree/main/packages/sismo-connect-server): the backend [package](server.md) to easily verify ZKPs offchain. +* [`@sismo-core/sismo-connect-client`](https://github.com/sismo-core/sismo-connect-packages/tree/main/packages/sismo-connect-client): the front-end [package](client.md) to easily request ZKPs from users in a privacy-preserving manner. +* [`@sismo-core/sismo-connect-react`](https://github.com/sismo-core/sismo-connect-packages/tree/main/packages/sismo-connect-react): the React front-end [package](react.md) to easily integrate the sismoConnectButton and sismo-connect-client in your React app. +* [`@sismo-core/sismo-connect-server`](https://github.com/sismo-core/sismo-connect-packages/tree/main/packages/sismo-connect-server): the back-end [package](server.md) to easily verify ZKPs offchain. * [`@sismo-core/sismo-connect-solidity`](https://github.com/sismo-core/sismo-connect-packages/tree/main/packages/sismo-connect-solidity) : the [Solidity Library](solidity.md) to easily verify ZKPs onchain. - -If you wish to learn more about diff --git a/build-with-sismo-connect/technical-documentation/packages/client.md b/build-with-sismo-connect/technical-documentation/packages/client.md index 7fe3249..ceb0efc 100644 --- a/build-with-sismo-connect/technical-documentation/packages/client.md +++ b/build-with-sismo-connect/technical-documentation/packages/client.md @@ -4,11 +4,11 @@ description: Request proofs from your user # Sismo Connect Client: Request -The [Sismo Connect](broken-reference) Client is a frontend package built on top of the [Data Vault](../../../#data-vault-aggregate-your-identity) app (the prover) to easily request proofs from your users with [AuthRequests](../auths.md), [ClaimRequests](../claims.md) and [SignatureRequests](../signature.md). +The [Sismo Connect](broken-reference) Client is a front-end package built on top of the [Data Vault](../../../#data-vault-aggregate-your-identity) app (the prover) to easily request proofs from your users with [AuthRequests](../auths.md), [ClaimRequests](../claims.md) and [SignatureRequests](../signature.md). ## Installation -Install the Sismo Connect Client package in your frontend with `npm` or `yarn`: +Install the Sismo Connect Client package in your front end with `npm` or `yarn`: ```bash # with npm @@ -23,11 +23,11 @@ Make sure to have at least v18.15.0 as Node version. You can encounter issues wi ## Example Usage -**Here is an example of a customized usage of the request function:** +Here is an example of a customized usage of the request function: You want to create an NFT airdrop for **holders of a Nouns DAO NFT** owning a **Gitcoin Passport** and a **Twitter account**. -So you want your users to prove that they own a **Nouns DAO NFT**. But in order to make your airdrop more Sybil-resistant you will require them to also prove a **Gitcoin Passport ownership with a passport value greater or equal to 15** and a **Twitter account ownership**. +So you want your users to prove that they own a **Nouns DAO NFT**. In order to make your airdrop more Sybil-resistant, you will require them to also prove a **Gitcoin Passport ownership with a passport value greater or equal to 15** and a **Twitter account ownership**. These proofs should be made for the service named **"sismo-edition".** When the proofs are generated, you want your users to be redirected to the claim page of your website at the path **"https://my-nft-drop.xyz/sismo-edition/claim-nft"**. @@ -84,7 +84,7 @@ sismoConnect.request({ {% hint style="info" %} -Namespace is highly interesting when you want your users to generate proofs for different services in an app. You can see more information about how to use it in the [Sismo Connect Server package documentation](server.md). +A namespace is useful when you want your users to generate proofs for different services in an app. You can see more information about how to use it in the [Sismo Connect Server package documentation](server.md). {% endhint %} ### `getResponse()` @@ -93,7 +93,7 @@ Namespace is highly interesting when you want your users to generate proofs for function getResponse(): SismoConnectResponse | null ``` -The `getResponse` function returns the [`SismoConnectResponse`](client.md#sismoconnectresponse) object containing the proofs generated by your user after coming back from Sismo Vault App. Proofs can be sent to your backend and verified thanks to the [`@sismo-core/sismo-connect-server`](https://github.com/sismo-core/sismo-connect-packages/tree/main/packages/sismo-connect-server) package OR sent to your contract that uses the [Sismo Connect Solidity library](solidity.md) to verify. +The `getResponse` function returns the [`SismoConnectResponse`](client.md#sismoconnectresponse) object containing the proofs generated by your user after coming back from the Data Vault app. Proofs can be sent to your back end and verified thanks to the [`@sismo-core/sismo-connect-server`](https://github.com/sismo-core/sismo-connect-packages/tree/main/packages/sismo-connect-server) package OR sent to your contract that uses the [Sismo Connect Solidity library](solidity.md) to verify. #### `getResponseBytes()` diff --git a/build-with-sismo-connect/technical-documentation/packages/server.md b/build-with-sismo-connect/technical-documentation/packages/server.md index 87df909..ccd8f1f 100644 --- a/build-with-sismo-connect/technical-documentation/packages/server.md +++ b/build-with-sismo-connect/technical-documentation/packages/server.md @@ -4,7 +4,9 @@ description: Verify proofs from your users # Sismo Connect Server: Verify Offchain -The Sismo Connect Server is a backend package built on top of the [Hydra-S2 Verifier](../../../how-sismo-works/core-components/proving-schemes/hydra-s2.md) to easily verify proofs from your users off-chain. +The Sismo Connect Server is a back-end package built on top of the [Hydra-S2 Verifier](../../../how-sismo-works/core-components/proving-schemes/hydra-s2.md) to easily verify proofs from your users offchain. + +The Sismo Connect Server is

Sismo Connect offchain Flow

@@ -27,7 +29,7 @@ Make sure to have at least v18.15.0 as Node version. You can encounter issues wi ### Configuration -The first step for integrating Sismo Connect in your backend is to create a `sismoConnectServerConfig`. This config will require an `appId` and can be customized with optional fields. You can go to the [Sismo Factory](https://factory.sismo.io/apps-explorer) to register an appId ([here is a tutorial](../../tutorials/create-a-sismo-connect-app.md)). +The first step for integrating Sismo Connect in your back end is to create a `sismoConnectServerConfig`. This config will require an `appId` and can be customized with optional fields. You can go to the [Sismo Factory](https://factory.sismo.io/apps-explorer) to register an appId ([here is a tutorial](../../tutorials/create-a-sismo-connect-app.md)). This `config` is then used to create a `SismoConnect` instance that will be used to verify proofs. @@ -44,7 +46,7 @@ const sismoConnect = SismoConnect({ config }); ### Verify proofs from your users -Proofs need to be sent from your frontend to your backend with a `SismoConnectResponse`. The `verify` function takes as inputs the `SismoConnectResponse` but also requests to verify that proofs held in the response are cryptographically valid with respect to these requests. +Proofs need to be sent from your front end to your back end with a `SismoConnectResponse`. The `verify` function takes the `SismoConnectResponse`as inputs but also requests to verify that proofs held in the response are cryptographically valid with respect to these requests. ```typescript import { SismoConnectVerifiedResult, AuthType } from "@sismo-core/sismo-connect-server"; diff --git a/build-with-sismo-connect/technical-documentation/packages/solidity.md b/build-with-sismo-connect/technical-documentation/packages/solidity.md index c852521..2169ded 100644 --- a/build-with-sismo-connect/technical-documentation/packages/solidity.md +++ b/build-with-sismo-connect/technical-documentation/packages/solidity.md @@ -22,7 +22,7 @@ You can find the Solidity Library GitHub repository [here](https://github.com/si Make sure to have [Foundry](https://book.getfoundry.sh/getting-started/installation) installed. {% endhint %} -Install the forge dependency: +Install the Forge dependency: ```bash foundryup @@ -37,7 +37,7 @@ echo $'sismo-connect-solidity/=lib/sismo-connect-packages/packages/sismo-connect #### Import the library -In your solidity file: +In your Solidity file: ```solidity import "sismo-connect-solidity/SismoLib.sol"; @@ -79,7 +79,7 @@ contract MyContract is SismoConnect { // inherits from Sismo Connect library You will then need to create some request objects to check that the proofs from your users are valid with respect to these requests. -Finally, use the `verify()` function to verify the proof stored in `sismoConnectResponse` with respect to some requests. For example, here we verify that the proof in the `sismoConnectResponse` is cryptographically valid for a certain `ClaimRequest`, `AuthRequests` and `SignatureRequest`. +Finally, use the `verify()` function to verify the proof stored in `sismoConnectResponse` with respect to some requests. For example, below we verify that the proof in the `sismoConnectResponse` is cryptographically valid for a certain `ClaimRequest`, `AuthRequests` and `SignatureRequest`. ```solidity function doSomethingUsingSismoConnect(bytes memory sismoConnectResponse) public { @@ -105,7 +105,7 @@ function doSomethingUsingSismoConnect(bytes memory sismoConnectResponse) public } ``` -If your proof is valid, the contract will continue its execution, otherwise it will reject an error. +If your proof is valid, the contract will continue its execution, otherwise, it will produce an error. ## Documentation @@ -125,12 +125,12 @@ function verify( The function can take these 5 arguments: -* `responseBytes` _(required)_: The response sent back by the [Data Vault](broken-reference). It contains the `appId`, the `namespace`, the `version` and the proofs corresponding to the requests made in the frontend. +* `responseBytes` _(required)_: The response sent back by the [Data Vault](broken-reference). It contains the `appId`, the `namespace`, the `version` and the proofs corresponding to the requests made in the front end. -The function needs to verify that the proof is cryptographically valid but also that it has been well generated from the requests specified in the frontend. To do this, we also need to setup the same requests in the contract: +The function needs to verify that the proof is cryptographically valid but also that it has been well generated from the requests specified in the front end. To do this, we also need to set up the same requests in the contract: -* `claim`: The object that holds all the information needed to request a proof of group ownership. -* `auth`: The object that holds all the information needed to request a proof of account membership. +* `claim`: The object that holds all the information needed to request a proof of group membership. +* `auth`: The object that holds all the information needed to request a proof of account ownership. * `signature`: It contains the message that the user should sign. * `namespace`: The namespace of the application that the contract uses. @@ -138,9 +138,9 @@ And it returns a `SismoConnectVerifiedResult`. ### `responseBytes` _(required)_ -The `responseBytes` is the encoded version of the `sismoConnectResponse`, the response that the frontend received from the Data Vault App. +The `responseBytes` is the encoded version of the `sismoConnectResponse`, the response that the front end receives from the Data Vault app. -Once decoded here is the type of the `SismoConnectResponse`: +Once decoded, here is the type of the `SismoConnectResponse`: ```solidity struct SismoConnectResponse { @@ -160,7 +160,7 @@ struct SismoConnectResponse { } ``` -**`proofs[]`** : The array that contains all the sismoConnectProofs the frontend provides to the contract.\ +**`proofs[]`** : The array that contains all the sismoConnectProofs the front end provides to the contract.\ A sismoConnectProof contains several objects: ```solidity @@ -225,9 +225,9 @@ enum AuthType { } ``` -**`provingScheme`** : The proving scheme that the Data Vault app used to generate the proof and by the verify to verify the proof. +**`provingScheme`** : The proving scheme that the Data Vault app uses to generate and verify the proof. -**`proofData`** : The proof content. +**`proofData`** : The proof's content. **`extraData`** : other data that can be used in the future by other proving schemes. Currently not used in the current proving scheme use: the [Hydra-S2](../../../how-sismo-works/core-components/proving-schemes/hydra-s2.md). diff --git a/build-with-sismo-connect/technical-documentation/signature.md b/build-with-sismo-connect/technical-documentation/signature.md index 944d479..32f58f3 100644 --- a/build-with-sismo-connect/technical-documentation/signature.md +++ b/build-with-sismo-connect/technical-documentation/signature.md @@ -1,6 +1,6 @@ # Signature -A `Signature` is a specific message embedded in a generated proof that will be checked when verifying the proof. It can be requested to the Data Vault thanks to a `SignatureRequest` . +A `Signature` is a specific message embedded in a generated proof that will be checked when verifying the proof. It can be requested from the Data Vault via a `SignatureRequest.`
@@ -38,7 +38,7 @@ type SignatureRequest = { The proof with the requested signature is then verified either in a backend using the [`sismo-connect-server` package](packages/server.md) or in a smart contract using the [`sismo-connect-solidity` package](packages/solidity.md). {% hint style="success" %} -If you are verifying your proofs in a smart contract, you will need to encode your singature with some ABI encoder like [Viem](https://viem.sh/docs/abi/encodeAbiParameters.html) or [EthersJS](https://docs.ethers.org/v5/api/utils/abi/coder/). +If you are verifying your proofs in a smart contract, you will need to encode your signature with some ABI encoder like [Viem](https://viem.sh/docs/abi/encodeAbiParameters.html) or [EthersJS](https://docs.ethers.org/v5/api/utils/abi/coder/). {% endhint %} ### Making a SignatureRequest - Front-end integration @@ -84,7 +84,7 @@ import { SismoConnectButton, SismoConnectClientConfig, SismoConnectResponse, Aut {% endtab %} {% tab title="React Hook" %} -The `useSismoConnect` hook is available from the [sismo-connect-react package](packages/react.md). It is a wrapper of the [sismo-connect-client package](packages/client.md). The `useSismoConnect` hook exposes the `sismoConnect` variable. +The `useSismoConnect` hook is available from the [sismo-connect-react package](packages/react.md). It is a wrapper of the [sismo-connect-client package](packages/client.md). The `useSismoConnect` hook exposes the `sismoConnect` variable. * One or multiple claim requests can be made using the `sismoConnect.request()` method available on the `sismoConnect` variable. * Responses could be received through either: @@ -122,7 +122,7 @@ if(response || responseBytes) { {% endcode %} {% endtab %} -{% tab title="Typescript" %} +{% tab title="TypeScript" %} The [`sismo-connect-client` package](packages/client.md) exposes a `SismoConnect` variable. * One or multiple ClaimRequests can be made using the `sismoConnect.request()` method available on a `SismoConnect` instance. @@ -165,7 +165,7 @@ if(response || responseBytes) { ### Verifying a SignatureRequest {% hint style="info" %} -Once a user has generated the proof on the Sismo Data Vault App, your application must verify it. This can be made either offchain in you backend or onchain in your smart contract. The [`sismo-connect-server` package](packages/server.md) exposes a `SismoConnect` variable. +Once a user has generated the proof on the Sismo Data Vault App, your application must verify it. This can be made either offchain in your back end or onchain in your smart contract. The [`sismo-connect-server` package](packages/server.md) exposes a `SismoConnect` variable. {% endhint %} {% tabs %} @@ -199,11 +199,11 @@ async function verifyResponse(sismoConnectResponse: SismoConnectResponse) { {% endtab %} {% tab title="Onchain verification - Solidity" %} -The [`sismo-connect-solidity` package](packages/solidity.md) exposes a Sismo Connect Library which can be inherited by your contract either using Foundry or Hardhat. +The [`sismo-connect-solidity` package](packages/solidity.md) exposes a Sismo Connect Library, which can be inherited by your contract either using Foundry or Hardhat. The Sismo Connect Library exposes: -* a `verify()` function which allows you to verify a proof generated by the [Sismo Vault app](broken-reference) with respect to some requests directly in your contract. The verify() function takes an object containing: +* a `verify()` function, which allows you to verify a proof generated by the [Sismo Vault app](broken-reference) with respect to some requests directly in your contract. The verify() function takes an object containing: 1. a `responseBytes` send from the front end, 2. a signature corresponding to the signature request made in the front end, 3. an auth or a claim. diff --git a/build-with-sismo-connect/technical-documentation/sismo-connect-configuration.md b/build-with-sismo-connect/technical-documentation/sismo-connect-configuration.md index 1956cff..f3c7c98 100644 --- a/build-with-sismo-connect/technical-documentation/sismo-connect-configuration.md +++ b/build-with-sismo-connect/technical-documentation/sismo-connect-configuration.md @@ -1,14 +1,14 @@ # Sismo Connect Configuration -The `SismoConnectConfiguration` is the first object to understand when starting Sismo Connect integration in your application. Its main feature is to reference the `appId` you got from the **Sismo Factory** [when you created a new Sismo Connect App](../tutorials/create-a-sismo-connect-app.md), it will then enable you to request proofs from your users and verify them. +The `SismoConnectConfiguration` is the first object to understand when starting Sismo Connect integration in your application. Its main feature is to reference the `appId` you got from the **Sismo Factory** [when you created a new Sismo Connect app](../tutorials/create-a-sismo-connect-app.md). It will then enable you to request proofs from your users and verify them. ## Type definitions The `SismoConnectConfiguration` is an object with the following properties: * `appId` (required): the Sismo Connect application identifier that you have created on the Sismo Factory. -* `vault.impersonate` (optional): by default set to `null`. The list of Data Source that you want to impersonate, they wll be automatically be added to your developer vault. -* `displayRawResponse` (optional): by default set to `false`. If set to `true`, the Sismo Data Vault App will display the proof generated in a modal and will not redirect to your application once the proof is generated. It can be useful in development. +* `vault.impersonate` (optional): by default set to `null`. The list of Data Sources that you want to impersonate. They will be automatically added to your developer Vault. +* `displayRawResponse` (optional): by default set to `false`. If set to `true`, the Sismo Data Vault app will display the proof generated in a modal and will not redirect to your application once the proof is generated. It can be useful in development. * `sismoApiUrl` (optional): API endpoint to fetch group information. * `vaultAppBaseUrl` (optional): by default set to `https://vault-beta.sismo.io/`. @@ -34,7 +34,7 @@ As far as the configurations are the same in the client and server packages, **w Requests are made in the front end using either the [`sismo-connect-react` package](packages/react.md) or the [`sismo-connect-client` package](packages/client.md). -Requests are then verified either in a backend using the [`sismo-connect-server` package](packages/server.md) or in a smart contract using the [`sismo-connect-solidity` package](packages/solidity.md). +Requests are then verified either in a back end using the [`sismo-connect-server` package](packages/server.md) or in a smart contract using the [`sismo-connect-solidity` package](packages/solidity.md). {% tabs %} {% tab title="React.js" %} @@ -53,7 +53,7 @@ const config: SismoConnectConfig = { config={config} // Sismo Connect Request Data - // request proof of Data Sources ownership (e.g EVM, GitHub, twitter or telegram) + // request proof of Data Sources ownership (e.g EVM, GitHub, Twitter or Telegram) auths={[{ authType: AuthType.GITHUB }]} // request proof of Data Group memberships of source // (e.g part of NFT owners, Dao Participants, GitHub commiters) @@ -69,7 +69,7 @@ const config: SismoConnectConfig = { {% endtab %} {% tab title="Typescript (client)" %} -In your frontend application, the most basic Sismo Connect Config looks like this: +In your front-end application, the most basic Sismo Connect Config looks like this: ```typescript import { SismoConnectConfig, SismoConnect } from "@sismo-core/sismo-connect-client"; @@ -99,7 +99,7 @@ const sismoConnect = SismoConnect({config}); {% endtab %} {% tab title="Solidity (foundry)" %} -In your Smart Contract, the most basic Sismo Connect Config looks like this: +In your smart contract, the most basic Sismo Connect Config looks like this: ```solidity import "sismo-connect-solidity/SismoLib.sol"; // <--- add a Sismo Connect import @@ -117,7 +117,7 @@ contract MyContract is SismoConnect { ## Impersonating accounts in development -Impersonating accounts allows you to be redirected to a Sismo Data Vault App with fake accounts imported that you defined in the `SismoConnectConfig` object. The impersonated Vault only exists in your browser memory. It does not affect your personal Data Vault. +Impersonating accounts allows you to be redirected to a Sismo Data Vault app with fake accounts imported that you defined in the `SismoConnectConfig` object. The impersonated Vault only exists in your browser memory. It does not affect your personal Data Vault. It is useful in development to test your application flow. You are able to generate a proof based on a Sismo Connect request for which you would not be eligible otherwise. @@ -152,7 +152,7 @@ const config: SismoConnectConfig = { config={config} // Sismo Connect Request - // request proof of Data Sources ownership (e.g EVM, GitHub, twitter or telegram) + // request proof of Data Sources ownership (e.g EVM, GitHub, Twitter or Telegram) auths={[{ authType: AuthType.GITHUB }]} // request proof of Data Group memberships of source // (e.g part of NFT owners, Dao Participants, GitHub commiters) @@ -168,7 +168,7 @@ const config: SismoConnectConfig = { {% endtab %} {% tab title="Typescript (client)" %} -In your frontend application, the impersonation Sismo Connect Config looks like this: +In your front-end application, the impersonation Sismo Connect Config looks like this: ```typescript import { SismoConnectConfig, SismoConnect } from "@sismo-core/sismo-connect-client"; @@ -216,7 +216,7 @@ const sismoConnect = SismoConnect({config}); {% endtab %} {% tab title="Solidity (foundry)" %} -In your Smart Contract, the most basic Sismo Connect Config looks like this: +In your smart contract, the most basic Sismo Connect Config looks like this: ```solidity import "sismo-connect-solidity/SismoLib.sol"; // <--- add a Sismo Connect import diff --git a/build-with-sismo-connect/technical-documentation/vault-and-proof-identifiers.md b/build-with-sismo-connect/technical-documentation/vault-and-proof-identifiers.md index bac577a..757c344 100644 --- a/build-with-sismo-connect/technical-documentation/vault-and-proof-identifiers.md +++ b/build-with-sismo-connect/technical-documentation/vault-and-proof-identifiers.md @@ -1,10 +1,10 @@ --- -description: App-specific anonymous user ID +description: App-specific anonymous user ID. --- # Vault Identifiers -Sismo uses zero-knowledge proofs (ZKPs) to let users prove ownership/group membership of their Data Sources. Personal data (e.g I'm owner an NFT from a collection) can be revealed to applications integrated with Sismo Connect without revealing the associated Data Source. +Sismo uses zero-knowledge proofs (ZKPs) to let users prove ownership/group membership of their Data Sources. Personal data (e.g. data that proves ownership of an NFT from a specific collection) can be revealed to applications integrated with Sismo Connect without revealing the associated Data Source. For example, users can prove they own a certain NFT (i.e. prove they are part of the group of NFT owners) without revealing the wallet address (i.e. Data Source) holding it. @@ -34,11 +34,11 @@ The use of an application's **`appId`** in the formula ensures the uniqueness of ### Deterministic -As a Vault Identifier is deterministically derived from a `vaultSecret` and `appId` , a single user cannot have multiple identifiers for a specific application unless they create another Data Vault. However, Data Sources can only be added to a single Data Vault, thus ensuring a user cannot use twice the same Data Source to prove a group memberships without the application knowing it. +As a Vault Identifier is deterministically derived from a `vaultSecret` and `appId` , a single user cannot have multiple identifiers for a specific application unless they create another Data Vault. However, Data Sources can only be added to a single Data Vault, thus ensuring a user cannot use the same Data Source twice to prove membership in a Data Group without the application being aware. ### Native Data Sources -In addition, Vault Identifiers can be used as native Data Sources in the Sismo ecosystem. This allows for creating Data Groups of Vault Identifiers, which can be used by users to make group membership claims on additional Sismo Connect applications. +In addition, Vault Identifiers can be used as native Data Sources in the Sismo ecosystem. This allows for the creation of Data Groups containing Vault Identifiers, which can be used by users to make group membership claims on additional Sismo Connect applications. ## Case Studies diff --git a/build-with-sismo-connect/tutorials/create-a-sismo-connect-app.md b/build-with-sismo-connect/tutorials/create-a-sismo-connect-app.md index 451f308..2a62a11 100644 --- a/build-with-sismo-connect/tutorials/create-a-sismo-connect-app.md +++ b/build-with-sismo-connect/tutorials/create-a-sismo-connect-app.md @@ -1,18 +1,18 @@ -# Get your appId - Create a Sismo Connect App +# Get Your appId - Create a Sismo Connect App -Before you begin integrating [**Sismo Connect**](../../#sismo-connect-the-crypto-native-sso), you must register first a Sismo Connect app in the [**Sismo Factory**](https://factory.sismo.io/apps-explorer). This step is mandatory to obtain an application Id (`appId`), which is required during the Sismo Connect development process. +Before you begin integrating [**Sismo Connect**](../../#sismo-connect-the-crypto-native-sso), you must first register a Sismo Connect app in the [**Sismo Factory**](https://factory.sismo.io/apps-explorer). This step is mandatory to obtain an application Id (`appId`), which is required during the Sismo Connect development process.
Why is an appId required for Sismo Connect? -The `appId` will be used to compute a VaultId, which is the the unique identifier for a user on your app. The VaultId is simply the hash of a user's Vault secret and the appId. +The `appId` will be used to compute a vaultId, which is the unique identifier for a user on your app. The vaultId is simply the hash of a user's Vault secret and the appId. $$vaultId = hash(vaultSecret, appId)$$ -If we remove the `appId` from this simple calculation, we would have had the same VaultId for the same vaultSecret, effectively leaking information about a user that uses Sismo Connect on two different apps. The VaultId would be the same across different apps, and the user could be tracked if the VaultIds became public. +If we remove the `appId` from this simple calculation, we would have had the same vaultId for the same vaultSecret, effectively leaking information about a user that uses Sismo Connect on two different apps. The vaultId would be the same across different apps, and the user could be tracked if the vaultIds became public. -By introducing an `appId`, the vaultId is now different between apps, and the same user will have two different VaultIds on two different apps, effectively preserving the user's privacy. +By introducing an `appId`, the vaultId is now different between apps, and the same user will have two different vaultIds on two different apps, effectively preserving the user's privacy. You can learn more about this notion in this [article](../technical-documentation/vault-and-proof-identifiers.md). @@ -22,10 +22,10 @@ You can learn more about this notion in this [article](../technical-documentatio You can register a Sismo Connect app here: [https://factory.sismo.io/apps-explorer](https://factory.sismo.io/apps-explorer).\ \ -To create a Sismo Connect app, you need to log in with Sign-In With Ethereum and click on “create a new Sismo Connect app”. You will need to register an App Name, enter a description, and upload a logo alongside registering authorized domains. Pay attention to authorized domains, as these are the urls where the `appId` that will be created can be used for [Sismo Connect](../../#sismo-connect-the-crypto-native-sso). +To create a Sismo Connect app, you need to log in with Sign-In With Ethereum and click on “Create a new Sismo Connect app”. You will need to register an app name, enter a description, and upload a logo alongside registering authorized domains. Pay attention to authorized domains, as these are the URLs where the `appId` that will be created can be used for [Sismo Connect](../../#sismo-connect-the-crypto-native-sso). {% hint style="info" %} -Feel free to add `*.com` to authorized domains when developing in local. This will allow you to easily whitelist `localhost`. Don't forget to update the authorized domains when deploying in production though. +Feel free to add `*.com` to authorized domains when developing in local. This will allow you to easily whitelist `localhost`. Don't forget to update the authorized domains when deploying in production. {% endhint %} Once created, you should have all information about your app displayed in your profile: diff --git a/build-with-sismo-connect/tutorials/deploy-your-contracts.md b/build-with-sismo-connect/tutorials/deploy-your-contracts.md index 1c4a808..673fcec 100644 --- a/build-with-sismo-connect/tutorials/deploy-your-contracts.md +++ b/build-with-sismo-connect/tutorials/deploy-your-contracts.md @@ -1,11 +1,11 @@ -# Onchain Tutorial (2/2): deploy your Airdrop contract +# Onchain Tutorial (2/2): Deploy Your Airdrop Contract ## Overview -This tutorial aims at describing the notions around the deployment of Sismo Connect contracts. In this context, we will recap what is a Sismo Connect Client config and how to impersonate accounts. Once understood, these notions will allow you to confidently deploy your contracts inheriting Sismo Connect functionalities. +This tutorial aims at describing the process behind the deployment of Sismo Connect contracts. In this context, we will recap on what a Sismo Connect Client config is and how to impersonate accounts. Once understood, these notions will allow you to confidently deploy contracts with Sismo Connect's functionalities. {% hint style="success" %} -To better understand the different notions highlighted in this tutorial, we strongly advise you to go through [**the first tutorial**](tuto.md) that will show you how to leverage data aggregation in your app by [**building a Gated Airdrop for Gitcoin Passport holders**](tuto.md). +To better understand the different notions highlighted in this tutorial, we strongly advise you to go through [**the first tutorial**](tuto.md)**,** which will show you how to leverage data aggregation in your app by [**building a Gated Airdrop for Gitcoin Passport holders**](tuto.md). {% endhint %} For this tutorial, we will again use the GitHub repository used for the [**gated airdrop tutorial**](tuto.md). You can **clone it** and **install it** as described in the repository's README or in [**the tutorial**](tuto.md). You don't need to clone it again if you just finished the tutorial. @@ -17,10 +17,10 @@ This tutorial requires: * [Node.js](https://nodejs.org/en/download/) >= 18.15.0 (Latest LTS version) * [Yarn](https://classic.yarnpkg.com/en/docs/install) * [Foundry](https://book.getfoundry.sh/) (see how to install it [here](https://book.getfoundry.sh/getting-started/installation)) -* Metamask installed in your browser +* MetaMask installed in your browser {% hint style="success" %} -We use Foundry for our smart contract dependencies but we also have a [**Hardhat library**](https://www.npmjs.com/package/@sismo-core/sismo-connect-solidity). This tutorial is focused on how to deploy your smart contracts using Foundry. +We use Foundry for our smart contract dependencies, but we also have a [**Hardhat library**](https://www.npmjs.com/package/@sismo-core/sismo-connect-solidity). This tutorial is focused on how to deploy your smart contracts using Foundry. {% endhint %} ## Installation @@ -41,15 +41,15 @@ foundryup forge install ``` -Once this steps are done, you are well setup to use [Forge](https://book.getfoundry.sh/forge/deploying), a tool provided by Foundry to test and deploy smart contracts. +Once these steps are done, you are well set up to use [Forge](https://book.getfoundry.sh/forge/deploying), a tool provided by Foundry to test and deploy smart contracts. ## Understand the Sismo Connect config Before deploying any Sismo Connect contract, it is better to understand the Sismo Connect config and especially how to impersonate accounts. -As you may already know, Sismo Connect is the communication layer allowing any Sismo Connect app to requests some proofs about user data and receive the expected proofs before verifying them. To be able to produce such proofs, users are required to import accounts (i.e. [Data Sources](../../data-groups/data-groups-and-how-to-create-them/#data-sources)) into their [Data Vaults](../../how-sismo-works/core-components/what-is-the-data-vault.md). By doing so, they will be able to prove group membership and account ownership to apps. +As you may already know, Sismo Connect is the communication layer allowing any Sismo Connect app to request ZK proofs about user data and receive the expected proofs before verifying them. To be able to produce such proofs, users are required to import accounts (i.e. [Data Sources](../../data-groups/data-groups-and-creation/#data-sources)) into their [Data Vaults](../../how-sismo-works/core-components/what-is-the-data-vault.md). By doing so, they will be able to prove group membership and account ownership to apps. -Such proof generation is possible (among other things) thanks to the [**Commitment Mapper**](../../how-sismo-works/technical-concepts/commitment-mapper.md)**.** Therefore, we allow **any developer to impersonate accounts** by automatically creating a fake Commitment Mapper in the Vault App front end if the **Vault object with impersonate field is defined in the Sismo Connect configuration**. +Such proof generation is possible (among other things) thanks to the [**Commitment Mapper**](../../how-sismo-works/technical-concepts/commitment-mapper.md)**.** Therefore, we allow **any developer to impersonate accounts** by automatically creating a fake Commitment Mapper in the Vault app front end if the **Vault object with the impersonate field is defined in the Sismo Connect configuration**. You can learn more about the Sismo Connect configuration [**here**](../technical-documentation/sismo-connect-configuration.md). @@ -93,7 +93,7 @@ contract A is SismoConnect { Solidity scripting is a way to declaratively deploy contracts using Solidity instead of using the more limiting and less user friendly [`forge create`](https://book.getfoundry.sh/reference/forge/forge-create.html). You can look at the [example displayed in the Foundry documentation](https://book.getfoundry.sh/tutorials/solidity-scripting?highlight=script#solidity-scripting) if you want to learn more about it. -We are going to use a simple solidity script to deploy our contract on our chosen network. +We are going to use a simple Solidity script to deploy our contract on our chosen network. You can see the script used in `script/Airdrop.s.sol` file. Here is it: @@ -115,7 +115,7 @@ contract DeployAirdrop is Script { } ``` -This script is really simple, it declares a **new Airdrop contract** between `vm.startBroadcast` and `vm.stopBroadcast,` two [**foundry cheatcodes**](https://book.getfoundry.sh/cheatcodes/) that will simulate the contract creation in the context you will provide (here the context of a Mumbai fork as you will see). +This script is simple; it declares a **new airdrop contract** between `vm.startBroadcast` and `vm.stopBroadcast,` two [**foundry cheatcodes**](https://book.getfoundry.sh/cheatcodes/) that will simulate the contract creation in the context you will provide. You can simply run this command to see the simulation of your contract deployment in the context of a Mumbai fork. @@ -175,7 +175,7 @@ forge script DeployAirdrop --rpc-url --private-key '0xac09 If you try to run this exact command without changing the private key, you will encounter an error since the account has no funds. You should replace the private key by your own developer private key and have some funds on your dev account (Mumbai faucet link: [https://mumbaifaucet.com/](https://mumbaifaucet.com/)). {% hint style="success" %} -Notice the `--broadcast` option which states that you want to actually trigger the transaction on the Mumbai testnet. +Notice the `--broadcast` option, which states that you want to actually trigger the transaction on the Mumbai testnet. {% endhint %} ## Verify your contracts with `--verify` option @@ -183,12 +183,12 @@ Notice the `--broadcast` option which states that you want to actually trigger t To verify your contracts, you will need to register for an Etherscan API key. {% hint style="success" %} -The Etherscan API Key needs to be registered from Polygonscan if you want to deploy on Mumbai: [https://polygonscan.com/myaccount](https://polygonscan.com/myaccount) +The Etherscan API Key needs to be registered from PolygonScan if you want to deploy on Mumbai: [https://polygonscan.com/myaccount](https://polygonscan.com/myaccount) {% endhint %} You just need to directly specify the `--verify` option when deploying alongside your Etherscan API key. -It is pretty straightforward: +In clear terms: {% code overflow="wrap" %} ```bash @@ -236,10 +236,10 @@ All (1) contracts were verified! ``` {% hint style="success" %} -If you deploy the exact contract from the tutorial on Mumbai, you are likely to encounter a message stating "Already verified". As long as your contract is verified, it is totally fine! +If you deploy the exact contract from the tutorial on Mumbai, you are likely to encounter a message reading "Already verified". As long as your contract is verified, it is totally fine! {% endhint %} -And congrats on your deployment! You should be left with a verified contract at this point. If not don't hesitate to reach out to us on our [**developer telegram**](https://t.me/+Z-SwcvXZFRVhZTQ0)**.** +And congrats on your deployment! You should be left with a verified contract at this point. If not, don't hesitate to reach out to us on our [**developer Telegram**](https://t.me/+Z-SwcvXZFRVhZTQ0)**.** If you want to use the tutorial front end with your contracts, you will need to add some minor changes to the `front/src/app/page.tsx` file. You will first need to change how you get the `contractAddress` by changing 5151111 (the fork chain id) to 80001 (the Mumbai chain id) in your imports. You also have to use the `polygonMumbai` chain config from viem instead of `mumbaiFork` config for the chain. diff --git a/build-with-sismo-connect/tutorials/tuto.md b/build-with-sismo-connect/tutorials/tuto.md index 459547e..65f3e72 100644 --- a/build-with-sismo-connect/tutorials/tuto.md +++ b/build-with-sismo-connect/tutorials/tuto.md @@ -1,12 +1,12 @@ -# Onchain Tutorial (1/2): code your Airdrop contract with privately-aggregated data +# Onchain Tutorial (1/2): Code Your Airdrop Contract With Privately-Aggregated Data ## Overview This tutorial is designed as an **introduction** to **Sismo Connect Solidity** Library. -It shows you how to create a Sybil-resistant ERC20 airdrop from privately-aggregated data. Take a look at the [**SafeDrop Case Study**](https://case-studies.sismo.io/db/safe-drop) to understand deeply the use case. +It shows you how to create a Sybil-resistant ERC20 airdrop from privately-aggregated data. Take a look at the [**SafeDrop Case Study**](https://case-studies.sismo.io/db/safe-drop) to deeply understand the use case. -You will learn how to request ZK proofs about your user's data and verify them in your contracts. +You will learn how to request ZK proofs about your user's data and verify them in your smart contracts. ## Prerequisites @@ -15,7 +15,7 @@ This tutorial requires: * [Node.js](https://nodejs.org/en/download/) >= 18.15.0 (Latest LTS version) * [Yarn](https://classic.yarnpkg.com/en/docs/install) * [Foundry](https://book.getfoundry.sh/) (see how to install it [here](https://book.getfoundry.sh/getting-started/installation)) -* Metamask installed in your browser +* MetaMask installed in your browser {% hint style="info" %} We use Foundry for our smart contract dependencies, but we also have a [**Hardhat library**](https://www.npmjs.com/package/@sismo-core/sismo-connect-solidity). A tutorial with Hardhat integration will be made in the coming weeks. Don't hesitate to ask questions on our [Builder Telegram](https://t.me/+Z-SwcvXZFRVhZTQ0) group if you have any. @@ -47,7 +47,7 @@ yarn anvil #### Launch the local application -You can now launch your local dapp with the commands: +You can now launch your local app with the commands: ```bash # in another terminal @@ -60,21 +60,21 @@ yarn dev This command starts the NextJs application that will call the contract in `src/Airdrop.sol` which has already been deployed on your local fork of Mumbai. You should now have the simple tutorial application running on [http://localhost:3000](http://localhost:3000). -You can now play with the local app that already integrates Sismo Connect. You should be able to claim your Airdrop! +You can now play with the local app that already integrates Sismo Connect. You should be able to claim your airdrop!

Claim successfully your airdrop

### Important note {% hint style="warning" %} -The interaction with the fork network can become quite unstable if you stop the `yarn anvil` command at some point or if you already use the sample app before. +The interaction with the fork network can become quite unstable if you stop the `yarn anvil` command at some point or if you already used the sample app before. You can end up with an infinitely pending transaction. If so: * keep the local anvil node running, -* make sure to delete your activity tab for the fork network in Metamask by going to "Settings > Advanced > Clear activity tab data" when connected to the fork network. +* make sure to delete your activity tab for the fork network in MetaMask by going to "Settings > Advanced > Clear activity tab data" when connected to the fork network. * relaunch the anvil node and the application See the [FAQ](../faq.md) for more information. @@ -116,7 +116,7 @@ import { const sismoConnectConfig: SismoConnectConfig = { appId: "0xf4977993e52606cfd67b7a1cde717069", vault: { - // We will impersonate those Data Sources, will be useful later + // We will impersonate those Data Sources, which will be useful later impersonate: [ "dhadrien.sismo.eth", "twitter:dhadrien_", @@ -144,13 +144,13 @@ Let's add the Sismo Connect Button and request the`vaultId` of users. vaultId: anonymous indentifier for a user. Will be used to avoid users to claim twice -Sismo users have a sovereign [Data Vault](../../how-sismo-works/core-components/what-is-the-data-vault.md) where they import Data Source fro which they will generate ZK Proofs. Each Data Vault has a secret only know by its owner. +Sismo users have a sovereign [Data Vault](../../how-sismo-works/core-components/what-is-the-data-vault.md) where they import Data Sources from which they will generate ZK proofs. Each Data Vault has a secret only known by its owner. -To identify users, you can request a `vaultId.`It is a sovereign an anonymous Identifier natively provided to Sismo Connect Apps. vaultId = hash(userVaultSecret, AppId, 0) +To identify users, you can request a `vaultId.`It is a sovereign and anonymous identifier natively provided to Sismo Connect Apps. vaultId = hash(userVaultSecret, AppId, 0) The `vaultId` will be used to make sure a user that claimed the airdrop is registered and cannot claim it twice! -you can read more about it in [**Vault Identifiers.**](../technical-documentation/vault-and-proof-identifiers.md) +You can read more about it in [**Vault Identifiers.**](../technical-documentation/vault-and-proof-identifiers.md)
@@ -175,17 +175,17 @@ you can read more about it in [**Vault Identifiers.**](../technical-documentatio /> ``` -What are the different react button props? +What are the different React button props? * **`configuration.`** Learn more about the **Sismo Connect Config** [**here**](../technical-documentation/sismo-connect-configuration.md). -* **`auths:`** Request here proof of ownership of Data Sources (Wallet, Github, Telegram, Twitter and VaultId). -* **`signature:`** We can request users to sign a message, here we request them to sign the recipient address for the airdrop. It will protect them from front-running +* **`auths:`** Request proof of ownership of Data Sources here (Wallet, GitHub, Telegram, Twitter and vaultId). +* **`signature:`** We can request users to sign a message; here, we request them to sign the recipient address for the airdrop, protecting them from front-running.
-Frontrunning: why do we need a signature when verifying proofs on-chain? +Front-running: why do we need a signature when verifying proofs onchain? -The signed message is not mandatory when you interact with your contracts, but it is very often needed. As far as your users are generating valid proofs, it could be quite easy for a third party to front-run them by just taking their proof and making their own call to your smart contracts with it. +The signed message is not mandatory when you interact with your contracts, but it is very often needed. As far as your users are generating valid proofs, it could be quite easy for a third party to front-run them by taking their proof and making their own call to your smart contracts with it. To overcome this issue, we offer a way to embed a specific message in a proof. It can be thought of as a signature since this proof could not be valid without checking successfully that the signed message is correct onchain. @@ -193,20 +193,20 @@ Here, for example, we request the user to embed the address where they want to r
-* **`onResponseBytes:`** function that will be called after the user has generated the ZK Proof and sent the Sismo Connect Response. Here we are just storing the response. +* **`onResponseBytes:`** a function that will be called after the user has generated the ZK proof and sent the Sismo Connect Response. Here we are just storing the response. * **`text:`** Content on the button {% hint style="info" %} -For more: check the Cheatsheet, the [**@sismo-core/sismo-connect-react**](../technical-documentation/packages/react.md) library, feel free to check the [**technical documentation**](../technical-documentation/packages/react.md). +For more: check the Cheatsheet, the [**@sismo-core/sismo-connect-react**](../technical-documentation/packages/react.md) library, and feel free to check the [**technical documentation**](../technical-documentation/packages/react.md). {% endhint %} Now let's see how the contracts work! ## Verify proofs onchain -Let's verify the ZK Proof in your contract. Go to `src/Airdrop.sol` +Let's verify the ZK proof in your contract. Go to `src/Airdrop.sol` -Below is the code that initiates the contract with the Sismo Connect Solidity Library, and like in the frontend, it must be be initilazed with a configuration. +Below is the code that initiates the contract with the Sismo Connect Solidity Library, and like in the front end, it must be initiated with a configuration. ```solidity // you are in: src/Airdrop.sol @@ -236,9 +236,9 @@ contract Airdrop is ERC20, SismoConnect { // <--- add a Sismo Connect inheritanc } ``` -Take a look at the `claimWithSismo` function. It takes the Sismo Connect Response as an argument (which is received by the frontend after the users has generated the ZK Proof) and verifies the response valid against the authentication and the signature requested. +Take a look at the `claimWithSismo` function. It takes the Sismo Connect Response as an argument (which is received by the front after the user has generated the ZK proof) and verifies the response as valid against the authentication and the signature requested. -If the response is valid, it checks that the airdrop has not been claimed before by the `vaultId` and finally mints 100 tokens on the address in the signature. +If the response is valid, it checks that the airdrop has not been claimed before by the associated`vaultId` and finally mints 100 tokens to the address in the signature. 
// you are in src/Airdrop.sol
 
@@ -250,7 +250,7 @@ contract Airdrop is ERC20, SismoConnect {
     SismoConnectVerifiedResult memory result = verify({
       responseBytes: response,
       // we want the user to prove that he owns a Sismo Vault
-      // we are recreating the auth request made in the frontend to be sure that 
+      // we are recreating the auth request made in the front end to be sure that 
       // the proofs provided in the response are valid with respect to this auth request
       auth: buildAuth({authType: AuthType.VAULT}),
       // we also want to check if the signed message provided in the response is the signature of the user's address
@@ -291,7 +291,7 @@ The integration is basically done! 
 Ok, so if we recap an onchain Sismo Connect integration, it all comes to:
 
 * the creation of an app in the Sismo Factory to get an `appId`
-* a Sismo Connect configuration in the frontend and the smart contract with this `appId` and a possible "impersonation mode" enabled with chosen accounts for easy testing
+* a Sismo Connect configuration in the front end and the smart contract with this `appId` and a possible "impersonation mode" enabled with chosen accounts for easy testing
 * the configuration of the React button to choose which proofs to request from your users
 * the creation of a smart contract to verify the user proofs onchain
 
@@ -302,7 +302,7 @@ Well, now that you have all these steps in mind, let's improve this airdrop cont
 Our first aim is to make the ERC20 airdrop Sybil-resistant. To do this, we simply need to request a proof of Gitcoin Passport group membership from our users. We also want them to have a passport score above 15. You can request such a proof by taking the `groupId` of the "Gitcoin Passport Holders" group that can be found on the Sismo Factory at this link: [https://factory.sismo.io/groups-explorer?search=0x1cde61966decb8600dfd0749bd371f12](https://factory.sismo.io/groups-explorer?search=0x1cde61966decb8600dfd0749bd371f12) and create a [**claim request**](../technical-documentation/claims.md) from it.
 
 {% hint style="success" %}
-You can learn how to create a Data Group with the [following tutorial](../../data-groups/data-groups-and-how-to-create-them/create-your-data-group.md).
+You can learn how to create a Data Group with the [following tutorial](../../data-groups/data-groups-and-creation/create-your-data-group.md).
 {% endhint %}
 
 The `groupId` of the Gitcoin Passport Holders group is `0x1cde61966decb8600dfd0749bd371f12`. Let's add our claim request in the React button. We indicate the groupId of the group and the minimum value required in this group.
@@ -391,7 +391,7 @@ contract Airdrop is ERC20, SismoConnect {
 
 These simple code additions now allow our smart contract to only airdrop some tokens to holders of a Gitcoin Passport. While this is exciting, how can we quickly test it in our local front end if we are not Gitcoin Passport holders? 
 
-The simplest solution is to impersonate an account holding a Gitcoin Passport. Remember that we are already impersonating dhadrien.sismo.eth ethereum account that holds a Gitcoin Passport on his ENS, therefore we are eligible.
+The simplest solution is to impersonate an account holding a Gitcoin Passport. Remember that we are already impersonating the dhadrien.sismo.eth Ethereum account that holds a Gitcoin Passport, making us eligible.
 
 {% hint style="success" %}
 Don't forget to remove the `vault object` in the config when deploying in production.
@@ -400,42 +400,42 @@ Don't forget to remove the `vault object` in the config when deploying in produc
 When all of this is done, you can try again to go on your local application on [http://localhost:3000](http://localhost:3000) to see the new proofs requested. 
 
 {% hint style="success" %}
-**You don't need to do anything with anvil or your frontend application in your terminals, all is reloaded automatically for you. Just play with your front by clicking on the "RESET" button in the top right! 😇**
+**You don't need to do anything with anvil or your front-end application in your terminals. All is reloaded automatically for you. Just play with your front end by clicking on the "RESET" button in the top right! 😇**
 {% endhint %}
 
-As you can see below, you are now asked to share your `userId` like before and you also should prove that you own a Gitcoin Passport. You also keep signing the address on which you want to receive the airdrop.
+As you can see below, you are now asked to share your `userId` like before, and you also should prove that you own a Gitcoin Passport. You also keep signing the address on which you want to receive the airdrop.
 
 
Sismo Vault UI when redirected

 
 {% hint style="warning" %}
-The interaction with the fork network can become quite unstable if you stop the `yarn anvil` command at some point or if you already use the sample app before.
+The interaction with the fork network can become quite unstable if you stop the `yarn anvil` command at some point or if you already used the sample app before.
 
 You can end up with an infinitely pending transaction.
 
 If so:
 
-* keep the local anvil node running, 
-* make sure to delete your activity tab for the fork network in Metamask by going to "Settings > Advanced > Clear activity tab data" when connected to the fork network. 
-* relaunch the anvil node and the application
+* Keep the local anvil node running, 
+* Make sure to delete your activity tab for the fork network in MetaMask by going to "Settings > Advanced > Clear activity tab data" when connected to the fork network. 
+* Relaunch the anvil node and the application
 
 See [FAQ](../faq.md) for more information.
 {% endhint %}
 
-Congrats again! You have successfully made your airdrop Sybil-Resistant by gating it for holders of Gitcoin Passport.
+Congrats again! You have successfully made your airdrop Sybil-resistant by gating it for holders of Gitcoin Passport.
 
-Let's see how to ultimately combine data aggregation with privacy now by gating this Sybil-Resistant airdrop to specific Sismo Community members and allowing them to get more tokens depending on their reputation.
+Let's see how to ultimately combine data aggregation with privacy now by gating this Sybil-resistant airdrop to specific Sismo community members and allowing them to get more tokens depending on their reputation.
 
 ## Combine data aggregation and privacy
 
-Data aggregation can be powerful in the context of an airdrop, for example it can allow you to receive extra tokens if you prove some specific engagement in a community. In our example, we will offer more tokens to people that were early users of Sismo and to all the Sismo Factory users. Sismo Community members will also receive more tokens based on the value they have in the group.
+Data aggregation can be powerful in the context of an airdrop. For example, it can allow you to receive extra tokens if you prove some specific engagement in a community. In our example, we will offer more tokens to people that were early users of Sismo and to all the Sismo Factory users. Sismo Community members will also receive more tokens based on the value they have in the group.
 
 To do this, we will simply do the same logic as before by creating additional claim requests for:
 
-*  Sismo Community members with the id `0xd630aa769278cacde879c5c0fe5d203c` (you can see the group description in the Sismo Factory [here](https://factory.sismo.io/groups-explorer?search=0xd630aa769278cacde879c5c0fe5d203c)). This membership is required.
-* Early Sismo Community members with the id `0xe4c011331d91b79639df349a93157a1b` (you can see the group description in the Sismo Factory [here](https://factory.sismo.io/groups-explorer?search=0xe4c011331d91b79639df349a93157a1b)). This membership is optional and allows to receive more tokens.
-* Sismo Factory Users with the id `0x05629c9a54e30d8c8aea911a48cd9e30` (you can see the group description in the Sismo Factory [here](https://factory.sismo.io/groups-explorer?search=0x05629c9a54e30d8c8aea911a48cd9e30)). This membership is optional and allows to receive more tokens.
+* Sismo Community members with the id `0xd630aa769278cacde879c5c0fe5d203c` (you can see the group description in the Sismo Factory [here](https://factory.sismo.io/groups-explorer?search=0xd630aa769278cacde879c5c0fe5d203c)). This membership is required.
+* Early Sismo Community members with the id `0xe4c011331d91b79639df349a93157a1b` (you can see the group description in the Sismo Factory [here](https://factory.sismo.io/groups-explorer?search=0xe4c011331d91b79639df349a93157a1b)). This membership is optional and allows claimants to receive more tokens.
+* Sismo Factory Users with the id `0x05629c9a54e30d8c8aea911a48cd9e30` (you can see the group description in the Sismo Factory [here](https://factory.sismo.io/groups-explorer?search=0x05629c9a54e30d8c8aea911a48cd9e30)). This membership is optional and allows users to receive more tokens.
 
-You can add the claim requests in the frontend, notice that to claim the airdrop you must have a Gitcoin Passport and be a member of the Sismo Community but it is not required to be an early contributor nor a Factory user.
+You can add the claim requests in the front end. Notice that to claim the airdrop, you must have a Gitcoin Passport and be a member of the Sismo Community, but it is not required to be an early contributor or a Factory user.
 
 ```typescript
 // you are in: front/src/app/page.tsx
@@ -565,13 +565,13 @@ function _getRewardAmount(
 }
 ```
 
-You can try again to claim the airdrop from your application, you will see the auth request with the four claim requests and the sign message. If you share all the informations by default, you should end up with 400 tokens!
+You can try again to claim the airdrop from your application. You will see the auth request with the four claim requests and the sign message. If you share all the information by default, you should end up with 400 tokens!
 
 
Sismo Vault UI when redirected

 
 And it is our final congrats! 🎉
 
-If we recap, you basically managed to go from a simple request of **vaultId** to a complex multi request of **vaultId** + **group memberships** allowing you to create a Sybil-Resistant airdrop from privately-aggregated data. All these requests respect the user privacy since no ethereum address is ever shared during the flow and all of this is made possible thanks to the data aggregation that offers the Sismo Vault. 
+If we recap, you managed to go from a simple request of **vaultId** to a complex multi-request of **vaultId** + **group membership** allowing you to create a Sybil-resistant airdrop from privately-aggregated data. All these requests respect user privacy since no Ethereum address is ever shared during the flow, thanks to data aggregation in Sismo's Data Vault.
 
 To see how to deploy your contracts, you can go to the [**associated tutorial**](deploy-your-contracts.md).
 
diff --git a/data-groups/data-groups-and-how-to-create-them/README.md b/data-groups/data-groups-and-creation/README.md
similarity index 56%
rename from data-groups/data-groups-and-how-to-create-them/README.md
rename to data-groups/data-groups-and-creation/README.md
index 0b789de..34b06ae 100644
--- a/data-groups/data-groups-and-how-to-create-them/README.md
+++ b/data-groups/data-groups-and-creation/README.md
@@ -1,4 +1,4 @@
-# Data Groups & How to Create them?
+# Data Groups & Creation
 
 Data Groups are created via the [Factory UI](https://factory.sismo.io) or by creating a pull request on the [Sismo Hub](https://github.com/sismo-core/sismo-hub).
 
@@ -6,39 +6,39 @@ Data Groups are created via the [Factory UI](https://factory.sismo.io) or by cre
 
 The Factory is an interface to easily create Data Groups on the Sismo Hub infrastructure. 
 
-The Sismo Hub computes merkle trees of groups, store them in its database and publish the merkle tree roots onchain. 
+The Sismo Hub computes Merkle trees of groups, stores them in its database and publishes the Merkle tree roots onchain. 
 
-Onchain roots are the source of truth for backend and smart contracts to verify whether a ZK Proof is valid.
+Onchain roots are the source of truth for back ends and smart contracts to verify whether a ZK proof is valid.
 
 {% hint style="info" %}
-Everything is [open-source](https://github.com/sismo-core/sismo-hub) and all groups can be computed by all.
+Everything is [open-source](https://github.com/sismo-core/sismo-hub). Anyone can compute any Data Group.
 {% endhint %}
 
 ## Data Sources
 
 Data Sources are the accounts that users aggregate in their Data Vault. Currently supported Data Sources: 
 
-* Ethereum wallets/ EVM accounts
+* Ethereum wallets/EVM accounts
 * GitHub accounts
 * Twitter accounts
 * Telegram accounts
 
-From imported Data Sources, vault owners can generate ZK Proofs of:
+From imported Data Sources, Vault owners can generate ZK proofs of:
 
-* ownership of a specific Data Source (e.g authentication)
-* inclusion of an owned Data Source in a Data Group (+ claim about its value in the group)
+* Ownership of a specific Data Source (i.e, authentication)
+* Inclusion of an owned Data Source in a Data Group (and a claim about its value in the group)
 
 {% hint style="info" %}
-Take a look at the Sismo Connect Cheatsheet to see all request y
+Take a look at the [Sismo Connect Cheatsheet](../../build-with-sismo-connect/sismo-connect-cheatsheet.md) to see all requests.
 {% endhint %}
 
 ## Data Groups
 
-Data Groups are sets of Data Sources where each Data Source has an associated value.
+Data Groups are sets of Data Sources in which each Data Source has an associated value.
 
 

 
-Concrete examples Data Groups and ZK Proofs you can request from users
+Concrete examples of Data Groups and ZK proofs you can request from users
 
 ```json
 { // "Stand With Crypto" NFT Minters Data Group
@@ -56,14 +56,12 @@ Data Groups are sets of Data Sources where each Data Source has an associated va
 }
 ```
 
-* All owners of these wallets can create a ZK Proof that they are part of this group
+* All owners of these wallets can generate a ZK proof attesting that they are part of this group
 
 
 
-* owner of `0x70ddb5abf21202602b57f4860ee1262a594a0086` can create a ZK Proof that they are part of the group with value > 10 (e.g minted more than 10 NFTs)
-* owner of 0xa2bf1b0a7e079767b4701b5a1d9d5700eb42d1d1 can create a ZK Proof that they are part of the group with value = 21 (e.g minted exactly 2 NFT)
-
-
+* The owner of `0x70ddb5abf21202602b57f4860ee1262a594a0086` can generate a ZK proof attesting that they are part of the group with a value > 10 (e.g, minted more than 10 NFTs)
+* The owner of 0xa2bf1b0a7e079767b4701b5a1d9d5700eb42d1d1 can create a ZK proof attesting that they are part of the group with a value = 2 (e.g minted exactly 2 NFT)
 
 ```json
 { // Sismo Community Data Group, created by Sismo
@@ -83,19 +81,17 @@ Data Groups are sets of Data Sources where each Data Source has an associated va
 }
 ```
 
-* All owners of these wallets can create a ZK Proof that they are part of this group
+* All owners of these wallets can generate a ZK proof attesting that they are part of this group
 
 
 
-* owner of `dhadrien.eth` can create a ZK Proof that they are part of the group with value > 2 (e.g community member with level > 2)
-* owner of  @wojtekwtf on twitter can create  a ZK Proof that they are part of the group with value = 3 (e.g community member with level 3)
+* The owner of `dhadrien.eth` can create a ZK proof attesting that they are part of the group with a value > 2 (e.g, community member with level > 2)
+* The owner of  @wojtekwtf on Twitter can generate  a ZK proof attesting that they are part of the group with a value = 3 (e.g, community member with level 3)
 
 
 
 

 
-
Data Group ExamplesMembers (Data Sources)Value for each Data Source
"Stand With Crypto" NFT Minterswallets of minters number of NFT minted
Gitcoin Passport Holderswallets of Gitcoin Passport holderssybil-resistant score
Sismo Hub Github Contributors github accounts of contributors to sismo-core/sismo-hub reponumber of contributions
ENS DAO Voterswallets of voters in ENS DAOnumber of votes
Sismo Community Memberswallets, github, telegram and twitter accounts of all people that helped Sismolevel of their contributions (1, 2 or 3)

-
-
+
Data Group ExamplesMembers (Data Sources)Value for each Data Source
"Stand With Crypto" NFT MintersWallets of minters Number of NFT minted
Gitcoin Passport HoldersWallets of Gitcoin Passport holdersSybil-resistant score
Sismo Hub Github Contributors GitHub accounts of contributors to sismo-core/sismo-hub repoNumber of contributions
ENS DAO VotersWallets of voters in the ENS DAONumber of votes
Sismo Community MembersWallets, GitHub, Telegram and Twitter accounts of all people that helped SismoLevel of their contributions (1, 2 or 3)

 
 
Factory Guide: 
Create a Data Group in 5 Minutes
create-your-data-group.md
Sismo Hub Guide: 
Create Data Groups Programmatically		create-your-group-generator.md
Sismo Hub Guide: 
Add a Data Provider to the Sismo Factory		create-your-data-provider.md

diff --git a/data-groups/data-groups-and-how-to-create-them/create-your-data-group.md b/data-groups/data-groups-and-creation/create-your-data-group.md
similarity index 99%
rename from data-groups/data-groups-and-how-to-create-them/create-your-data-group.md
rename to data-groups/data-groups-and-creation/create-your-data-group.md
index b0e8c21..6c96a68 100644
--- a/data-groups/data-groups-and-how-to-create-them/create-your-data-group.md
+++ b/data-groups/data-groups-and-creation/create-your-data-group.md
@@ -13,7 +13,7 @@ If you are a developer and want to build your own customizable Data Group, go ch
 {% endhint %}
 
 {% hint style="success" %}
-Don't hesitate to join our [**Dev** **Telegram**](https://t.me/+Z-SwcvXZFRVhZTQ0) and ping us during a hackathon. We would love to talk to you and meet you there. **All new Groups under 100k accounts are automatically deployed**.
+Don't hesitate to join our [**Dev** **Telegram**](https://t.me/+Z-SwcvXZFRVhZTQ0) and ping us during a hackathon. We would love to talk to you and meet you there. **All new Data Groups under 100k accounts are automatically deployed**.
 {% endhint %}
 
 ## What are Data Groups?
diff --git a/data-groups/data-groups-and-how-to-create-them/create-your-data-provider.md b/data-groups/data-groups-and-creation/create-your-data-provider.md
similarity index 100%
rename from data-groups/data-groups-and-how-to-create-them/create-your-data-provider.md
rename to data-groups/data-groups-and-creation/create-your-data-provider.md
diff --git a/data-groups/data-groups-and-how-to-create-them/create-your-group-generator.md b/data-groups/data-groups-and-creation/create-your-group-generator.md
similarity index 99%
rename from data-groups/data-groups-and-how-to-create-them/create-your-group-generator.md
rename to data-groups/data-groups-and-creation/create-your-group-generator.md
index b971011..46bdc61 100644
--- a/data-groups/data-groups-and-how-to-create-them/create-your-group-generator.md
+++ b/data-groups/data-groups-and-creation/create-your-group-generator.md
@@ -1,5 +1,5 @@
 ---
-description: Developer Tutorial
+description: Developer tutorial
 ---
 
 # Sismo Hub Guide: Create Data Groups Programmatically
diff --git a/how-sismo-works/core-components/README.md b/how-sismo-works/core-components/README.md
index b623ae4..a346e76 100644
--- a/how-sismo-works/core-components/README.md
+++ b/how-sismo-works/core-components/README.md
@@ -6,12 +6,8 @@ description: An overview of how Sismo works.
 
 Sismo enables communication between a user’s personal data and applications. The following components are fundamental in facilitating this communication:
 
-* [Data Vault](what-is-the-data-vault.md) — a local, sovereign and private identity aggregator
-* [Data Sources](../../data-groups/data-groups-and-how-to-create-them/#data-sources) — web2 or web3 accounts and other credentials aggregated in a user’s Data Vault
-* [Data Groups](../../data-groups/data-groups-and-how-to-create-them/#data-groups) — enable users to make claims about their Data Sources.
-* [Proving schemes](proving-schemes/) — cryptographic circuits that enable users to prove ownership of Data Sources and group membership of Data Sources
-* [The Sismo Hub](what-is-the-data-vault-1.md#what-is-the-sismo-hub) — Sismo’s data infrastructure used to create Data Groups, thus enabling users to make claims of group membership.
+* [Data Vault](what-is-the-data-vault.md) — a local, sovereign and private identity aggregator that stores [Data Sources](../../data-groups/data-groups-and-creation/#data-sources)
+* [Proving schemes](proving-schemes/) — cryptographic circuits that enable users to prove ownership of Data Sources and membership in [Data Groups](../../data-groups/data-groups-and-creation/#data-groups)
+* [The Sismo Hub](what-is-the-data-vault-1.md#what-is-the-sismo-hub) — Sismo’s data infrastructure used to create Data Groups, thus enabling users to make claims about their personal data.
 
 Sismo enables users to freely leverage Data Sources, bypassing the typical privacy limitations associated with web3 and the constraint of being confined to a single platform on web2.
-
-##
diff --git a/how-sismo-works/core-components/proving-schemes/README.md b/how-sismo-works/core-components/proving-schemes/README.md
index 5c4448f..46f1123 100644
--- a/how-sismo-works/core-components/proving-schemes/README.md
+++ b/how-sismo-works/core-components/proving-schemes/README.md
@@ -1,8 +1,6 @@
 # Proving Schemes
 
-## Prove & Verify
-
-Sismo Connect technically let users participate in proving schemes to make claims from their Data Sources.
+Sismo Connect technically let users participate in proving schemes to make claims about [Data Sources](../../../data-groups/data-groups-and-creation/#data-sources) in their [Data Vault](../what-is-the-data-vault.md).
 
 {% hint style="info" %}
 A proving scheme is a cryptographic method that allows one party (the prover) to prove to another party (the verifier) that a certain statement is true without revealing how it is true—ensuring privacy.
@@ -10,7 +8,7 @@ A proving scheme is a cryptographic method that allows one party (the prover) to
 
 

 
-The Data Vault includes the provers, enabling users to generate zero-knowledge proofs (ZKPs) from their Data Sources (proof of ownership/ proof of inclusion in a Data Group). The ZKP is then verified by the application (in a smart contract for onchain apps, in a backend of offchain apps, in a browser/client for p2p apps)
+The Data Vault includes the prover, enabling users to generate zero-knowledge proofs (ZKPs) from their Data Sources (proof of ownership/proof of inclusion in a [Data Group](../../../data-groups/data-groups-and-creation/)). The ZKP is then verified by the application (in a smart contract for onchain apps, in a backend for offchain apps, and in a browser/client for p2p apps). 
 
 ## Proving Schemes
 
@@ -18,7 +16,7 @@ Fundamentally, a proving scheme is a paired concept involving a prover and a ver
 
 In a proving scheme, both the prover and the verifier require access to the same data—the source of truth from which proofs are generated, called Data Groups. For instance, to prove ownership of a specific NFT at a certain time, the prover and verifier must be synchronized on the same snapshot of NFT owners (i.e. a Data Group).
 
-Sismo Connect is the developer-friendly layer on top of proving schemes. It enables apps to request and verify ownership/ group membership of Data Sources. Sismo Connect routes these requests to the associated proving scheme.
+[Sismo Connect](../../../#sismo-connect-the-crypto-native-sso) is the developer-friendly layer on top of proving schemes. It enables apps to request and verify ownership of Data Sources or associated group memberships. Sismo Connect routes these requests to the associated proving scheme.
 
 Currently, Sismo has the following proving schemes deploy_e_d:
 
@@ -28,5 +26,5 @@ Currently, Sismo has the following proving schemes deploy_e_d:
 In Hydra proving schemes, users commit the Poseidon hash of a secret and receive an EdDSA signed receipt from the Commitment Mapper. A user’s secret and the signed receipt from the Commitment Mapper form the Hydra Proof of Ownership, which is verified inside a zk-SNARK circuit—preserving user privacy.
 
 {% hint style="info" %}
-The [Commitment Mapper ](../../technical-concepts/commitment-mapper.md)is an off-chain service that privately associates a commitment with a source account during proving schemes.
+The [Commitment Mapper ](../../technical-concepts/commitment-mapper.md)is an offchain service that privately associates a commitment with a source account during proving schemes.
 {% endhint %}
diff --git a/how-sismo-works/core-components/proving-schemes/hydra-s1.md b/how-sismo-works/core-components/proving-schemes/hydra-s1.md
index d49c055..a1b190b 100644
--- a/how-sismo-works/core-components/proving-schemes/hydra-s1.md
+++ b/how-sismo-works/core-components/proving-schemes/hydra-s1.md
@@ -3,12 +3,12 @@
 The Hydra-S1 proving scheme is the first proving scheme in the Hydra family:
 
 * Hydra = using Hydra Proof of Ownership via the [Commitment Mapper](../../technical-concepts/commitment-mapper.md)
-* S1 = single source, version 1: verifying ownership of a single Data Gem
+* S1 = single source, version 1: verifying membership in a single [Data Group](../../../data-groups/data-groups-and-creation/)
 
-Currently, the proving scheme is utilized by the ZK Badge protocol **that is not maintained anymore.** It allows users to verify ownership of a Data Gem on a single Data Source and mint a ZK Badge on an unlinked Ethereum address.
+Currently, the proving scheme is utilized by the ZK Badge protocol, **which is no longer maintained.** It allows users to verify membership in a Data Group from a single Data Source and mint a ZK Badge on an unlinked Ethereum address.
 
 {% hint style="info" %}
-Sismo’s [ZK Badge protocol](https://github.com/sismo-core/sismo-badges) uses Hydra S1 Attesters to issue ZK Badges. You can see Sismo’s Hydra S1 attesters on GitHub [here](https://github.com/sismo-core/sismo-protocol/tree/main/contracts/attesters/hydra-s1). While the contracts are deployed, we stopped maintaining ZK Badge protocol.
+Sismo’s [ZK Badge protocol](https://github.com/sismo-core/sismo-badges) uses Hydra S1 proving schemes to issue ZK Badges. You can see them [here](https://github.com/sismo-core/sismo-protocol/tree/main/contracts/attesters/hydra-s1). While the contracts are still deployed, Sismo no longer maintains the ZK Badge protocol. Read more in this [blog post](https://sismo.mirror.xyz/MimvqFv45hohMwDBD9rGqY4XGZIHRR8On7nx6q9YFRc).
 {% endhint %}
 
 ## Hydra Proof of Ownership
@@ -21,8 +21,8 @@ The Hydra-S1 proving scheme allows participants to establish, in one ZK proof, t
 * A claim about their source account value is true
   * e.g: "my account value is superior to 5" (non-strict claim)
   * or "my account value is strictly equal to 5" (strict claim)
-* They correctly generated a [Proof Identifier](../../../build-with-sismo-connect/technical-documentation/vault-and-proof-identifiers.md)
+* They correctly generated a Proof Identifier
 
 {% hint style="info" %}
-Proof Identifiers can be stored by verifiers to ensure a user cannot use two ZKPs for the same function when unintended.
+A Proof Identifier functions as a nullifier for the Hydra-S1 proving scheme, preventing the same user from minting a certain ZK Badge more than once. 
 {% endhint %}
diff --git a/how-sismo-works/core-components/proving-schemes/hydra-s2.md b/how-sismo-works/core-components/proving-schemes/hydra-s2.md
index d04d900..8336e7e 100644
--- a/how-sismo-works/core-components/proving-schemes/hydra-s2.md
+++ b/how-sismo-works/core-components/proving-schemes/hydra-s2.md
@@ -7,36 +7,32 @@ The [Hydra-S2 ZK proving scheme](https://github.com/sismo-core/hydra-s2-zkps) is
 
 The proving scheme expands on the [Hydra-S1 proving scheme](hydra-s1.md) and introduces the notion of a Vault Identifier while offering a modular way of creating ZK proofs.
 
-### VaultId & Proof Identifiers
+### Vault Identifiers
 
-[VaultId](../../../build-with-sismo-connect/technical-documentation/vault-and-proof-identifiers.md) is a new notion introduced with Hydra-S2; it is an anonymous app-specific identifier that can be utilized as an in-app user ID.
+[VaultId](../../../build-with-sismo-connect/technical-documentation/vault-and-proof-identifiers.md) is a new notion introduced with the Hydra-S2 proving scheme. This VaultId is deterministically generated from a `vaultSecret` and an application identifier (`appId`) by taking the Poseidon hash of these two values. 
 
-This VaultId is deterministically generated from a `vaultSecret` and an application Identifier (`appId`) by taking the Poseidon hash of these two values.
-
-A [Proof Identifier](../../../build-with-sismo-connect/technical-documentation/vault-and-proof-identifiers.md) can be seen as the nullifier used in Hydra-S1, as far as it is deterministically generated from the Poseidon hash of a hashed sourceSecret and a requestIdentifier. The request Identifier is made of an application id, a group ID, a group timestamp, and a namespace (learn more about it in the [Sismo Connect package documentation](../../../build-with-sismo-connect/technical-documentation/)).
-
-{% hint style="info" %}
-VaultId and Proof Identifiers are two tools with different purposes. VaultId can help you to privately keep track of a user with an anonymous app-specific ID while a Proof Identifier can help you to prevent a user from using the same proof two times in your app.
-{% endhint %}
+This differs from the Proof Identifier used in the Hydra-S1 proving scheme, which functions as a nullifier—preventing the same proof from being used more than once. Meanwhile, a Vault Identifier functions as an anonymous app-specific identifier that can be utilized as an in-app user ID.
 
 ### Hydra Proof Of Ownership
 
+Hydra Proof of Ownership differs in the Hydra-S2 proving scheme as far as a new Commitment Mapper and new variable when creating commitments are being used. The secret used to generate the commitment for the trusted Commitment Mapper is now the hash of the Vault secret.
+
 [Hydra Proof of Ownership](./) also changes in Hydra-S2 as far as a new [Commitment Mapper](../../technical-concepts/commitment-mapper.md) and a new variable when creating commitments are being used. The secret used to generate the commitment for the trusted [Commitment Mapper](../../technical-concepts/commitment-mapper.md) is now the hash of the Vault secret and the user secret instead of the user secret only.
 
 $$
 Commitment = PoseidonHash(VaultSecret, AccountSecret);
 $$
 
-To allow this, we created a new commitment mapper, and we ensured that an account can only be added to one vault since the commitment is now based on the vault secret.
+To allow this, we created a new Commitment Mapper, and we ensured that a Data Source can only be added to a single Data Vault, as the commitment is now based on the Vault secret.
 
-### Optional verifications
+### Optional Verifications
 
 Hydra-S2 also offers a modular way of generating ZK proofs. Therefore, while [Hydra-S1](hydra-s1.md) obliged users to prove that they own two accounts and that the source account was in a specific [Account Tree](../../technical-concepts/accounts-registry-tree.md) (itself in a specific [Registry Tree](../../technical-concepts/accounts-registry-tree.md)) with a specific value and checking a nullifier value, we can avoid checking specific constraints in the circuits.
 
-It can be now optional to prove while using Hydra-S2 Proving Scheme:
+During the Hydra-S2 proving scheme, it is now optional to prove the following:
 
-* any account ownership via Hydra Proof Of Ownership and the new commitment generation
-* any Registry Tree or Account Tree Merkle Proof of inclusion
-* any value held by a source of data (Ethereum address, web2 account, etc.)
-* any Vault Identifier generation
-* any Proof Identifier generation
+* Any account ownership via Hydra Proof Of Ownership and the new commitment generation
+* Any Registry Tree or Account Tree Merkle Proof of inclusion
+* Any value held by a source of data (Ethereum address, web2 account, etc.)
+* Any [Vault Identifier](../../../build-with-sismo-connect/technical-documentation/vault-and-proof-identifiers.md) generation
+* Any [Proof Identifier](hydra-s1.md) generation
diff --git a/how-sismo-works/core-components/what-is-the-data-vault-1.md b/how-sismo-works/core-components/what-is-the-data-vault-1.md
index 29983b5..0d4d50a 100644
--- a/how-sismo-works/core-components/what-is-the-data-vault-1.md
+++ b/how-sismo-works/core-components/what-is-the-data-vault-1.md
@@ -1,12 +1,12 @@
 ---
-description: Encrypted storage for personal data.
+description: Sismo's data infrastructure.
 ---
 
 # Sismo Hub
 
-## What is the Sismo Hub?
+[Proving schemes](proving-schemes/) need access to data in a specific, agreed-upon format to function. The Sismo Hub is Sismo’s data infrastructure—open for anyone to use. It is the tool that standardizes raw data for Sismo, thus creating Data Groups.
 
-Proving schemes need access to data in a specific, agreed-upon format to function. The Sismo Hub is Sismo’s data infrastructure—open for anyone to use. It is the tool that standardizes raw data for the Sismo communication protocol, creating Data Groups.
+## Onchain Sources of Truth 
 
 Hydra proving schemes use onchain Merkle roots as sources of truth. The Sismo Hub generates Data Groups and transforms them into Merkle registry trees—publishing them onchain. Future proving schemes could utilize different sources of truth, such as public keys issued by centralized entities.
 
@@ -16,4 +16,4 @@ Data Groups essentially function as snapshots of a dataset at a given point in t
 While Sismo manages the maintenance of Data Groups, anyone can create and register a Data Group via the Sismo Hub—either via a pull request or the [Sismo Factory](https://factory.sismo.io/) (a no-code interface).
 {% endhint %}
 
-In addition to Data Groups, the Sismo Hub manages the creation and maintenance of Data Providers. They allow for the programmatic updates of Data Groups, further ensuring that provers and verifiers always work with the most relevant data.
+In addition to Data Groups, the Sismo Hub manages the creation and maintenance of [Data Providers](../resources/sismo-hub/data-providers.md). They allow for the programmatic updates of Data Groups, further ensuring that provers and verifiers always work with the most relevant data.
diff --git a/how-sismo-works/core-components/what-is-the-data-vault.md b/how-sismo-works/core-components/what-is-the-data-vault.md
index c7402f7..5f26aa4 100644
--- a/how-sismo-works/core-components/what-is-the-data-vault.md
+++ b/how-sismo-works/core-components/what-is-the-data-vault.md
@@ -1,21 +1,24 @@
 ---
-description: Encrypted storage for personal data.
+description: A private, local and sovereign identity aggregator.
 ---
 
 # Data Vault
 
-The Data Vault is an encrypted storage for a user’s personal data. The accounts and other credentials that users store in the Data Vault are known as Data Sources.
+The Data Vault is encrypted storage for a user’s personal data. The accounts and other credentials that users store in the Data Vault are known as Data Sources. 
 
-After aggregating their identity, users can prove ownership of Data Sources and make claims about the granular data they hold. The Data Vault is encrypted and only ever exists in its decrypted state on a user’s device.
+Currently, the following types of Data Sources can be added to the Data Vault:
 
-##
+* Web3 accounts (Ethereum addresses owned by a private key)
+* Web2 accounts (GitHub, Twitter and Telegram)
 
-

-
-{% hint style="warning" %}
-A valid Data Source can only be imported into a single Data Vault.
+{% hint style="info" %}
+A valid Data Source can only be imported into a single Data Vault. As a result, applications can verify users are unique without infringing on their privacy. This is achieved via [Vault Identifiers](../../build-with-sismo-connect/technical-documentation/vault-and-proof-identifiers.md), which function as anonymous app-specific user IDs. 
 {% endhint %}
 
+After aggregating their identity, users can prove ownership of Data Sources and make claims about the granular data they own. The Data Vault is encrypted and only ever exists in its decrypted state on a user’s device.
+
+

+
 ## Encrypted Storage
 
 When creating a Data Vault, users sign a message to generate a seed—derived deterministically from the user’s ECDSA wallet signature. The wallet address used to create the Vault is its designated owner and first Data Source.
@@ -33,6 +36,6 @@ Envision the Data Vault as an encrypted aggregator that securely stores various
 For instance, imagine a user has imported two Ethereum addresses: a public ENS domain and a private wallet holding a Gitcoin Passport. Sismo allows them to:
 
 1. Prove ownership of their public wallet (Data Source)
-2. Selectively disclose they own a Gitcoin Passport  without revealing their private wallet.
+2. Selectively disclose they own a Gitcoin Passport without revealing their private wallet.
 
 The Data Vault ensures users have full control over their aggregated digital identity, with the flexibility to authenticate and share information on their own terms. As the starting point for end users to leverage Sismo’s communication protocol, the Data Vault reshapes how users interact with applications and manage their digital presence.
diff --git a/how-sismo-works/resources/sismo-api/README.md b/how-sismo-works/resources/sismo-api/README.md
index 46f3da4..0385842 100644
--- a/how-sismo-works/resources/sismo-api/README.md
+++ b/how-sismo-works/resources/sismo-api/README.md
@@ -8,7 +8,7 @@ You found the Sismo API documentation! Here, we aim to outline all of Sismo’s
 
 The Sismo protocol makes use of data from both onchain and offchain sources. The Sismo API allows developers to fetch the data they need from either source. As the API is GraphQL-based, developers only fetch the data they request—with no unnecessary information.
 
-The goal of the Sismo API is to aggregate the on-chain & off-chain information into two GraphQL endpoints—one for production networks (Ethereum, Polygon, & Gnosis) and the other for testnets (Goerli & Mumbai). Making these endpoints public makes it extremely easy for developers to build with Sismo—pathing the way for mass adoption.
+The goal of the Sismo API is to aggregate the onchain & offchain information into two GraphQL endpoints—one for production networks (Ethereum, Polygon, & Gnosis) and the other for testnets (Goerli & Mumbai). Making these endpoints public makes it extremely easy for developers to build with Sismo—pathing the way for mass adoption.
 
 We plan to continuously update this API and pack it with as many features as possible. Any feedback is greatly appreciated. We hope you enjoy using it!
 
diff --git a/how-sismo-works/resources/sismo-api/other-models/README.md b/how-sismo-works/resources/sismo-api/other-models/README.md
deleted file mode 100644
index abee8fe..0000000
--- a/how-sismo-works/resources/sismo-api/other-models/README.md
+++ /dev/null
@@ -1,5 +0,0 @@
-# Other models
-
-{% content-ref url="transaction.md" %}
-[transaction.md](transaction.md)
-{% endcontent-ref %}
diff --git a/how-sismo-works/resources/sismo-api/other-models/transaction.md b/how-sismo-works/resources/sismo-api/transaction.md
similarity index 98%
rename from how-sismo-works/resources/sismo-api/other-models/transaction.md
rename to how-sismo-works/resources/sismo-api/transaction.md
index 3644f59..95cf488 100644
--- a/how-sismo-works/resources/sismo-api/other-models/transaction.md
+++ b/how-sismo-works/resources/sismo-api/transaction.md
@@ -76,7 +76,7 @@ type Query {
 
 ### Query stats for a list of transactions
 
-Use this query to get stats for a list of transactions. You can use [common parameters](../common-parameters.md#parameters-when-querying-a-list) to filters them. The tab Schema below provides more details.
+Use this query to get stats for a list of transactions. You can use [common parameters](common-parameters.md#parameters-when-querying-a-list) to filters them. The tab Schema below provides more details.
 
 {% tabs %}
 {% tab title="Query" %}
diff --git a/how-sismo-works/resources/sismo-hub/README.md b/how-sismo-works/resources/sismo-hub/README.md
index 3bccb84..4afd1c5 100644
--- a/how-sismo-works/resources/sismo-hub/README.md
+++ b/how-sismo-works/resources/sismo-hub/README.md
@@ -3,7 +3,7 @@
 Here you can find all the technical documentation of the [Sismo Hub repository](https://github.com/sismo-core/sismo-hub), the repository used for integrations on Sismo.
 
 {% hint style="info" %}
-Learn more about the Sismo Hub [here](../../core-components/#what-is-the-sismo-hub).
+Learn more about the Sismo Hub [here](../../core-components/what-is-the-data-vault-1.md).
 {% endhint %}
 
 ## In This Section
diff --git a/how-sismo-works/resources/sismo-hub/data-operators.md b/how-sismo-works/resources/sismo-hub/data-operators.md
index b93b607..2143541 100644
--- a/how-sismo-works/resources/sismo-hub/data-operators.md
+++ b/how-sismo-works/resources/sismo-hub/data-operators.md
@@ -2,13 +2,13 @@
 
 #### Data Operators
 
-Data Operators is an helper to create new groups by combining existing groups.
+Data Operators are helpers to create new Data Groups by combining existing ones.
 
-Currently, there are 3 data operators:
+Currently, there are 3 Data Operators:
 
-* `Union`: join multiples groups data together
-* `Intersection`: take the intersection between 2 groups data
-* `Map`: map values of a group data with an other value
+* `Union`: join multiples groups of data together
+* `Intersection`: take the intersection between 2 groups of data
+* `Map`: map values of a group data with another value
 * `Aggregation`: aggregate the value with multiples groups 
 
 ```typescript
diff --git a/how-sismo-works/resources/sismo-hub/data-providers.md b/how-sismo-works/resources/sismo-hub/data-providers.md
index 5212297..f2cb249 100644
--- a/how-sismo-works/resources/sismo-hub/data-providers.md
+++ b/how-sismo-works/resources/sismo-hub/data-providers.md
@@ -56,8 +56,8 @@ The above information displays how to use data from external sources. Below, you
 
 **You can find here a complete tutorial describing all the Data Provider creation process steps:**
 
-{% content-ref url="../../../data-groups/data-groups-and-how-to-create-them/create-your-data-provider.md" %}
-[create-your-data-provider.md](../../../data-groups/data-groups-and-how-to-create-them/create-your-data-provider.md)
+{% content-ref url="../../../data-groups/data-groups-and-creation/create-your-data-provider.md" %}
+[create-your-data-provider.md](../../../data-groups/data-groups-and-creation/create-your-data-provider.md)
 {% endcontent-ref %}
 
 ## Create a new Data Provider
diff --git a/how-sismo-works/resources/sismo-hub/sismo-protocol-overview.md b/how-sismo-works/resources/sismo-hub/sismo-protocol-overview.md
index 37939e0..5efcedf 100644
--- a/how-sismo-works/resources/sismo-hub/sismo-protocol-overview.md
+++ b/how-sismo-works/resources/sismo-hub/sismo-protocol-overview.md
@@ -5,7 +5,7 @@ coverY: 0
 
 # Group Generators
 
-Groups are a reusable tool used by Sismo to generate available Data Groups for proving schemes.
+Groups are a reusable tool used by Sismo to generate available Data Groups for [proving schemes](../../core-components/proving-schemes/).
 
 You will find more information on what are groups in this section:
 
@@ -19,8 +19,8 @@ You will be able to create your own group of accounts (Ethereum addresses, Githu
 
 **Here is a complete tutorial describing all the group creation process steps:**
 
-{% content-ref url="../../../data-groups/data-groups-and-how-to-create-them/create-your-group-generator.md" %}
-[create-your-group-generator.md](../../../data-groups/data-groups-and-how-to-create-them/create-your-group-generator.md)
+{% content-ref url="../../../data-groups/data-groups-and-creation/create-your-group-generator.md" %}
+[create-your-group-generator.md](../../../data-groups/data-groups-and-creation/create-your-group-generator.md)
 {% endcontent-ref %}
 
 The following documentation aims to describe the code in a more theoretical way, we strongly recommend doing the tutorial to understand what the code below is for, especially for newcomers.
diff --git a/how-sismo-works/technical-concepts/README.md b/how-sismo-works/technical-concepts/README.md
index 9ef0373..f1f62d7 100644
--- a/how-sismo-works/technical-concepts/README.md
+++ b/how-sismo-works/technical-concepts/README.md
@@ -4,11 +4,7 @@ description: Understand Sismo's underlying technical concepts.
 
 # Technical Concepts
 
-This section is designed to provide a detailed understanding of the key concepts that form the foundation of the Sismo communication protocol. By unraveling these concepts, you will gain a deeper understanding of how Sismo operates and the technology that powers its communication protocol.
-
-### In This Section
-
-In the proceeding pages of this documentation, you will find in-depth explanations of the following technical concepts:
+In the proceeding pages of this documentation, you can find in-depth explanations of the following technical concepts:
 
 * [**Accounts Registry Tree**](accounts-registry-tree.md)**:** Learn about how Accounts Registry Trees are used to store available Data Groups.
 * [**Commitment Mapper**](commitment-mapper.md)**:** An offchain service that facilitates Sismo's zero-knowledge functionality.
diff --git a/how-sismo-works/technical-concepts/accounts-registry-tree.md b/how-sismo-works/technical-concepts/accounts-registry-tree.md
index 03c3dc2..752a640 100644
--- a/how-sismo-works/technical-concepts/accounts-registry-tree.md
+++ b/how-sismo-works/technical-concepts/accounts-registry-tree.md
@@ -1,48 +1,46 @@
 # Accounts Registry Tree
 
-Accounts Registry Trees are used by some attesters as a data structure to store their available groups.
+Accounts Registry Trees are used to structure data and store it onchain in the form of [Data Groups](broken-reference). As a result, users can participate in [proving schemes](../core-components/proving-schemes/) and prove facts about data aggregated in their [Data Vault](../core-components/what-is-the-data-vault.md). 
 
 ### Key-Value Merkle tree
 
-A KV Merkle tree is a key-value store enhanced with a merkle tree. The merkle tree stores in its leaves the following data: hash(key, value).
+A KV Merkle tree is a key-value database enhanced with a Merkle tree. The Merkle tree stores the following data: hash(key, value). 
 
 ### Accounts Tree
 
-An Accounts Tree is a KV Merkle tree where the keys and values are accounts (e.g keys = account identifiers, values = accounts values)
+An Accounts Tree is a KV Merkle tree where the keys and values are accounts (e.g. keys = account identifiers, values = accounts values).
 
-This makes it easy and cheap for a verifier with access to the root of the tree (say a smart contract) to verify that a prover (a user) owns an account in the KV store. 
+This makes it easy and cheap for a verifier with access to the root of the tree (e.g. a smart contract) to verify that a prover (a user) owns an account in the KV database. This prover just has to send the Merkle proof to the verifier.
 
-This prover just has to send the merkle proof to the verifier
-
-![Accounts tree structure](<../../.gitbook/assets/Merkle Tree1 (3).png>)
+![](<../../.gitbook/assets/Merkle Tree1 (3).png>)
 
 {% hint style="info" %}
-An Accounts Tree can store a group of accounts.
+An Accounts Tree can store a group of accounts (i.e. a [Data Group](../../data-groups/data-groups-and-creation/)).
 
-An example of such group:
+For example:
 
-* account identifiers:  all addresses that voted in the ENS DAO
-* account values: the number of submitted voted for each address
-* (group identifier): 3
+* Account identifiers — all addresses that voted in the ENS DAO
+* Account values — the number of votes submitted for each address
+* (Group identifier): 3
 
-A user (owner of `0x123..def`) can easily prove to a smart contract (an attester with access to the root) that they voted 5 times.
+A user (owner of `0x123..def`) can easily prove to a smart contract with access to the root) that they voted 5 times.
 
 They just need to provide the following information:
 
 * Proof of `0x123..def` ownership: signature of a message with their private key
 * 5: the account value
-* merkle proof (data needed for the attester to reconstruct the accounts tree root)
+* Merkle proof (data needed for the smart contract to reconstruct the Accounts Tree root)
 
 The attester will then just need to:
 
-* verify the signature
-* compute the leaf = hash(`0x123..def,5)`
-* Verify the merkle proof (hashing the leaf against the merkle proof elements to check whether it corresponds to the accounts tree root)
+* Verify the signature
+* Compute the leaf = hash(`0x123..def,5)`
+* Verify the Merkle proof (hashing the leaf against the Merkle proof elements to check whether it corresponds to the Accounts Tree root)
 {% endhint %}
 
 ### Registry tree
 
-The registry tree is another KV merkle tree where the key is an accounts tree root, and the value a specific value linked to the accounts tree (e.g for Hydra-S1 we chose the groupIndex as the accounts tree value)
+The registry tree is another KV Merkle tree where the key is an accounts tree root, and the value is a specific value linked to the accounts tree (e.g. for Hydra-S1, we choose the groupIndex as the accounts tree value). 
 
 ![Registry tree structure](<../../.gitbook/assets/Merkle Tree2.png>)
 
@@ -56,17 +54,13 @@ We can register the previous accounts tree of ENS Voters in the Registry tree wi
 Users will then be able to prove to a verifier (that only has access to the registry tree root) that:
 
 * They have an account that's part of one of the accounts trees registered
-* The accounts tree they are a part of has the value of 3
+* The accounts tree they are a part of has a value of 3
 
-\=> They will have effectively proved they are part of the group 3!
+\=> They will have effectively proved they are part of group 3!
 {% endhint %}
 
 ![Registry tree structure](<../../.gitbook/assets/Merkle Tree3.png>)
 
-### Hydra-S1 Attesters
-
-Hydra-S1 Attester uses this scheme to enable users to prove they have accounts that are part of groups.
-
-The proof of ownership is a bit more complex than signing a message, but the general flow is exactly the same.
+### Hydra Proving Schemes
 
-The scheme is done in a ZK-SNARK which makes it impossible for anyone to know which account was used to prove that they are part of a group with a specific account!
+Hydra [proving schemes](../core-components/proving-schemes/) use Account Registry Trees to enable users to prove they are part of a [Data Group](../../data-groups/data-groups-and-creation/). Generating proof of ownership is more complex than simply signing a message, but the general flow is exactly the same. As the scheme is done in a zk-SNARK, it is impossible for anyone to know which account was used.
diff --git a/how-sismo-works/technical-concepts/commitment-mapper.md b/how-sismo-works/technical-concepts/commitment-mapper.md
index ea719a6..0a607d2 100644
--- a/how-sismo-works/technical-concepts/commitment-mapper.md
+++ b/how-sismo-works/technical-concepts/commitment-mapper.md
@@ -1,6 +1,6 @@
 # Commitment Mapper
 
-The Commitment Mapper, provided by Sismo, is a trusted offchain service housed in an isolated infrastructure. It allows account owners to transform proof of account ownership into proof of secret knowledge. The account owner receives a receipt from the Commitment Mapper, which connects their account to their commitment (e.g., the hash of their secret). This combination of the user's secret and the Commitment Mapper receipt forms the Delegated Proof of Ownership. The commitment can be used in zero-knowledge (ZK) systems as a [Vault or Proof Identifier](../../build-with-sismo-connect/technical-documentation/vault-and-proof-identifiers.md).
+The Commitment Mapper, provided by Sismo, is a trusted offchain service housed in an isolated infrastructure. It allows account owners to transform proof of account ownership into proof of secret knowledge. The account owner receives a receipt from the Commitment Mapper, which connects their account to their commitment (e.g., the hash of their secret). This combination of the user's secret and the Commitment Mapper receipt forms the Delegated Proof of Ownership. The commitment can be used in zero-knowledge (ZK) systems as a [Vault Identifier](../../build-with-sismo-connect/technical-documentation/vault-and-proof-identifiers.md).
 
 ## How It Works
 
@@ -25,7 +25,7 @@ The user can then use this receipt to prove in a SNARK that they know the secret
 
 ## Why Use The Commitment Mapper?
 
-In constrained environments like zk-SNARK circuits, traditional proofs of ownership become impractically expensive. Sismo alleviates this problem by using the Commitment Mapper signing with an EdDSA address, which is cheaper to prove and verify in a SNARK.
+In constrained environments like zk-SNARK circuits, traditional proofs of ownership become impractically expensive. Sismo alleviates this problem by using the Commitment Mapper signing with an EdDSA address, which is cheaper to prove and verify in a zk-SNARK.
 
 ## Security Model
 
@@ -40,7 +40,7 @@ Sismo follows best practices with high web2 security in mind when deploying the
 * The Commitment Mapper is executed using an AWS Lambda deployed in an isolated infrastructure, within a dedicated AWS account.
 * Private keys are stored using AWS KMS.
 * Actions made inside the AWS account are traced, stored in another account, and cannot be modified, allowing for precise auditing.
-* Alerts are sent to the entire Sismo team if actions occur inside this AWS account.
+* Alerts are sent to the Sismo team if actions occur inside this AWS account.
 
 {% hint style="info" %}
 The Commitment Mapper code and its terraform deployment are open-source and accessible here: [https://github.com/sismo-core/sismo-commitment-mapper](https://github.com/sismo-core/sismo-commitment-mapper).
@@ -48,4 +48,4 @@ The Commitment Mapper code and its terraform deployment are open-source and acce
 
 ## The Future
 
-Sismo is developing a new version of the Commitment Mapper that will require less trust. Operations within the Commitment Mapper will be executed inside a SNARK and verified onchain.
+Sismo is developing a new version of the Commitment Mapper that will require less trust. Operations within the Commitment Mapper will be executed inside a zk-SNARK and verified onchain.