fixed issuer docs

docs/faqs/content/verifier-on-chain-verification-gas-costs.md

@@ -17,9 +17,16 @@ Can you explain the necessity of gas fees for on-chain verification?
 
 ## Answer
 
-On-chain verification of zero-knowledge proofs (ZKPs) is a computationally intensive process that requires significant resources from the blockchain network. This process relies on advanced cryptographic techniques, specifically pairings cryptography, to ensure the validity and security of transactions without revealing underlying private information.
+On-chain verification of zero-knowledge proofs (ZKPs) is a computationally intensive process that requires significant resources from the blockchain network. This process relies on advanced cryptographic techniques to ensure the validity and security of transactions without revealing underlying private information.
 
-The computational complexity of these verifications is reflected in their gas costs, which serve as a payment for the computational resources consumed by the network to perform these operations. For a full verification flow, the gas costs are approximately 770k for v3 circuit proofs and around 700k for v2 circuit proofs. The verification step alone typically consumes about 500k gas.
+The computational complexity of these verifications is reflected in their gas costs, which serve as a payment for the computational resources consumed by the network to perform these operations. For a full on-chain verifier flow, the gas costs are approximately **1.245 million gas**. At the current rate of 25 Gwei per Gas on Polygon, this equates to approximately **0.031125 POL** (less than one cent USD as of July 2025).
+
+The on-chain verification process typically consists of the following steps:
+
+- The **setZKPRequest** step, which takes approximately **325,000 gas** ([example transaction](https://polygonscan.com/tx/0x14f8ce081ced29317c4cb391e23c165411bb3da68498dd78d2270c65a387a969)).
+- The **submitZKPResponseV2** step, which takes approximately **920,000 gas** ([example transaction](https://polygonscan.com/tx/0xf3e541bfcb8e3f0ee665e8c392ca94c5eec491ffea13cf83b42c28337ed9ea20)).
+
+A full history of transactions for the Universal Verifier contract on Polygon can be found [here](https://polygonscan.com/address/0xfcc86a79fcb057a8e55c6b853dff9479c3cf607c).
 
 Gas fees are a crucial component of on-chain verification processes, compensating network validators or miners for the computational power required to secure and execute these complex cryptographic operations. Without these fees, it would be challenging to incentivize the maintenance and security of blockchain networks, especially when performing specialized tasks such as ZKP verifications.
 

docs/introduction.md

@@ -20,7 +20,7 @@ Privado ID’s identity infrastructure facilitates trusted and secure relationsh
 
 ## Why Privado ID?
 
-Privado ID, with the help of zero-knowledge proofs, lets users prove their identity without the need of exposing their private information. This ensures both the **Freedom of Expression** and **Privacy by Default** (user's identities are secured by zero-knowledge cryptography).
+Privado ID, with the help of zero-knowledge proofs, lets users prove their identity without the need to expose their private information. This ensures both the **Freedom of Expression** and **Privacy by Default** (user's identities are secured by zero-knowledge cryptography).
 
 ## Core Concepts of Privado ID: Verifiable Credentials, Identity Holder, Issuer and Verifier
 
@@ -42,19 +42,19 @@ The architecture of the framework is composed of three modules: Identity Holder,
 
 The simplest example of a Verifier is a bar that wants to verify if a client is over 18. In the real world, the Identity Holder would need to provide an ID and show all their personal information. With Privado ID, they only need to pass a proof.
 
-A core concept here is the _trust_ that must exist between a Verifier and an Issuer: the fact that the information contained inside a VC is cryptographically verifiable doesn't guarantee it's true. The Issuer must be a trusted and reputable party so that Verifier can consume the VCs originated by that Issuer.
+A core concept here is the _trust_ that must exist between a Verifier and an Issuer: the fact that the information contained inside a VC is cryptographically verifiable doesn't guarantee that it is true. The Issuer must be a trusted and reputable party so that Verifier can consume the VCs originated by that Issuer.
 
 <div align="center">
 <img src= {useBaseUrl('/img/triangle-of-trust-simple.png')} align="center" width="700"/>
 </div>
 
 ## Role of a Wallet
 
-A [Wallet](./wallet/wallet-overview.md) plays a crucial role in the seamless exchange of VCs with the Issuer, on one hand, and proofs with the Verifier, on the other. As stated above, an Identity Holder carries their personal data, in the form of VC, within their wallet. At its core, the wallet stores the private key of a user, fetch VCs from the Issuer, and create zero-knowledge proofs to be presented to the Verifier. Being the carrier of the sensitive information, the Wallet has been designed to ensure that the identity of its Holder is protected and preserved, and no sensitive data can be revealed to the third party without the consent of the Holder.
+A [Wallet](./wallet/wallet-overview.md) plays a crucial role in the seamless exchange of VCs with the Issuer, on one hand, and proofs with the Verifier, on the other. As stated above, an Identity Holder carries their personal data, in the form of VC, within their wallet. At its core, the wallet stores the private key of a user, fetches VCs from the Issuer, and create zero-knowledge proofs to be presented to the Verifier. Being the carrier of the sensitive information, the Wallet has been designed to ensure that the identity of its Holder is protected and preserved, and no sensitive data can be revealed to the third party without the consent of the Holder.
 
 ## What Can you Achieve Using Privado ID?
 
-1. **Privacy using Zero-Knowledge Proofs**: An Identity Holder, using zero-knowledge proofs, can keep thier personal data private. During the process of VC verification, it just needs to show a proof that they are the owner of a VC that matches certain criteria without letting the Verifier know of the actual VC. For example, an Identity Holder can prove to a Verifier authority that they are above 18 years of age by presenting the proof without revealing their actual age. This ensures minimum data exposure and hence confirms the safety of any sensitive data.
+1. **Privacy using Zero-Knowledge Proofs**: An Identity Holder, using zero-knowledge proofs, can keep their personal data private. During the process of VC verification, it just needs to show a proof that they are the owner of a VC that matches certain criteria without letting the Verifier know of the actual VC. For example, an Identity Holder can prove to a Verifier authority that they are above 18 years of age by presenting the proof without revealing their actual age. This ensures minimum data exposure and hence confirms the safety of any sensitive data.
    Another aspect of privacy comes from the fact that the Issuer would not be able to track the usage of VCs by an individual once it has been issued.
 
 2. **Off-Chain and On-Chain Verification**: Verification of proofs can be done either off-chain or on-chain via Smart Contracts. For example, developers can set up a contract that airdrops tokens only to users that meet certain criteria based on their VCs.

docs/issuer-node/issuer-node-api/agent/apis.md

@@ -14,7 +14,7 @@ keywords:
   - agent
 ---
 
-The agent endpoint acts as a port to communicate messages between the mobile app and the server. The user, using the agent endpoint, can access the functionality through his/her mobile app.
+The agent endpoint acts as a port to communicate messages between the mobile app and the server. The user, using the agent endpoint, can access the functionality through their mobile app.
 
 The core feature of message-based communication initiation in messaging specification is the process of looking up the two main properties of each identity:
 
@@ -26,18 +26,18 @@ The [JWZ](/docs/wallet/wallet-sdk/polygonid-sdk/iden3comm/jwz.md) is generated w
 
 ## Agent Endpoint
 
-**Function**: endpoint to send a JWZ token from the user's mobile app.
+**Function**: Endpoint to send a JWZ token from the user's mobile app.
 
-**How it Works**: the user's app sends a JWZ token in the request body.
+**How it Works**: The user's app sends a JWZ token in the request body.
 
 The Issuer Node responds by sending a response message that contains details related to Verifiable Credential and Issuer. It also includes metadata such as:
 
 - `from`: from which user's DID the message is sent.
 - `to`: to which Issuer's DID the message is sent.
 - `id`: a random UUID generated for a transaction.
 - `threadID`: part of the JWZ token.
-- `typ`: the way of communication between protocol and mobile.
-- `type`: the way of communication between protocol and mobile.
+- `typ`: the way of communication between protocol and mobile. Also indicates how the message is formatted and should be processed
+- `type`: the way of communication between protocol and mobile. Specifies what kind of operation or response the message represents
 
 A typical response looks like this:
 

docs/issuer-node/issuer-node-api/claim/apis.md

@@ -29,15 +29,15 @@ A credential ID is assigned to a Verifiable Credential when it is created by an
 
 ## Create Credential
 
-**Function**: endpoint to create a Verifiable Credential for a user.
+**Function**: Endpoint to create a Verifiable Credential for a user.
 
-**How it Works**: the DID (identifier string retrieved from calling the `Create Identity` endpoint) is passed as a path variable in the request URL. This is your DID identifier that you use as an issuer of credentials.
+**How it Works**: The DID (identifier string retrieved from calling the `Create Identity` endpoint) is passed as a path variable in the request URL. This is your DID identifier that you use as an issuer of credentials.
 
 The following parameters are passed in the body of the request:
 
 - `credentialSchema`: it is a template for a Verifiable Credential that guarantees the structure of a credential. This way, an Issuer, a Holder, and a Verifier can reference the data in a known way. Further details on the `credentialSchema` can be found in the [Create Custom Schema](../../../issuer/schema.md) section.
 - `type`: the type of the credential schema sent.
-- `credentialSubject`: contains DID (Decentralized Identifier), i.e. `did`, of the user and the fields related to the data to be attested. You should have previously obtained this identifier from the user by performing a "basic auth" step, this can be done through the [Authentication/QRcode step](https://issuer-admin.polygonid.me/#get-/v1/authentication/qrcode).
+- `credentialSubject`: contains DID (Decentralized Identifier), i.e. `did`, of the user and the fields related to the data to be attested. You should have previously obtained this identifier from the user by performing a "basic auth" step, this can be done through the [Authentication / QRcode step](https://issuer-admin.polygonid.me/#get-/v1/authentication/qrcode).
 - `expiration`: Date of expiry of the Verifiable Credential.
 
 :::note
@@ -52,11 +52,11 @@ The Issuer Node responds by sending a response message that contains the string
 
 ## Get Credential
 
-**Function**: endpoint to retrieve a Verifiable Credential based on its Credential ID (CID). This way, you can retrieve a credential issued by an Issuer based on this credential's ID.
+**Function**: Endpoint to retrieve a Verifiable Credential based on its Credential ID (CID). This way, you can retrieve a credential issued by an Issuer based on this credential's ID.
 
-**How it Works**: the DID (the identifier string retrieved from calling the `Create Identity` endpoint) and the Claim ID, i.e.`id` (or CID) of the Verifiable Credential (retrieved from calling the `Create Claim` endpoint) are passed as path variables in the request URL.
+**How it Works**: The DID (the identifier string retrieved from calling the `Create Identity` endpoint) and the Claim ID, i.e.`id` (or CID) of the Verifiable Credential (retrieved from calling the `Create Claim` endpoint) are passed as path variables in the request URL.
 
-The endpoint requires to pass the issuer `did` and the Verifiable Credential `CID` as path variables in the request URL.
+The endpoint requires passing the issuer `did` and the Verifiable Credential `CID` as path variables in the request URL.
 
 The server responds by sending the following data about the Verifiable Credential:
 
@@ -93,9 +93,9 @@ The server responds by sending the following data about the Verifiable Credentia
 
 ## Get Credentials
 
-**Function**: endpoint to retrieve all the Verifiable Credentials issued by an Issuer.
+**Function**: Endpoint to retrieve all the Verifiable Credentials issued by an Issuer.
 
-**How it Works**: the DID (the identifier string retrieved from calling the `Create Identity` endpoint) is passed as path variables in the request URL.
+**How it Works**: The DID (the identifier string retrieved from calling the `Create Identity` endpoint) is passed as path variables in the request URL.
 
 You can retrieve a set of credentials based on different filters or criteria. These criteria can be added as the query-string parameters in the request URL. These filters (and their data types) are listed below:
 
@@ -122,9 +122,9 @@ In order to communicate with the Web Wallet or the Wallet App, the Issuer Node m
 
 :::
 
-**Function**: endpoint to generate a Universal Link. The user can then click this link and accept credentials to his/her wallet.
+**Function**: Endpoint to generate a Universal Link. The user can then click this link and accept credentials to their wallet.
 
-**How it Works**: the Issuer DID (identifier string retrieved from calling the `Create Identity` endpoint) and credential Identifier (or `cid` retrieved from the `Create Credential` endpoint) are passed as path variables in the request URL.
+**How it Works**: The Issuer DID (identifier string retrieved from calling the `Create Identity` endpoint) and credential Identifier (or `cid` retrieved from the `Create Credential` endpoint) are passed as path variables in the request URL.
 
 The Issuer Node responds by sending a response message that contains a JSON which carries the following fields:
 
@@ -137,19 +137,19 @@ The Issuer Node responds by sending a response message that contains a JSON whic
 
 ## Revoke Credential
 
-**Function**: endpoint to revoke a Verifiable Credential
+**Function**: Endpoint to revoke a Verifiable Credential
 
-**How it Works**: the Issuer DID (The identifier string retrieved from calling the `Create Identity` endpoint) and `nonce` of the VC to be revoked (Revocation Nonce) are passed as a path variable in the request URL.
+**How it Works**: The Issuer DID (The identifier string retrieved from calling the `Create Identity` endpoint) and `nonce` of the VC to be revoked (Revocation Nonce) are passed as a path variable in the request URL.
 
 The server responds by showing the Revocation Status of the credential.
 
 <a href="https://issuer-node-core-api-testing.privado.id/#post-/v2/identities/-identifier-/credentials/revoke/-nonce-" target="_blank">API Reference</a>
 
 ## Get Revocation Status
 
-**Function**: endpoint to retrieve the Revocation Status of the Verifiable Credential.
+**Function**: Endpoint to retrieve the Revocation Status of the Verifiable Credential.
 
-**How it Works**: the DID (The identifier string retrieved from calling the `Create Identity` endpoint) and `nonce` (Revocation Nonce) are passed as a path variable in the request URL. For the credential to be marked "revoked", we need to publish the state first on-chain, and then wait for 5 confirmation blocks.
+**How it Works**: The DID (The identifier string retrieved from calling the `Create Identity` endpoint) and `nonce` (Revocation Nonce) are passed as a path variable in the request URL. For the credential to be marked "revoked", we need to publish the state first on-chain, and then wait for 5 confirmation blocks.
 
 The server responds by sending the following details:
 

docs/issuer-node/issuer-node-api/identity/apis.md

@@ -14,7 +14,7 @@ keywords:
   - Identity
 ---
 
-The identity endpoint is used to create and retrieve identities for a user/issuer. Privado ID supports the creation of identities in the form of DIDs (Decentralized Identifiers). A user can have multiple DIDs.
+The identity endpoint is used to create and retrieve identities for a user and issuer. Privado ID supports the creation of identities in the form of DIDs (Decentralized Identifiers). A user can have multiple DIDs.
 
 :::note
 
@@ -28,7 +28,7 @@ A DID can be represented as:
 did: did method: did method-specific identifier.
 ```
 
-This is a standard form of expressing a Decentralised Identifier as defined by the <a href="https://www.w3.org/TR/did-core" target="_blank">W3C DID Core 1.0 Specifications</a>.
+This is a standard form of expressing a Decentralized Identifier as defined by the <a href="https://www.w3.org/TR/did-core" target="_blank">W3C DID Core 1.0 Specifications</a>.
 
 ## Create Identity
 
@@ -40,13 +40,13 @@ An example of a `didMetaData` passed in the request body of the `Create Identity
 
 ```
 {
-    "didMetadata":{
-        "method": "polygonid",
-        "blockchain":"polygon",
-        "network": "amoy",
-        "type": "BJJ"
-    },
-    "credentialStatusType": "Iden3commRevocationStatusv1.0",
+  "didMetadata": {
+    "method": "iden3",
+    "blockchain": "privado",
+    "network": "main",
+    "type": "BJJ"
+  },
+  "credentialStatusType": "Iden3ReverseSparseMerkleTreeProof"
 }
 ```
 
@@ -59,7 +59,10 @@ A few variations of the metadata can be:
 
 - blockchain:
 
+  - "privado"
+  - "billions"
   - "polygon"
+  - "linea"
   - "eth"
 
 - network:
@@ -74,16 +77,17 @@ A few variations of the metadata can be:
 
 :::info Identity Types
 
-As you can see above, there are two options for Identity types: Baby Jubjub and Ethereum DID.
-Baby Jubjub keys are used to create regular identities, but that method can't create an identity out of an Ethereum address. Instead, users can choose the "ETH" type to use Ethereum accounts to authenticate, prove statements and control identity. It is important to note that the Ethereum address must have funds to publish its state onchain.
+As you can see above, there are two options for Identity types: Baby JubJub and Ethereum DID.
+Baby JubJub keys are used to create regular identities, but that method can't create an identity out of an Ethereum address. Instead, users can choose the "ETH" type to use Ethereum accounts to authenticate, prove statements and control identity. It is important to note that the Ethereum address must have funds to publish its state onchain.
 
 Read more about Identity types on <ins>[Iden3 Docs](https://docs.iden3.io/getting-started/identity/identity-types/)</ins>.
 
 :::
 
 The Issuer Node responds by sending a response message that contains:
 
-- `identifier`: Identifier of the Issuer in the standard DID format. For example: `did:polygonid:polygon:amoy:2qNBWSAsyvaGBpqQVHk3E4cgChaN6ogaZnYCQUyoRQ`
+- `identifier`: Identifier of the Issuer in the standard DID format. For example: 
+`did:iden3:privado:main:2qNBWSAsyvaGBpqQVHk3E4cgChaN6ogaZnYCQUyoRQ`
 
 - `identity state`: It is the state of the identity and contains fields that include `claimsTreeRoot` (Verifiable Credentials are added to the Claims Tree and its root is calculated), `state` (state of identity), and `status` (whether the status of the identity state is confirmed or pending). `identity state` also contains the timestamp when the identity was created (`createdAt`) or updated(`modifiedAt`).
 
@@ -101,7 +105,7 @@ The Issuer Node responds by sending a response message that contains:
 
 - `identifier`: Identifier of the Issuer in the standard DID format. For example:
 
-`did:polygonid:polygon:amoy:2qNBWSAsyvaGBpqQVHk3E4cgChaN6ogaZnYCQUyoRQ`
+`did:iden3:privado:main:2qNBWSAsyvaGBpqQVHk3E4cgChaN6ogaZnYCQUyoRQ`
 
 <a href="https://issuer-node-core-api-testing.privado.id/#get-/v2/identities" target="_blank">API Reference</a>