zama-ai · tudorpintea999 · Jan 15, 2025 · Jan 15, 2025 · Jan 15, 2025 · Jan 16, 2025
diff --git a/README.md b/README.md
@@ -133,7 +133,7 @@ _More examples are available [here](https://docs.zama.ai/fhevm/tutorials/see-all
 
 > [!Note] > **Zama 5-Question Developer Survey**
 >
-> We want to hear from you! Take 1 minute to share your thoughts and helping us enhance our documentation and libraries. 👉 **[Click here](https://www.zama.ai/developer-survey)** to participate.
+> We want to hear from you! Take 1 minute to share your thoughts and help us enhance our documentation and libraries. 👉 **[Click here](https://www.zama.ai/developer-survey)** to participate.
 
 ## Resources
 

diff --git a/docs/README.md b/docs/README.md
@@ -63,5 +63,5 @@ Collaborate with us to advance the FHE spaces and drive innovation together.
 {% hint style="success" %}
 **Zama 5-Question Developer Survey**
 
-We want to hear from you! Take 1 minute to share your thoughts and helping us enhance our documentation and libraries. **👉** [**Click here**](https://www.zama.ai/developer-survey) to participate.
+We want to hear from you! Take 1 minute to share your thoughts and help us enhance our documentation and libraries. **👉** [**Click here**](https://www.zama.ai/developer-survey) to participate.
 {% endhint %}
diff --git a/docs/developer/roadmap.md b/docs/developer/roadmap.md
@@ -1,6 +1,6 @@
 # Development roadmap
 
-This document gives an preview of the upcoming features of fhEVM. In addition to what's listed here, you can [submit your feature request](https://github.com/zama-ai/fhevm/issues/new?template=feature-request.md) on GitHub.
+This document gives a preview of the upcoming features of fhEVM. In addition to what's listed here, you can [submit your feature request](https://github.com/zama-ai/fhevm/issues/new?template=feature-request.md) on GitHub.
 
 ## Features
 

diff --git a/docs/fundamentals/architecture_overview/fhevm-components.md b/docs/fundamentals/architecture_overview/fhevm-components.md
@@ -1,6 +1,6 @@
 # fhEVM components
 
-This document gives an detail explanantion of each components of fhEVM and illustrate how they work together to perform compuations.&#x20;
+This document gives a detailed explanantion of each component of fhEVM and illustrate how they work together to perform computations.&#x20;
 
 ## O**verview**
 

diff --git a/docs/fundamentals/d_re_ecrypt_compute.md b/docs/fundamentals/d_re_ecrypt_compute.md
@@ -52,7 +52,7 @@ Encrypted computations are performed using the **evaluation key** on the coproce
 
 ### **Decryption**
 
-Decryption is used when plaintext results are required for contract logic or for presentation to a user. After the decryption in preformed on the blockchain, the decrypted result is exposed to everyone who has access to the blockchain.
+Decryption is used when plaintext results are required for contract logic or for presentation to a user. After the decryption is performed on the blockchain, the decrypted result is exposed to everyone who has access to the blockchain.
 
 <figure><img src="../.gitbook/assets/decryption.png" alt="decryption"><figcaption></figcaption></figure>
 
@@ -69,7 +69,7 @@ Decryption is used when plaintext results are required for contract logic or for
 
 <figure><img src="../.gitbook/assets/asyncDecrypt.png" alt="re-encryption"><figcaption><p>re-encryption</p></figcaption></figure>
 
-You can read about the implemention details in [our decryption guide](decryption/decrypt.md).
+You can read about the implementation details in [our decryption guide](decryption/decrypt.md).
 
 ---
 

diff --git a/docs/fundamentals/decryption/decrypt.md b/docs/fundamentals/decryption/decrypt.md
@@ -3,7 +3,7 @@
 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 prerequisit before implementation, see [Encryption, Decryption, Re-encryption, and Computation](../d_re_ecrypt_compute.md).
+Understanding how encryption, decryption and reencryption works is a prerequisite before implementation, see [Encryption, Decryption, Re-encryption, and Computation](../d_re_ecrypt_compute.md).
 {% endhint %}
 
 Decryption is essential in two primary cases:
@@ -80,7 +80,7 @@ import { SepoliaZamaGatewayConfig } from "fhevm/config/ZamaGatewayConfig.sol";
 import "fhevm/gateway/GatewayCaller.sol";
 
 /// @title EncryptedCounter3
-/// @notice A contract that maintains an encrypted counter and is meant for demonstrating how decryption works
+/// @notice A contract that maintains an encrypted counter and is meant to demonstrate how decryption works
 /// @dev Uses TFHE library for fully homomorphic encryption operations and Gateway for decryption
 /// @custom:experimental This contract is experimental and uses FHE technology with decryption capabilities
 contract EncryptedCounter3 is SepoliaZamaFHEVMConfig, SepoliaZamaGatewayConfig, GatewayCaller {

diff --git a/docs/fundamentals/decryption/decrypt_details.md b/docs/fundamentals/decryption/decrypt_details.md
@@ -56,9 +56,9 @@ Notice that `XXX` should be the decrypted type, which is a native Solidity type
 
 Here `callbackName` is a custom name given by the developer to the callback function, `requestID` will be the request id of the decryption (could be commented if not needed in the logic, but must be present) and `x_0`, `x_1`, ... `x_N-1` are the results of the decryption of the `ct` array values, i.e their number should be the size of the `ct` array.
 
-`msgValue` is the value in native tokens to be sent to the calling contract during fulfilment, i.e when the callback will be called with the results of decryption.
+`msgValue` is the value in native tokens to be sent to the calling contract during fulfillment, i.e when the callback will be called with the results of decryption.
 
-`maxTimestamp` is the maximum timestamp after which the callback will not be able to receive the results of decryption, i.e the fulfilment transaction will fail in this case. This can be used for time-sensitive applications, where we prefer to reject decryption results on too old, out-of-date, values.
+`maxTimestamp` is the maximum timestamp after which the callback will not be able to receive the results of decryption, i.e the fulfillment transaction will fail in this case. This can be used for time-sensitive applications, where we prefer to reject decryption results on too old, out-of-date, values.
 
 `passSignaturesToCaller` determines whether the callback needs to transmit signatures from the KMS or not. This is useful if the dApp developer wants to remove trust from the Gateway service and prefers to check the KMS signatures directly from within his dApp smart contract. A concrete example of how to verify the KMS signatures inside a dApp is available [here](https://github.com/zama-ai/fhevm/blob/2ff952e8e038e56246c840af31ca3fadd7fccedd/examples/TestAsyncDecrypt.sol#L82-L94) in the `requestBoolTrustless` function.
 
@@ -151,9 +151,9 @@ When the decryption request is fufilled by the relayer, the `GatewayContract` co
 event ResultCallback(uint256 indexed requestID, bool success, bytes result);
 ```
 
-The first argument is the `requestID` of the corresponding decryption request, `success` is a boolean assessing if the call to the callback succeeded, and `result` is the bytes array corresponding the to return data from the callback.
+The first argument is the `requestID` of the corresponding decryption request, `success` is a boolean assessing if the call to the callback succeeded, and `result` is the bytes array corresponding to the return data from the callback.
 
-In your hardhat tests, if you sent some transactions which are requesting one or several decryptions and you wish to await the fulfilment of those decryptions, you should import the two helper methods `initGateway` and `awaitAllDecryptionResults` from the `asyncDecrypt.ts` utility file. This would work both when testing on an fhEVM node or in mocked mode. Here is a simple hardhat test for the previous `TestAsyncDecrypt` contract (more examples can be seen [here](https://github.com/zama-ai/fhevm/blob/main/test/gatewayDecrypt/testAsyncDecrypt.ts)):
+In your hardhat tests, if you sent some transactions which are requesting one or several decryptions and you wish to await the fulfillment of those decryptions, you should import the two helper methods `initGateway` and `awaitAllDecryptionResults` from the `asyncDecrypt.ts` utility file. This would work both when testing on a fhEVM node or in mocked mode. Here is a simple hardhat test for the previous `TestAsyncDecrypt` contract (more examples can be seen [here](https://github.com/zama-ai/fhevm/blob/main/test/gatewayDecrypt/testAsyncDecrypt.ts)):
 
 ```js
 import { initGateway, awaitAllDecryptionResults } from "../asyncDecrypt";
@@ -183,4 +183,4 @@ describe("TestAsyncDecrypt", function () {
 });
 ```
 
-You should initialize the gateway by calling `initGateway` at the top of the `before` block - more specifically, before doing any transaction which could involve a decryption request. Notice that when testing on the fhEVM, a decryption is fulfilled usually 2 blocks after the request, while in mocked mode the fulfilment will always happen as soon as you call the `awaitAllDecryptionResults` helper function. A good way to standardize hardhat tests is hence to always call the `awaitAllDecryptionResults` function which will ensure that all pending decryptions are fulfilled in both modes.
+You should initialize the gateway by calling `initGateway` at the top of the `before` block - more specifically, before doing any transaction which could involve a decryption request. Notice that when testing on the fhEVM, a decryption is fulfilled usually 2 blocks after the request, while in mocked mode the fulfillment will always happen as soon as you call the `awaitAllDecryptionResults` helper function. A good way to standardize hardhat tests is hence to always call the `awaitAllDecryptionResults` function which will ensure that all pending decryptions are fulfilled in both modes.
diff --git a/docs/fundamentals/decryption/reencryption.md b/docs/fundamentals/decryption/reencryption.md
@@ -112,7 +112,7 @@ import "fhevm/lib/TFHE.sol";
 import { SepoliaZamaFHEVMConfig } from "fhevm/config/ZamaFHEVMConfig.sol";
 
 /// @title EncryptedCounter4
-/// @notice A contract that maintains encrypted counters for each user and is meant for demonstrating how re-encryption works
+/// @notice A contract that maintains encrypted counters for each user and is meant to demonstrate how re-encryption works
 /// @dev Uses TFHE library for fully homomorphic encryption operations
 /// @custom:security Each user can only access and modify their own counter
 /// @custom:experimental This contract is experimental and uses FHE technology

diff --git a/docs/fundamentals/inputs.md b/docs/fundamentals/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 prerequisit before implementation, see [Encryption, Decryption, Re-encryption, and Computation](d_re_ecrypt_compute.md)
+Understanding how encryption, decryption and reencryption works is a prerequisite before implementation, see [Encryption, Decryption, Re-encryption, and Computation](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.

diff --git a/docs/fundamentals/operations.md b/docs/fundamentals/operations.md
@@ -130,7 +130,7 @@ Despite both leading to the same encrypted result!
 
 TFHE arithmetic operators can overflow. Do not forget to take into account such a possibility when implementing fhEVM smart contracts.
 
-❌ For example, if you wanted to create a mint function for an encrypted ERC20 tokens with an encrypted `totalSupply` state variable, this code is vulnerable to overflows:
+❌ For example, if you wanted to create a mint function for an encrypted ERC20 token with an encrypted `totalSupply` state variable, this code is vulnerable to overflows:
 
 ```solidity
 function mint(einput encryptedAmount, bytes calldata inputProof) public {

diff --git a/docs/getting_started/write_contract/hardhat.md b/docs/getting_started/write_contract/hardhat.md
@@ -97,7 +97,7 @@ For Solidity syntax highlighting, use the [Hardhat Solidity](https://marketplace
 
 ### Important note
 
-Due to limitations in the `solidity-coverage` package, coverage computation in fhEVM does not support tests involving the `evm_snapshot` Hardhat testing method. However, this method is still supported when running tests in mocked mode. If you are using Hardhat snapshots, we recommend to end your your test description with the `[skip-on-coverage]` tag to to avoid coverage issues. Here is an example:
+Due to limitations in the `solidity-coverage` package, coverage computation in fhEVM does not support tests involving the `evm_snapshot` Hardhat testing method. However, this method is still supported when running tests in mocked mode. If you are using Hardhat snapshots, we recommend to end your test description with the `[skip-on-coverage]` tag to avoid coverage issues. Here is an example:
 
 ```js
 import { expect } from 'chai';

diff --git a/docs/guides/error_handling.md b/docs/guides/error_handling.md
@@ -113,7 +113,7 @@ function getLastError(address user) public view returns (euint8 error, uint time
    - Provides actionable error messages without compromising the confidentiality of encrypted computations.
 2. **Scalable error tracking**:
    - Logs errors per user, making it easy to identify and debug specific issues.
-3. **Event-driven botifications**:
+3. **Event-driven notifications**:
    - Enables frontends to react to errors in real time via the `ErrorChanged` event.
 
 By implementing error handlers as demonstrated, developers can ensure a seamless user experience while maintaining the privacy and integrity of encrypted data operations.
diff --git a/docs/guides/frontend/webpack.md b/docs/guides/frontend/webpack.md
@@ -8,7 +8,7 @@ This document provides solutions for common Webpack errors encountered during th
 
 **Cause:** In the codebase, there is a `new URL('tfhe_bg.wasm')` which triggers a resolve by Webpack.
 
-**Possible sultions:** You can add a fallback for this file by adding a resolve configuration in your `webpack.config.js`:
+**Possible solutions:** You can add a fallback for this file by adding a resolve configuration in your `webpack.config.js`:
 
 ```javascript
 resolve: {
@@ -24,7 +24,7 @@ resolve: {
 
 **Cause:** This error occurs when the Node.js `Buffer` object is used in a browser environment where it is not natively available.
 
-**Possible sultions:** To resolve this issue, you need to provide browser-compatible fallbacks for Node.js core modules. Install the necessary browserified npm packages and configure Webpack to use these fallbacks.
+**Possible solutions:** To resolve this issue, you need to provide browser-compatible fallbacks for Node.js core modules. Install the necessary browserified npm packages and configure Webpack to use these fallbacks.
 
 ```javascript
 resolve: {

diff --git a/docs/guides/gas.md b/docs/guides/gas.md
@@ -68,7 +68,7 @@ console.log("Native Gas Consumed:", transaction.gasUsed);
 
 The current devnet has a FHEGas limit of **10,000,000** per block. Here's what you need to know:
 
-- If you send a transaction that exceeds this limit or if the FHEGas block limit is exceeded, depending on other previous transaction in same block:
+- If you send a transaction that exceeds this limit or if the FHEGas block limit is exceeded, depending on other previous transaction in the same block:
   - The transaction will revert
   - Any native gas fees (but not FHEGas) will still be charged
   - You should do one of the following:

diff --git a/docs/guides/loop.md b/docs/guides/loop.md
@@ -1,4 +1,4 @@
-# If sentances
+# If sentences
 
 This document explains how to handle loops when working with Fully Homomorphic Encryption (FHE), specifically when a loop break is based on an encrypted condition.
 
@@ -33,7 +33,7 @@ for (uint32 i = 0; i < 10; i++) {
 
 In this snippet, we perform 10 iterations, adding 4 to `x` in each iteration as long as the iteration count is less than `maxValue`. If the iteration count exceeds `maxValue`, we add 0 instead for the remaining iterations because we can't break the loop.
 
-## Best practises
+## Best practices
 
 ### Obfuscate branching
 
@@ -43,7 +43,7 @@ However, this is sometimes not enough. Enhancing the privacy of smart contracts
 
 For example, if implementing a simple AMM for two encrypted ERC20 tokens based on a linear constant function, it is recommended to not only hide the amounts being swapped, but also the token which is swapped in a pair.
 
-✅ Here is a very simplified example implementations, we suppose here that the rate between tokenA and tokenB is constant and equals to 1:
+✅ Here is a very simplified example implementation, we suppose here that the rate between tokenA and tokenB is constant and equals to 1:
 
 ```solidity
 // typically either encryptedAmountAIn or encryptedAmountBIn is an encrypted null value

diff --git a/docs/guides/random.md b/docs/guides/random.md
@@ -56,7 +56,7 @@ function randomBoundedNumber(uint16 upperBound) public returns (euint16) {
 
 ## **Random encrypted bytes**
 
-For generating larger random values, you can use encrypted bytes. These are ideal for scenarios requiring high-precision or high-entropy data.
+To generate larger random values, you can use encrypted bytes. These are ideal for scenarios requiring high-precision or high-entropy data.
 
 ```solidity
 // Generate random encrypted bytes

diff --git a/docs/tutorials/see-all-tutorials.md b/docs/tutorials/see-all-tutorials.md
@@ -1,6 +1,6 @@
 # See all tutorials
 
-## Solidity smart contracts teamplates - `fhevm-contracts`
+## Solidity smart contracts templates - `fhevm-contracts`
 
 The [fhevm-contracts repository](https://github.com/zama-ai/fhevm-contracts) provides a comprehensive collection of secure, pre-tested Solidity templates optimized for fhEVM development. These templates leverage the TFHE library to enable encrypted computations while maintaining security and extensibility.