Docs : rectify typographical inaccuracies

docs/devdocs/Writing Smart Contracts/FHE-sol.mdx

@@ -12,7 +12,7 @@ A core component of the Fhenix ecosystem is the `FHE.sol` Solidity library.
 
 `FHE.sol` is a Solidity library designed to facilitate the use of Fully Homomorphic Encryption (FHE) within Ethereum smart contracts. FHE enables computations to be performed on encrypted data (ciphertexts) without needing to decrypt them first. The results of such computations, when decrypted, are identical to what would have been obtained if the operations had been performed on the unencrypted data (plaintexts).
 
-A full list and description of Fhenix functions is provided in [FHE.sol documentation](../Solidity%20API/FHE.md).
+A full list and description of Fhenix functions are provided in [FHE.sol documentation](../Solidity%20API/FHE.md).
 
 ## Installation
 

docs/devdocs/Writing Smart Contracts/Gas-and-Benchmarks.md

@@ -1,6 +1,6 @@
 # 🔥 Gas and Benchmarks
 
-This section will list the gas costs for every operation based on it's inputs.
+This section will list the gas costs for every operation based on its inputs.
 The gas prices are subject to change based on usage and performance.
 
 :::tip

docs/devdocs/Writing Smart Contracts/Permissions.md

@@ -10,7 +10,7 @@ The `Permissioned` contract is an abstract Solidity contract that leverages EIP-
 
 ## Use Cases
 
-One of the common use cases for such access control is in scenarios where sensitive information must be retrieved from a contract but should not be publicly accessible. For example, a contract managing private user data may implement view functions which require a signature to confirm the identity of the requester. This ensures that only the user or an authorized party can access that user's data.
+One of the common use cases for such access control is in scenarios where sensitive information must be retrieved from a contract but should not be publicly accessible. For example, a contract managing private user data may implement view functions that require a signature to confirm the identity of the requester. This ensures that only the user or an authorized party can access that user's data.
 
 ## How to Use
 

docs/devdocs/Writing Smart Contracts/Returning-Data.md

@@ -44,7 +44,7 @@ The following JSON structure shows the components of the encrypted data returned
 
 ### Metamask Compatability
 
-The encryption schema and structure matches the one used by Metamask's eth_decrypt function. 
+The encryption schema and structure match the one used by Metamask's eth_decrypt function. 
 This means that we can consume sealed data directly from Metamask, which provides a more engaging experience for a dApp user. 
 
 Fetch an address's public key using the `eth_getEncryptionPublicKey` method, seal the data for that specific public key (either as a permit or by using the public key directly), and then use Metamask's `eth_decrypt` call to provide a guided decryption experience.

docs/devdocs/Writing Smart Contracts/Types-and-Operators.md

@@ -14,7 +14,7 @@ The library provides a type system that is checked both at compile time and at r
 
 We currently support encrypted integers of bit length up to 256 bits and special types such as `ebool` and `eaddress`.
 
-The encrypted integers behave as much as possible as Solidity's integer types. However, behaviour such as "revert on overflow" is not supported as this would leak some information of the encrypted integers. Therefore, arithmetic on `euint` types is [unchecked](https://docs.soliditylang.org/en/latest/control-structures.html#checked-or-unchecked-arithmetic), i.e. there is wrap-around on overlow.
+The encrypted integers behave as much as possible as Solidity's integer types. However, behavior such as "revert on overflow" is not supported as this would leak some information of the encrypted integers. Therefore, arithmetic on `euint` types is [unchecked](https://docs.soliditylang.org/en/latest/control-structures.html#checked-or-unchecked-arithmetic), i.e. there is wrap-around on overlow.
 
 In the back-end, encrypted integers are FHE ciphertexts. The library abstracts away the ciphertexts and presents pointers to ciphertexts, or ciphertext handles, to the smart contract developer. The `euint`, `ebool` and `eaddress` types are _wrappers_ over these handles.
 <table>

docs/devdocs/Writing Smart Contracts/Useful-Tips.md

@@ -19,7 +19,7 @@ To explain this tip we will use an example. Let's assume we want to develop a co
 Assuming that on each vote we increase (cryptographically with FHE.add) the tally, one can just monitor the key in the DB that represents this specific tally and once the key is changed he will know who we voted for.
 An ideal solution for this issue is to change all keys no matter who we voted for, but how?!
 
-In order to understand how we will first need to understand that FHE encryption is a non-deterministic encryption means that encrypting (non-trivial encryption) a number twice will result with 2 different encrypted outputs.
+In order to understand how we will first need to understand that FHE encryption is a non-deterministic encryption means that encrypting (non-trivial encryption) a number twice will result in 2 different encrypted outputs.
 
 Now that we know that, we can add 0 (cryptographically with FHE.add) to all of those tallies that shouldn't be changed and they will be changed in the DB!