docs: various fixes for grammar, clarity, and consistency across documentation

docs/devdocs/Encryption and Privacy/Exposed-Encrypted-Variables.md

@@ -1,6 +1,6 @@
 # 🔎 Encrypted Variables - Preventing Exposure
 
-Ensuring that encrypted data and variables are not leaked is important when working with Fhenix. A common oversight when working with encrypted variables is revealing them to other contracts. Lets take a look at a scenario that leaks encrypted data:
+Ensuring that encrypted data and variables are not leaked is important when working with Fhenix. A common oversight when working with encrypted variables is revealing them to other contracts. Let's take a look at a scenario that leaks encrypted data:
 
 ```solidity
 contract UserBalanceVulnerable {
@@ -14,7 +14,7 @@ contract UserBalanceVulnerable {
 }
 ```
 
-This seems secure enough and no decrypted data is directly exposed, however the `public` access to `eUserBalances` leaks sensitive data. A malicious contract is able to fetch this data and then decrypt it:
+This seems secure enough and no decrypted data is directly exposed; however the `public` access to `eUserBalances` leaks sensitive data. A malicious contract is able to fetch this data and then decrypt it:
 
 ```solidity
 contract UserBalanceAttack {
@@ -72,7 +72,7 @@ contract ContractWithExposedVariables {
   }
 
   HoldEmGameState private gameState;
-  // Encrypted card values is the Player and Dealer structs are leaked and can be exploited
+  // Encrypted card values in the Player and Dealer structs are leaked and can be exploited
   function getGameState() public view returns (HoldEmGameState memory) {
     return gameState;
   }

docs/devdocs/Encryption and Privacy/Permits-Access-Control.md

@@ -25,16 +25,16 @@ The inclusion of this public key into the permit enables a secure process of dat
 Permits are generated using the `generatePermit` method in `fhenix.js`. This method receives the following parameters:
 
 * `contractAddress` (required, string): The address of the contract.
-* `provider` (optional): An `ethers` (or compatible) object that can sign EIP-712 formatted data. (Note that if you want to unseal data using your wallet's encryption key you can't use "JsonRpcProvider")
-* `signer` (optional): Another `ethers` (or compatible) signer if you want to use a different signer than the one in the provider (chain-id requests are still made via the provider)
+* `Provider` (optional): An `ethers` (or compatible) object that can sign EIP-712 formatted data. (Note that if you want to unseal data using your wallet's encryption key you can't use "JsonRpcProvider")
+* `signer` (optional): Another `ethers` (or compatible) signer if you want to use a different signer than the one in the Provider (chain-id requests are still made via the Provider)
 
 ```javascript
 const permit = await generatePermit(contractAddress);
 
 // passing a custom signer
 let permit = await fhenixjs.generatePermit(
     contractAddress,
-    undefined,         // use the internal provider
+    undefined,         // use the internal Provider
     signer,            // created from, e.g. `ethers.getSigners()[0]`
 );
 ```
@@ -63,10 +63,10 @@ The following code snippet shows how to implement the added cryptographic functi
 import { BrowserProvider } from "ethers";
 import { FhenixClient, getPermit } from "fhenixjs";
 
-const provider = new BrowserProvider(window.ethereum);
-const client = new FhenixClient({ provider });
-const permit = await generatePermit(contractAddress, provider);
-const permission = client.extractPemitPermissions(permit);
+const Provider = new BrowserProvider(window.ethereum);
+const client = new FhenixClient({ Provider });
+const permit = await generatePermit(contractAddress, Provider);
+const permission = client.extractPermitPermissions(permit);
 const response = await contract.connect(owner).getValue(permission); // Calling "getValue" which is a view function in "contract"
 const plaintext = await client.unseal(contractAddress, response);
 ```

docs/devdocs/Encryption and Privacy/Privacy-Web3.md

@@ -13,7 +13,7 @@ As a result of this analysis and the insights gained, structure your smart contr
 ##### A Simple Example
 A simple example of metadata leakage is gas usage. Consider a smart contract coded in Solidity that contains a conditional statement. In this case, the path taken by the condition, though encrypted, may still reveal information. A typical scenario is a conditional branch based on the value of a private variable, where gas usage, events, or other metadata could reveal the branch taken.
 
-```Javascript
+```JavaScript
 function performActionBasedOnBalance(uint256 amount) public {
     if (balance[msg.sender] >= amount) {
         // perform some operation
@@ -23,7 +23,7 @@ function performActionBasedOnBalance(uint256 amount) public {
 }
 ```
 
-In the above Solidity example, someone observing the transaction could potentially infer the chosen branch based on gas usage, events or metadata, which would, in turn, indirectly reveal whether the sender's balance was greater than or equal to the specified amount.
+In the above Solidity example, someone observing the transaction could potentially infer the chosen branch based on gas usage, events, or metadata, which would, in turn, indirectly reveal whether the sender's balance was greater than or equal to the specified amount.
 
 This example might seem insignificant, but it is important to remember that transactions can often be cheaply simulated with different input parameters. In the above example, performing a logarithmic search would reveal the exact balance fairly quickly.
 

docs/devdocs/Setting Up Your Environment/Foundry.md

@@ -58,11 +58,11 @@ contract MyTestContract is Test, FheEnabled {
 }
 ```
 
-During test setup, `initializeFhe` the FHE environment using the initializeFhe function:
+During test setup, `initializeFHE` the FHE environment using the initializeFHE function:
 
 ```solidity
 function setUp() public {
-    initializeFhe();
+    initializeFHE();
 }
 ```
 
@@ -121,8 +121,8 @@ operations are performed on plaintext data, which enables seamless development a
 operational FHE network. However, there are important differences between these mocked FHE operations and actual FHE
 operations:
 
-- Gas Costs – Gas costs associated with the mocked FHE operations do not accurately reflect those of real FHE
-  operations. Instead, they are based on gas costs of equivalent non-FHE operations.
+- Gas costs – Gas costs associated with the mocked FHE operations do not accurately reflect those of real FHE
+  operations. Instead, they are based on Gas costs of equivalent non-FHE operations.
 - Security Zones – In this mocked environment, security zones are not enforced. Thus, any user can perform operations
   between ciphertexts, which would otherwise fail in a real FHE setting.
 - Ciphertext Access – The mocked FHE operations do not enforce access control restrictions on ciphertexts, which allows

docs/devdocs/Setting Up Your Environment/Hardhat.md

@@ -8,10 +8,10 @@
 
 ## Clone Hardhat Template
 
-We provide a hardhat template available that comes "batteries included", with everything you need to hit the ground running. The template is [available here](https://github.com/fhenixprotocol/fhenix-hardhat-example). You can create a new repository, or clone it locally:
+We provide a Hardhat template available that comes "batteries included", with everything you need to hit the ground running. The template is [available here](https://github.com/fhenixprotocol/fhenix-Hardhat-example). You can create a new repository, or clone it locally:
 
 ```
-git clone https://github.com/fhenixprotocol/fhenix-hardhat-example
+git clone https://github.com/fhenixprotocol/fhenix-Hardhat-example
 ```
 
 You'll also probably want to set an .env file with your mnemonics:
@@ -38,10 +38,10 @@ To start a LocalFhenix instance, run the following command:
 pnpm localfhenix:start
 ```
 
-This will start a LocalFhenix instance in a docker container, managed by the `fhenix-hardhat-docker` plugin for Hardhat. 
-If this worked you should see a `LocalFhenix started` message in your console.
+This will start a LocalFhenix instance in a docker container, managed by the `fhenix-Hardhat-docker` plugin for Hardhat. 
+If this worked you should see a `LocalFhenix started!` message in your console.
 
-You've now officially created a LocalFhenix testnet. 🎉
+You've now officially set up a LocalFhenix testnet!. 🎉
 
 After you're done, you can stop the LocalFhenix instance with:
 
@@ -54,7 +54,7 @@ pnpm localfhenix:stop
 To deploy the contracts to LocalFhenix, run the following command:
 
 ```sh
-pnpm hardhat deploy
+pnpm Hardhat deploy
 ```
 
 This will compile the contracts in the `contracts` directory and deploy them to the LocalFhenix network.

docs/devdocs/Tools and Utilities/Fhenix-Hardhat-Plugin.md

@@ -111,7 +111,7 @@ await hre.fhenixjs.getFunds("your_wallet_address");
 ### Encryption
 
 ```javascript
-const encyrptedAmount = await fhenixjs.encrypt_uint32(15);
+const encryptedAmount = await fhenixjs.encrypt_uint32(15);
 ```
 
 ### Creating a Permit

docs/devdocs/Tutorials/Basic/Deploying.mdx

@@ -12,12 +12,12 @@ Now that we have our completed WrappingERC20 token, the next step is to see if o
 To do this, we'll be writing tests in typescript using hardhat, and deploying them on our [LocalFhenix](../../Setting%20Up%20Your%20Environment/Hardhat.md#start-localfhenix) environment which we set up earlier.
 
 :::tip[Note]
-At this stage, using hardhat network is not supported, as Fhenix uses custom extensions to the EVM that enable FHE operations
+At this stage, using the Hardhat network is not supported, as Fhenix uses custom extensions to the EVM that enable FHE operations
 :::
 
 ### Compiling the Contract
 
-#### Compiling your contracts
+#### Compiling Your Contracts
 
 First, let's see that our current contract is even valid. Let's run the following:
 
@@ -139,12 +139,12 @@ Now we can use this task to deploy our contract to either LocalFhenix, or the De
     </TabItem>
 </Tabs>
 
-Okay, now we know how to create programmatic actions. You can find a few other examples of tasks that interact with the deployed contract in the [`tasks` ](https://github.com/FhenixProtocol/werc20-example/tree/main/tasks)folder.
+Now we know how to create programmatic actions. You can find a few other examples of tasks that interact with the deployed contract in the [`tasks` ](https://github.com/FhenixProtocol/werc20-example/tree/main/tasks)folder.
 
 
 
 :::tip[Making Changes?]
-When deploying a contract hardhat creates a static deployment. If you want to make changes and redeploy using this method run
+When deploying a contract, Hardhat creates a static deployment. If you want to make changes and redeploy using this method run
 <Tabs groupId="package-managers">
     <TabItem value="npm" label="npm">
         **`npm run clean`**

docusaurus.config.ts

@@ -128,7 +128,7 @@ const config: Config = {
           position: 'right',
         },
         {
-          href: 'https://twitter.com/FhenixIO',
+          href: 'https://x.com/FhenixIO',
           className: 'header-twitter-link',
           position: 'right',
         },
@@ -170,7 +170,7 @@ const config: Config = {
             },
             {
               label: 'Twitter',
-              href: 'https://twitter.com/FhenixIO',
+              href: 'https://x.com/FhenixIO',
             },
           ],
         },

src/components/HomepageFeatures/index.tsx

@@ -146,7 +146,7 @@ export default function HomepageFeatures(): JSX.Element {
               <div style={{ display: 'flex', gap: '20px' }}>
                 <Link
                     className='tutorial-button'
-                    to={"https://twitter.com/FhenixIO"}>
+                    to={"https://x.com/FhenixIO"}>
                     <div style={{ display: 'flex', justifyContent: 'center', alignItems: "center", gap: '10px' }}> 
                       X / Twitter <img src="img/x.svg" style={{ width: '15px'}}/>
                     </div>

versioned_docs/version-Helium/devdocs/FhenixJS/Decryption.md

@@ -8,7 +8,7 @@ When an app wants to read some piece of encrypted data from a Fhenix smart contr
 
 The process of taking an FHE-encrypted ciphertext and converting it to standard encryption is called **sealing.**
 
-The data is returned to the user using [sealed box encryption ](https://bitbeans.gitbooks.io/libsodium-net/content/public-key\_cryptography/sealed\_boxes.html)from NaCL. The gist of it is that the user provides a public key to the contract during a view function call, which the contract then uses to encrypt the data in such a way that only the owner of the private key associated with the provided public key can decrypt and read the data.
+The data is returned to the user using [sealed box encryption](https://bitbeans.gitbooks.io/libsodium-net/content/public-key\_cryptography/sealed\_boxes.html)from NaCl. The gist of it is that the user provides a public key to the contract during a view function call, which the contract then uses to encrypt the data in such a way that only the owner of the private key associated with the provided public key can decrypt and read the data.
 
 :::tip[Don't Want to Seal?]
 Fhenix supports standard decryption as well. Mostly suited for public data, an unsealed plaintext value can be returned from a contract.
@@ -26,9 +26,9 @@ The main difference with inEuint* is that you can be explicit with what is the e
 A `Permit` is a data structure that helps contracts know who is trying to call a specific function. 
 
 The fhenix.js Javascript library includes methods to support creating parameters for values that require [Permits & Access Control](../Encryption%20and%20Privacy/Permits-Access-Control.md). These methods can help creating ephemeral transaction keys, which are used by the smart contract to create a secure encryption channel to the caller.
-Similarly to decryption, this usage can be implemented by any compliant library, but we include direct support in fhenix.js. 
+Similar to decryption, this can be implemented by any compliant library, but direct support is included in fhenix.js. 
 
-This is done in 3 steps: generating a permit, querying the contract and unsealing the data.
+This process involves three steps: generating a permit, querying the contract, and unsealing the data.
 
 #### 1. Creating a Permit
 
@@ -91,7 +91,7 @@ const plaintext = client.unseal(contractAddress, response);
 console.log(`My Balance: ${plaintext}`)
 ```
 :::tip[Did you know?]
-You have tools that can ease the process of interacting with the contract and decrypting values. If you want to use them please refer to
+There are tools available to simplify interacting with contracts and decrypting values. If you want to use them please refer to
 [Tools and Utilities](../Tools%20and%20Utilities/Fhenix-Encryption-UI) 
 :::
 

versioned_docs/version-Helium/devdocs/FhenixJS/Permits.md

@@ -8,17 +8,17 @@ title: Permits
 
 ## Overview
 
-Permits are a mechanism that allows the contract to cryptographically verify that the caller is who he says he is.
+Permits are a mechanism that allows the contract to cryptographically verify that the caller is who they claim to be.
 
-Simply, they are a signed message that contains the caller's public key, which the contract can then use to verify that the caller is who he says he is.
+Simply put, a permit is a signed message that contains the caller's public key, which the contract can then use to verify that the caller is who they claim to be.
 
 ## Usage
 
 Permits are meant to be used together with the interfaces exposed by [`Permissioned.Sol`](../Solidity%20API/Permissioned). If a contract expects a `Signature`
 parameter, that's a good sign that we should use a `permit` to manage and create user permissions.
 
 
-Out-of-the-box, Fhenix Solidity libraries come with a basic access control scheme. This helps contracts perform a basic check for ownership of an account.
+The Fhenix Solidity libraries include a built-in access control scheme. This helps contracts perform a basic check for ownership of an account.
 
 To confirm whether the recipient is authorized, EIP712 signatures are employed. EIP712 is a standard for Ethereum signed messages that makes it easier to understand the information being signed. This allows us to verify that the signer of a given piece of data is the owner of the account they claim to be.