docs(common): fix update addresses (#291)

PacificYield · web-flow · commit f64b19b4ec33 · 2025-06-16T15:16:42.000+02:00
* docs(common): fix update addresses

* docs(common): user decrypt

* fix(common): fix

* docs(common): updates
diff --git a/docs/introductions/SUMMARY.md b/docs/introductions/SUMMARY.md
@@ -9,7 +9,7 @@
 - [Overview](architecture_overview.md)
 - [FHE on blockchain](fhe-on-blockchain.md)
 - [FHEVM components](fhevm-components.md)
-- [Encryption, decryption, re-encryption, and computation](d_re_ecrypt_compute.md)
+- [Encryption, decryption, and computation](d_re_ecrypt_compute.md)
 
 ## References
 
diff --git a/docs/introductions/architecture_overview.md b/docs/introductions/architecture_overview.md
@@ -4,7 +4,7 @@ The FHEVM architecture provides the foundation for confidential smart contracts
 core is FHE, a cryptographic technique enabling computations directly on encrypted data, ensuring privacy at every
 stage.&#x20;
 
-This system relies on three key types:&#x20;
+This system relies on three key types:
 
 - The **public key:** used by users to encrypt their inputs locally.
 - The **private key:** required for decryption, securely distributed and managed through a threshold MPC-based Key
diff --git a/docs/introductions/d_re_ecrypt_compute.md b/docs/introductions/d_re_ecrypt_compute.md
@@ -37,7 +37,7 @@ transmitted or processed.
   - **Source**: Frontend.
   - **Destination**: Coprocessor (for processing).
 
-<figure><img src="../.gitbook/assets/encrypt.png" alt="re-encryption" width="600"><figcaption></figcaption></figure>
+<figure><img src="../.gitbook/assets/encrypt.png" alt="decryption" width="600"><figcaption></figcaption></figure>
 
 You can read about the implementation details in [our encryption guide](solidity-guides/inputs.md).
 
@@ -74,13 +74,13 @@ There are two kinds of decryption supported in the FHEVM system:
 
 <figure><img src="../.gitbook/assets/decryption.png" alt="decryption"><figcaption></figcaption></figure>
 
-<figure><img src="../.gitbook/assets/asyncDecrypt.png" alt="re-encryption"><figcaption><p>re-encryption</p></figcaption></figure>
+<figure><img src="../.gitbook/assets/asyncDecrypt.png" alt="decryption"><figcaption><p>decryption</p></figcaption></figure>
 You can read about the implementation details in [our decryption guide](solidity-guides/decryption/decrypt.md).
 
 #### What is “User Decryption”?
 
 User Decryption is the mechanism that allows users or applications to request private access to decrypted data — without
-exposing the plaintext on-chain. Instead of simply decrypting, the KMS securely decrypts and re-encrypts the result with
+exposing the plaintext on-chain. Instead of simply decrypting, the KMS securely decrypts the result with
 the user’s public key, allowing the user to decrypt it client-side only.
 
 This guarantees:
@@ -89,7 +89,7 @@ This guarantees:
 - The KMS never reveals the decrypted value
 - The decrypted result is not written to the blockchain
 
-<figure><img src="../.gitbook/assets/reencryption.png" alt="re-encryption"><figcaption><p>re-encryption process</p></figcaption></figure>
+<figure><img src="../.gitbook/assets/reencryption.png" alt="decryption"><figcaption><p>decryption process</p></figcaption></figure>
 
 #### Client-side implementation
 
@@ -98,7 +98,7 @@ User decryption is initiated on the client side using the
 
 1. **Retrieve the ciphertext**:
    - The dApp calls a view function (e.g., `balanceOf`) on the smart contract to get the handle of the ciphertext to be
-     re-encrypted.
+     decrypted.
 2. **Generate and sign a keypair**:
    - The dApp generates a keypair for the user.
    - The user signs the public key to ensure authenticity.
@@ -115,7 +115,7 @@ User decryption is initiated on the client side using the
    - The dApp receives the encrypted ciphertext under the user's public key from the Gateway/Relayer.
    - The dApp decrypts the ciphertext locally using the user's private key.
 
-You can read [our re-encryption guide explaining how to use it](solidity-guides/decryption/reencryption.md).
+You can read [our user decryption guide explaining how to use it](solidity-guides/decryption/user-decryption.md).
 
 ## **Tying It All Together**
 
diff --git a/docs/introductions/fhevm-components.md b/docs/introductions/fhevm-components.md
@@ -87,6 +87,6 @@ The KMS is a decentralized threshold-MPC-based service that manages the FHE key
 
 The KMS ensures robust cryptographic security, preventing single points of failure and maintaining public verifiability.
 
-In the next section, we will dive deeper into encryption, re-encryption, and decryption processes, including how they
-interact with the KMS and Gateway services. For more details, see
+In the next section, we will dive deeper into encryption and decryption processes, including how they
+interact with the KMS and relayer services. For more details, see
 [Encryption, decryption, and computation](./d_re_ecrypt_compute.md).
diff --git a/docs/introductions/table_of_addresses.md b/docs/introductions/table_of_addresses.md
@@ -12,5 +12,4 @@ These are Sepolia addresses.
 | KMS_VERIFIER_CONTRACT      | 0x1364cBBf2cDF5032C47d8226a6f6FBD2AFCDacAC     |
 | INPUT_VERIFIER_CONTRACT    | 0xbc91f3daD1A5F19F8390c400196e58073B6a0BC4     |
 | DECRYPTION_ORACLE_CONTRACT | 0xa02Cda4Ca3a71D7C46997716F4283aa851C28812     |
-| PUBLIC_KEY_ID              | 0301c5dd3e2702992b7c12930b7d4defeaaa52cf       |
 | RELAYER_URL                | `https://relayer.testnet.zama.cloud/v1/keyurl` |
diff --git a/docs/solidity-guides/SUMMARY.md b/docs/solidity-guides/SUMMARY.md
@@ -1,6 +1,7 @@
 ## Get Started
 
-- [Overview](overview.md)
+- [Overview](solidity-overview.md)
+- [Quick Start guide](overview.md)
 - [Quick Start - Hardhat](hardhat/README.md)
   - [Prerequisites](hardhat/prerequisites.md)
   - [1. Setting up Hardhat](hardhat/1.-setting-up-hardhat.md)
@@ -18,11 +19,11 @@
 - [Access Control List](acl/README.md)
   - [ACL examples](acl/acl_examples.md)
 
-## Decryption & Re-encryption
+## Public Decryption & User Decryption
 
-- [Decryption](decryption/decrypt.md)
+- [User Decryption](decryption/user-decryption.md)
+- [Public Decryption](decryption/public-decryption.md)
 - [Decryption in depth](decryption/decrypt_details.md)
-- [Re-encryption](decryption/reencryption.md)
 
 ## Control Flow & Logic
 
diff --git a/docs/solidity-guides/configure.md b/docs/solidity-guides/configure.md
@@ -9,7 +9,7 @@ To utilize encrypted computations in Solidity contracts, you must configure the
 ## Key components configured automatically
 
 1. **FHE library**: Sets up encryption parameters and cryptographic keys.
-2. **Relayer**: Manages secure cryptographic operations, including reencryption and decryption.
+2. **Relayer**: Manages secure cryptographic operations, including user decryption and public decryption.
 3. **Network-specific settings**: Adapts to local testing, testnets (Sepolia for example), or mainnet deployment.
 
 By inheriting these configuration contracts, you ensure seamless initialization and functionality across environments.
@@ -45,9 +45,9 @@ contract MyERC20 is SepoliaZamaFHEVMConfig {
 }
 ```
 
-## ZamaRela.sol
+## ZamaConfig.sol
 
-To perform decryption or reencryption, your contract must interact with the **Relayer**, which acts as a secure bridge between the blockchain, coprocessor, and Key Management System (KMS).
+To perform public decryption or user decryption, your contract must interact with the **Relayer**, which acts as a secure bridge between the blockchain, coprocessor, and Key Management System (KMS).
 
 **Import based on your environment**
 
@@ -59,7 +59,7 @@ import { SepoliaConfig } from "@fhevm/solidity/config/ZamaConfig.sol";
 **Purpose**
 
 - Configures the relayer for secure cryptographic operations.
-- Facilitates reencryption and decryption requests.
+- Facilitates public and user decryption requests.
 
 **Example: Configuring the relayer with Sepolia settings**
 
diff --git a/docs/solidity-guides/decryption/decrypt_details.md b/docs/solidity-guides/decryption/decrypt_details.md
@@ -62,4 +62,4 @@ You can call the function `FHE.checkSignatures` as such:
 The first argument, `requestID`, is the value that was returned in the `requestDecryption`function.
 The second argument, `signatures`, is an array of signatures from the KMS signers.
 
-This function reverts if the signatures are invalid.
+This function reverts if the signatures are invalid.
diff --git a/docs/solidity-guides/decryption/public-decryption.md b/docs/solidity-guides/decryption/public-decryption.md
@@ -1,17 +1,17 @@
-# Decryption
+# Public decryption
 
 This section explains how to handle decryption in fhevm. Decryption allows plaintext data to be accessed when required for contract logic or user presentation, ensuring confidentiality is maintained throughout the process.
 
 {% hint style="info" %}
-Understanding how encryption, decryption and reencryption works is a prerequisite before implementation, see [Encryption, Decryption, Re-encryption, and Computation](../../introductions/d_re_ecrypt_compute.md).
+Understanding how encryption, user decryption, and public decryption works is a prerequisite before implementation, see [Encryption, User Decryption, Public Decryption, and Computation](../../introductions/d_re_ecrypt_compute.md).
 {% endhint %}
 
 Decryption is essential in two primary cases:
 
 1. **Smart contract logic**: A contract requires plaintext values for computations or decision-making.
 2. **User interaction**: Plaintext data needs to be revealed to all users, such as revealing the decision of the vote.
 
-To learn how decryption works see [Encryption, Decryption, Re-encryption, and Computation](../../introductions/d_re_ecrypt_compute.md).
+To learn how decryption works see [Encryption, User decryption, Public decryption, and Computation](../../introductions/d_re_ecrypt_compute.md).
 
 ## Overview
 
@@ -60,7 +60,7 @@ contract TestAsyncDecrypt is SepoliaConfig {
 
 ### Next steps
 
-Explore advanced decryption techniques and learn more about re-encryption:
+Explore advanced decryption techniques and learn more about user decryption:
 
 - [Decryption in depth](decrypt_details.md)
-- [Re-encryption](reencryption.md)
+- [User decryption](user-decryption.md)
diff --git a/docs/solidity-guides/decryption/user-decryption.md b/docs/solidity-guides/decryption/user-decryption.md
@@ -2,10 +2,10 @@
 
 This document explains how to perform user decryption. User decryption required when you want a user to access their private data without it being exposed to the blockchain.
 
-Re-encryption in FHEVM enables the secure sharing or reuse of encrypted data under a new public key without exposing the plaintext. This feature is essential for scenarios where encrypted data must be transferred between contracts, dApps, or users while maintaining its confidentiality.
+User decryption in FHEVM enables the secure sharing or reuse of encrypted data under a new public key without exposing the plaintext. This feature is essential for scenarios where encrypted data must be transferred between contracts, dApps, or users while maintaining its confidentiality.
 
 {% hint style="info" %}
-Before implementing re-encryption, ensure you are familiar with the foundational concepts of encryption, re-encryption and computation. Refer to [Encryption, Decryption, Re-encryption, and Computation](../introductions/d_re_ecrypt_compute.md).
+Before implementing user decryption ensure you are familiar with the foundational concepts of encryption, decryption, and computation. Refer to [Encryption, Decryption, and Computation](../introductions/d_re_ecrypt_compute.md).
 {% endhint %}
 
 ## When to use user decryption
@@ -14,11 +14,11 @@ User decryption is particularly useful for **allowing individual users to secure
 
 ## Overview
 
-The re-encryption process involves retrieving ciphertext from the blockchain and performing re-encryption on the client-side. In other words we take the data that has been encrypted by the KMS, decrypt it and encrypt it with the users private key, so only he can access the information.
+The user decryption process involves retrieving ciphertext from the blockchain and performing user-decryption on the client-side. In other words we take the data that has been encrypted by the KMS, decrypt it and encrypt it with the users private key, so only he can access the information.
 
 This ensures that the data remains encrypted under the blockchain’s FHE key but can be securely shared with a user by re-encrypting it under the user’s NaCl public key.
 
-Re-encryption is facilitated by the **Relayer** and the **Key Management System (KMS)**. The workflow consists of the following:
+User decryption is facilitated by the **Relayer** and the **Key Management System (KMS)**. The workflow consists of the following:
 
 1. Retrieving the ciphertext from the blockchain using a contract’s view function.
 2. Re-encrypting the ciphertext client-side with the user’s public key, ensuring only the user can decrypt it.
@@ -41,10 +41,10 @@ contract ConfidentialERC20 {
 
 Here, `balanceOf` allows retrieval of the user’s encrypted balance stored on the blockchain.
 
-## Step 2: re-encrypt the ciphertext
+## Step 2: decrypt the ciphertext
 
-Re-encryption is performed client-side using the `@fhevm/sdk` library. [Refer to the guide](../../frontend/webapp.md) to learn how to include `@fhevm/sdk` in your project.
-Below is an example of how to implement reencryption in a dApp:
+User decryption is performed client-side using the `@fhevm/sdk` library. [Refer to the guide](../../frontend/webapp.md) to learn how to include `@fhevm/sdk` in your project.
+Below is an example of how to implement user decryption in a dApp:
 
 ```ts
 import { createInstances } from "../instance";
@@ -63,7 +63,7 @@ await initSigners(); // Initialize signers
 const signers = await getSigners();
 
 const instance = await createInstances(this.signers);
-// Generate the private and public key, used for the reencryption
+// Generate the private and public key, used for the user decryption
 const { publicKey, privateKey } = instance.generateKeypair();
 
 // Create an EIP712 object for the user to sign.
@@ -96,4 +96,4 @@ This code retrieves the user’s encrypted balance, re-encrypts it with their pu
 
 - **`instance.generateKeypair()`**: Generates a public-private keypair for the user.
 - **`instance.createEIP712(publicKey, CONTRACT_ADDRESS)`**: Creates an EIP712 object for signing the user’s public key.
-- **`instance.reencrypt()`**: Facilitates the re-encryption process by contacting the relayer and decrypting the data locally with the private key.
+- **`instance.reencrypt()`**: Facilitates the user decryption process by contacting the relayer and decrypting the data locally with the private key.
diff --git a/docs/solidity-guides/functions.md b/docs/solidity-guides/functions.md
@@ -311,7 +311,7 @@ function allowTransient(T value, address account) internal
 
 #### Access control list (ACL) overview
 
-The `allow` and `allowTransient` functions enable fine-grained control over who can access, decrypt, and reencrypt encrypted values. Temporary permissions (`allowTransient`) are ideal for minimizing gas usage in scenarios where access is needed only within a single transaction.
+The `allow` and `allowTransient` functions enable fine-grained control over who can access and decrypt encrypted values. Temporary permissions (`allowTransient`) are ideal for minimizing gas usage in scenarios where access is needed only within a single transaction.
 
 **Example: granting access**
 
diff --git a/docs/solidity-guides/inputs.md b/docs/solidity-guides/inputs.md
@@ -3,7 +3,7 @@
 This document introduces the concept of encrypted inputs in the fhevm, explaining their role, structure, validation process, and how developers can integrate them into smart contracts and applications.
 
 {% hint style="info" %}
-Understanding how encryption, decryption and reencryption works is a prerequisite before implementation, see [Encryption, Decryption, Re-encryption, and Computation](../introductions/d_re_ecrypt_compute.md)
+Understanding how encryption, public, and user decryption works is a prerequisite before implementation, see [Encryption, Decryption, and Computation](../introductions/d_re_ecrypt_compute.md)
 {% endhint %}
 
 Encrypted inputs are a core feature of fhevm, enabling users to push encrypted data onto the blockchain while ensuring data confidentiality and integrity.
