0xPolygonID · Nityam573 · Jul 16, 2025 · Jul 16, 2025 · Jul 16, 2025
diff --git a/.env.sample b/.env.sample
diff --git a/docs/verifier/features.md b/docs/verifier/features.md
@@ -5,7 +5,7 @@ sidebar_label: Features
 description: Verifier main features.
 keywords:
   - docs
-  - polygon id
+  - privado id
   - ID holder
   - verifier
   - selective disclosure
@@ -15,10 +15,10 @@ keywords:
 
 ## Selective Disclosure
 
-There are two types of proof requests: private proof and selective disclosure. In private proof requests, the credential attribute values are not disclosed, and the response is true/false of the requested value.
+There are two types of proof requests: private proof and selective disclosure. In private proof requests, the credential attribute values are not disclosed, and the response is true/false for the requested value.
 In selective disclosure requests, the verifier asks for one attribute value from the credential to be disclosed.
 
-The selective disclosure has almost the same technical flow as the proof request, the only difference is that the query in the QR code from the proof request of the verifier contains a different format. The SDK just calls the authenticate method from `iden3comm.dart` with the `iden3MessageEntity` as a parameter.
+The **selective disclosure** has almost the same technical flow as the proof request, the only difference is that the query in the QR code from the proof request of the verifier contains a different format. The SDK just calls the authenticate method from `iden3comm.dart` with the `iden3MessageEntity` as a parameter.
 
 :::info
 

diff --git a/docs/verifier/on-chain-verification/overview.md b/docs/verifier/on-chain-verification/overview.md
@@ -14,7 +14,7 @@ keywords:
 
 import useBaseUrl from '@docusaurus/useBaseUrl';
 
-The on-chain verification workflow allows dApps to verify users' credentials inside a Smart Contract. Zero-Knowledge Proof cryptography enables this verification to happen privately, that means, without revealing any personal information of the user (prover).
+The on-chain verification workflow allows dApps to verify users' credentials inside a Smart Contract. Zero-Knowledge Proof cryptography enables this verification to happen privately, this means, without revealing any personal information of the user (prover).
 
 This flow is especially needed in cases where further on-chain logic needs to be implemented on successful verification such as:
 
@@ -29,9 +29,9 @@ Before describing on-chain verification details, it's important to emphasize tha
 
 You can inherit `EmbeddedZKPVerifier` smart contract or link to pre-deployed `UniversalVerifier` contract. Both of the contracts share the same parent class and implement the same `IZKPVerifier` interface, which defines methods to set, get, and submit responses for Proof Requests.
 
-However, as `EmbeddedZKPVerifier` is added to client custom contract that means that all verification result are stored in the state of a client contract. Whenever you need to use on-chain verification for a new contract, you need to re-submit all the proof responses to it.
+However, as `EmbeddedZKPVerifier` is added to client's custom contract that means that all verification result are stored in the state of a client contract. Whenever you need to use on-chain verification for a new contract, you need to resubmit all the proof responses to it.
 
-On the other hand, `UniversalVerifier` is deployed as a standalone contract and acts as a central register of proof verifications. Once a proof is submitted for specific proof request, is can be used in many different client contracts.
+On the other hand, `UniversalVerifier` is deployed as a standalone contract and acts as a central register of proof verifications. Once a proof is submitted for specific proof request, it can be used in many different client contracts.
 
 
 ## On-chain verification flow
@@ -43,14 +43,14 @@ On the other hand, `UniversalVerifier` is deployed as a standalone contract and
 </div>
 
 1. After having deployed a client custom contract with inherited `Embedded ZKP Verifier`, the Verifier designs and sets a [Proof Request](#set-the-zkp-request) with `setRequest` contract method.
-1. The Request is generated at verifier backend and delivered to a user within a QR code (or via deep-linking, depending on the implementation).
-1. The user scans the QR code using his/her mobile ID wallet and parses the request.
-1. A ZK proof is generated on mobile or web wallet according to the request of the website and based on the credentials held in his/her wallet.
-1. The user sends the ZK proof to the Verifier Smart Contract via `submitZKPResponse` or `submitZKPResponseV2` method.
-1. The Verifier Smart Contract verifies the ZK Proof.
-1. The Verifier Smart Contract checks that the State of the Issuer of the credential and the State of the user are still valid and have not been revoked.
-1. If the verification is successful, the proof status is recorded on-chain. 
-1. Now the Verifier Contract may execute a custom business logic (e.g. minting tokens), which may check the proof status and occurs in the same transaction.
+2. The Request is generated at verifier backend and delivered to a user within a QR code (or via deep-linking, depending on the implementation).
+3. The user scans the QR code using his/her mobile ID wallet and parses the request.
+4. A ZK proof is generated on mobile or web wallet according to the request of the website and based on the credentials held in his/her wallet.
+5. The user sends the ZK proof to the Verifier Smart Contract via `submitZKPResponse` or `submitZKPResponseV2` method.
+6. The Verifier Smart Contract verifies the ZK Proof.
+7. The Verifier Smart Contract checks that the State of the Issuer of the credential and the State of the user are still valid and have not been revoked.
+8. If the verification is successful, the proof status is recorded on-chain. 
+9. Now the Verifier Contract may execute a custom business logic (e.g. minting tokens), which may check the proof status and occur in the same transaction.
 
 Note that the Verifier only sets the Request at step 1. All the rest of the interaction is between a User and the Smart Contract. All the verification logic is executed programmatically inside the Smart Contract.
 

diff --git a/docs/verifier/on-chain-verification/set-zkp-request.md b/docs/verifier/on-chain-verification/set-zkp-request.md
@@ -16,33 +16,41 @@ import useBaseUrl from '@docusaurus/useBaseUrl';
 
 ### Approach - A Setting Request using Query Builder:
 
-1. Visit the [PrivadoID Query Builder](https://tools.privado.id/query-builder) and paste the JSON-LD Context URL (mentioned above) in the input box.
-2. Select the schema type to `pohcheck` and select the `human` in the Attribute field.
+1. Visit the [PrivadoID Query Builder](https://tools.privado.id/query-builder) and paste the JSON-LD Context URL (mentioned below).
+`ipfs://QmfEEiU1UqkH5eXSFurSbu6g87k6R6YhKtxyRnd534Wn6E`
+
+2. Select the schema type to `Proof of Age`, click on `Add condition` and select the `minAgeRange` in the Attribute field.
 <div align="center">
     <img width="600" src={useBaseUrl("img/onchain-verifier/querybuilder-1.png")}></img>
 </div>
-
-3. Select the Proof type "Signature-based (SIG)" and Circuit ID Credential Atomic Query v3 On Chain.
-
-4. Set the query type as Condition and Operator as "Is equal to," and select `true` in the Attribute value.
-
-5. Set the Issuer DID field to "*" to accept credentials from any issuer or, if you want, you can use any specific DID to restrict allowed issuers for the query.
+<br/>
 <div align="center">
     <img width="600" src={useBaseUrl("img/onchain-verifier/querybuilder-2.png")}></img>
 </div>
 
-6. Next, click on the **“Create query”**.
+3. Set the Issuer DID field to "*" to accept credentials from any issuer or, if you want, you can use any specific DID to restrict allowed issuers for the query.
+
+4. Set the Operator as "Is equal to," and input value `20` in the Attribute value
+
+5. Select verification type as `on-chain` and click on Advanced options and select the Proof type `BJJSignature2021` and Circuit ID `Credential Atomic Query v3`.
 
-7. Add the Universal Verifier Smart contract address for the selected network (e.g., for Polygon Amoy: `0xfcc86A79fCb057A8e55C6B853dff9479C3cf607c`) in the Smart Contract Address input.
 <div align="center">
     <img width="600" src={useBaseUrl("img/onchain-verifier/querybuilder-3.png")}></img>
 </div>
+<br/>
+<div align="center">
+    <img width="600" src={useBaseUrl("img/onchain-verifier/querybuilder-4.png")}></img>
+</div>
 
-8. Click on the **Set request** to submit the on-chain request.
+6. Add the Universal Verifier Smart contract address for the selected network (e.g., for Polygon Amoy: `0xfcc86A79fCb057A8e55C6B853dff9479C3cf607c`) in the Smart Contract Address input.
 
-9. Click on **Confirm** in the Metamask to accept and submit the request.
+7. Click on the **Set query** to submit the on-chain request.
+
+8. Click on **Confirm** in the Metamask to accept and submit the request.
+
+9. Next, click on the **“Test query”**.
 <div align="center">
-    <img width="600" src={useBaseUrl("img/onchain-verifier/querybuilder-4.png")}></img>
+    <img width="600" src={useBaseUrl("img/onchain-verifier/querybuilder-5.png")}></img>
 </div>
 
 :::note

diff --git a/docs/verifier/query-builder.md b/docs/verifier/query-builder.md
@@ -5,7 +5,7 @@ sidebar_label: Query Builder
 description: Learn how to use the Query Builder.
 keywords:
   - docs
-  - polygon id
+  - privado id
   - ID holder
   - issuer
   - verifier
@@ -23,7 +23,7 @@ keywords:
 
 import useBaseUrl from '@docusaurus/useBaseUrl';
 
-The Query Builder, available [here](https://schema-builder.polygonid.me/query-builder), is an intuitive, web-based tool designed to simplify the creation of verification queries. It's particularly useful for verifiers looking to establish specific criteria for identity verification, such as organizational membership or age requirements. By leveraging Polygon ID, the Query Builder offers a secure and efficient method for users to authenticate identities based on these criteria.
+The Query Builder, available [here](https://tools.privado.id/query-builder), is an intuitive, web-based tool designed to simplify the creation of verification queries. It's particularly useful for verifiers looking to establish specific criteria for identity verification, such as organizational membership or age requirements. By leveraging Privado ID, the Query Builder offers a secure and efficient method for users to authenticate identities based on these criteria.
 
 ## Features
 
@@ -48,12 +48,20 @@ Here's a glimpse of the main user interface of the Query Builder:
 <img src={useBaseUrl("img/query-builder.png")} align="center" width="600"/>
 </div>
 <br/>
+<div align="center">
+<img src={useBaseUrl("img/query-circuit.png")} align="center" width="600"/>
+</div>
+<br/>
+<div align="center">
+<img src={useBaseUrl("img/query-test.png")} align="center" width="600"/>
+</div>
+<br/>
 
 ## Building a query
 
 ### URL to JSON-LD Context
 
-To create a query, it is essential to reference the correct schema, specifically its JSON-LD Context's URL. Users have two options: they can either enter a URL pointing to a JSON-LD Context or utilize one from the [Schema Explorer](https://schema-builder.polygonid.me). By starting to type the name (or any other keyword) of the desired schema in the Schema Explorer, a list of available schemas will appear, allowing the user to select the appropriate one.
+To create a query, it is essential to reference the correct schema, specifically its JSON-LD Context's URL. Users have two options: they can either enter a URL pointing to a JSON-LD Context or utilize one from the [Schema Explorer](https://tools.privado.id/). By starting to type the name (or any other keyword) of the desired schema in the Schema Explorer, a list of available schemas will appear, allowing the user to select the appropriate one.
 
 <div align="center">
 <img src={useBaseUrl("img/query-builder-url.png")} align="center" width="600"/>
@@ -73,6 +81,9 @@ Credentials consist of various primitive attributes such as strings, integers, b
 <div align="center">
 <img src={useBaseUrl("img/query-builder-attribute-field.png")} align="center" width="600"/>
 </div>
+<div align="center">
+<img src={useBaseUrl("img/query-add-condition.png")} align="center" width="600"/>
+</div>
 <br/>
 
 ### Proof type
@@ -132,9 +143,9 @@ The protocol allows selection between three query types:
 
 1. **Condition:** This type allows the prover to demonstrate that a specific condition is met without revealing the underlying data. It maintains data privacy by cryptographically verifying the condition. An example is proving legal age for entry into a venue without disclosing the actual age.
 
-2. **Selective disclosure:** Use this when you need the prover to reveal specific data stored in their credential. This option discloses the actual value of an attribute to the verifier. For instance, instead of just requesting proof proving legal age, it would disclose the prover's actual age to the verifier.
+2. **Selective disclosure:** Use this when you need the prover to reveal specific data stored in their credential. This option discloses the actual value of an attribute to the verifier. For instance, instead of just requesting proof of legal age, it would disclose the prover's actual age to the verifier.
 
-3. **Credential issued:** Use this when you need the prove that credential with a specific type has been issued, but not to reveal any information.
+3. **Credential issued:** Use this when you need to prove that a credential with a specific type has been issued, but not to reveal any information.
 
 Choose "Condition" for privacy-preserving verification, "Selective disclosure" for cases where revealing specific information is necessary, "Credential issued" when you need to ensure the fact of credential issuance.
 
@@ -198,7 +209,7 @@ The verification of queries off-chain is a straightforward process:
 2. **Scan QR Code:** Use the prover's wallet to scan this QR code.
 3. **Credential Validation:** The wallet checks for the existence of the credential and verifies all query requirements, including issuer DID, revocation status, and specified conditions.
 4. **Zero-Knowledge Proof Generation:** If the criteria are met, a zero-knowledge proof is generated. This proof serves as cryptographic evidence that the prover's credential is valid and fulfills all aspects of the query.
-5. **Receiving Proof:** The zero-knowledge proof is returned as a JWZ token, which can be decoded using the [JWZ tool](https://jwz.polygonid.me/).
+5. **Receiving Proof:** The zero-knowledge proof is returned as a JWZ token, which can be decoded using the [JWZ tool](hhttps://jwz-validator.privado.id/).
 
 For a detailed walkthrough, refer to the provided video illustrating the complete process of creating and verifying an off-chain query.
 

diff --git a/docs/verifier/v3-circuit.md b/docs/verifier/v3-circuit.md
@@ -5,25 +5,25 @@ sidebar_label: V3 circuit (Beta)
 description: Verifier main features.
 keywords:
   - docs
-  - polygon id
+  - privado id
   - ID holder
   - circuit
   - v3
 ---
 
 ## New circuits available
 
-We want to introduce new circuits - СredentialAtomicQueryV3 and CredentialAtomicQueryV3Onchain
+We are introducing two new circuits — CredentialAtomicQueryV3 and CredentialAtomicQueryV3Onchain
 
 :::warning
 
-    Circuits are in the beta version. Trusted setup will be performed in the next release.
+    These circuits are in beta. The trusted setup will be completed in the next release.
     Newest version is СredentialAtomicQueryV3-beta.1
 
   <details><summary>Changelog from beta.0 to beta.1</summary>
 
     1. ValueArrSize input is introduced, which fixes behaviour for IN / NIN operations.
-    2. Exists / Noop / Less Than Or Equal / Greater Than or Equal /  Not between / Between operators support.
+    2. Support for Exists / Noop / Less Than Or Equal / Greater Than Or Equal / Not Between / Between operators.
     3. Query hash calculation algorithm changes.
     4. Constraints and security optimizations.
 
@@ -35,7 +35,7 @@ More about new supported operators [here](./verification-library/zk-query-langua
 
 Link to latest sdk circuit wrappers: [js](https://github.com/0xPolygonID/js-sdk/pull/181) / [go](https://github.com/iden3/go-circuits/releases/tag/v2.1.0)
 
-In general it's an improved version of V2 circuits with several important key features:
+Overall, it is an improved version of the V2 circuits with several important features:
 
 1. SIG and MTP checks are united in single circuit. Now you can use only one circuit without sig/mtp suffixes. Proof will be taken from user wallet and authorization response will contain information about verifiable credential proof type which has been used. It is possible to request the needed proof from user by using `proofType` property in the authorization request message. Possible values are `Iden3SparseMerkleTreeProof` and `BJJSignature2021`. If `proofType` is not provided - available proof will be used. In case there are two proofs available - MTP will be used as more prior.
 
@@ -56,7 +56,7 @@ In general it's an improved version of V2 circuits with several important key fe
 
 2. Support of new type of operators modifiers: now selective disclosed value will be present in the output value - this will give a possibility for onchain verification to work with selective disclosure workflows. The format of the request hasn't been changed.
 
-3. Support of nullifiers generation for proof of uniqueness use cases. Imagine the scenario when verifier needs to make sure that credential can be used only once for the proof generation from specific user. Now it's possible. If credential is issued on profile, verifier id is present and nullifier session id is provided - unique value for such credential will be generated and persist in the proof outputs.
+3. Support of nullifiers generation for proof of uniqueness use cases. Imagine the scenario when verifier needs to make sure that credential can be used only once for the proof generation from specific user. This is now possible, if a credential is issued on a profile, the verifier ID is present, and a nullifier session ID is provided - unique value for such credential will be generated and persist in the proof outputs.
 
 ```json
 ...
@@ -75,8 +75,8 @@ In general it's an improved version of V2 circuits with several important key fe
 ...
 ```
 
-4. For onchain circuit now it is possible to disable default authentication. Ethereum-based identities can generate zero-knowledge proofs without having the bjj keys, and verification will be successful.
-   In this scenario user id myst be derived from the sender address. Bellow is an example of V3 circuit.
+4. For onchain circuit now it is possible to disable default authentication. Ethereum-based identities can generate zero-knowledge proofs without having the BJJ keys, and verification will be successful.
+   In this scenario user id must be derived from the sender address. Below is an example of a V3 circuit.
 
 ```js
 
@@ -90,7 +90,7 @@ In general it's an improved version of V2 circuits with several important key fe
 
 Beta Validator is also deployed: [Repository](https://github.com/0xPolygonID/contracts)
 
-1. Possibility to use linked proofs. This means that verifier can be sure that user used the same credential to proof different queries. This is achievable by using `groupId` property in the proof request.
+5. Possibility to use linked proofs. This means the verifier can be sure that the user used the same credential to prove different queries. This is achievable by using `groupId` property in the proof request.
 
 ```json
 ...
@@ -144,7 +144,7 @@ Example of complex request with v3 circuit proof request:
         },
         "query": {
           "groupId": 1,
-          "proofType": "BJJSignature",
+          "proofType": "BJJSignature2021",
           "allowedIssuers": ["*"],
           "context": "https://raw.githubusercontent.com/iden3/claim-schema-vocab/main/schemas/json-ld/kyc-v101.json-ld",
           "type": "KYCEmployee",