docs: typo fixes

docs/references/gateway_api.md

@@ -28,18 +28,18 @@ None.
 **Success (200 OK)**
 
 The request is successful, and the response will include a JSON object with a `status` and a `response`. The response again consists of the following elements: 
-- `crs`: A map of mapping of different CRS'. The key of the map is the max amount of bits the CRS can support proofs for. The value is then an object of the following elements:
+- `crs`: A map of containing information on the different CRS'. The key of the map is the max amount of bits the CRS can support proofs for. The value is an object of the following elements for the given CRS:
     * `data_id`: The 20 byte (lower-case) hex encoded handle/ID identifying the CRS.
     * `param_choice`: An integer representing the choice of parameters for the public key to be used with the CRS. 
     * `signatures`: A list of signatures (one from each TKMS). Each signature is a hex (lower-case) encoded EIP712 signature on the `safe_serialization` of `PublicParam<Bls12_446>`.
     * `urls`: A list of URLs where the data can be fetched. The data at the end-point is a `safe_serialization` of `PublicParam<Bls12_446>`.
-- `fhe_key_info`: A list of elements, each representing information on a key-set in the system. More specifically each element consists of the following:
+- `fhe_key_info`: A list of objects, each representing information on a key-set in the system. More specifically each element consists of the following:
     * `fhe_public_key`: An element which contains information about the public encryption key of a FHE key set. More specifically it consists of the following elements:
         * `data_id`: The 20 byte (lower-case) hex encoded handle/ID identifying the key.
         * `param_choice`: An integer representing the choice of parameters used to generate the key. 
         * `signatures`: A list of signatures (one from each TKMS). Each signature is a hex (lower-case) encoded EIP712 signature on the `safe_serialization` of `CompactPublicKey`.
         * `urls`: A list of URLs where the data can be fetched. The data at the end-point is a `safe_serialization` of `CompactPublicKey`.
-    * `fhe_server_key`: An element which contains information about the server key (the key for performing FHE operations on ciphertexts) of a FHE key set. More specifically it consists of the following elements:
+    * `fhe_server_key`: An element which contains information about the server key (the key used to perform FHE operations on ciphertexts) of a FHE key set. More specifically it consists of the following elements:
         * `data_id`: The 20 byte (lower-case) hex encoded handle/ID identifying the key.
         * `param_choice`: An integer representing the choice of parameters used to generate the key. 
         * `signatures`: A list of signatures (one from each TKMS). Each signature is a hex (lower-case) encoded EIP712 signature on the `safe_serialization` of `CompactPublicKey`.
@@ -178,18 +178,18 @@ For example the following:
 
 #### Description
 
-This endpoint returns a JSON object containing all the signatures on the proven ciphertext from the TKMS servers. Furthermore the response contain some meta-information distinguishing if the response is for the co-processor setting or fhEVM native setting. In case of the co-processor setting, then the ciphertext storage handles and a signature from the co-processor attesting correct storage is also included.
+This endpoint returns a JSON object containing all the signatures on the proven ciphertexts from the TKMS servers. Furthermore the response contains some meta-information distinguishing if the response is for the co-processor setting or fhEVM native setting. In case of the co-processor setting, then the ciphertext storage handles and a signature from the co-processor attesting correct storage is also included.
 
-The signatures from the TKMS should be considered as a multi-sig. This means that instead of needing all the signatures to validate the content, only a subset, specifically >1/3 of the total signatures (if n nodes are signing), is required to verify that the content is legitimate. 
+The signatures from the TKMS should be considered as a multi-sig. This means that instead of needing all the signatures to validate the content, only a subset, specifically >1/3 of the total signatures, is required to verify that the content is legitimate. 
 
 #### Query Parameters
 
-Multiple parameters must be supplied as a json file. 
+Multiple parameters must be supplied as a JSON file:
 - `contract_address`: An EIP-55 encoded address (that is, including the `0x` prefix) of the contract where the proven ciphertext is to be submitted.
 - `caller_address`: An EIP-55 encoded address (that is, including the `0x` prefix) of the user who is providing the encrypted input.
 - `crs_id`: The 20 byte (lower-case) hex encoded handle/ID identifying the CRS used to construct the proof.
 - `key_id`: The 20 byte (lower-case) hex encoded handle/ID identifying the public key used to encrypt the ciphertext with.
-- "ct_proof": A hex encoding of the serialization of the proven ciphertext. More specifically the TFHE-RS object `ProvenCompactCiphertextList` serialized using `safe_serialize`.
+- "ct_proof": A hex encoding of the serialization of the proven ciphertext. More specifically the TFHE-RS object `ProvenCompactCiphertextList` serialized using `safe_serialization`.
 
 ```json
 {
@@ -275,13 +275,13 @@ For example the following:
 
 #### Description
 
-This endpoint returns a JSON object containing a signcryption of the plaintext value of an FHE ciphertext that has been (obliviously) decrypted by the TKMS. 
+This end-point returns a JSON object containing a signcryption of the plaintext value of an FHE ciphertext that has been (obliviously) decrypted by the TKMS. 
 More specifically the TKMS servers carry out a partial decryption resulting in each of them knowing a secret share of the plaintext. They each then signcrypt their share of the plaintext. The response consists of each of these signcryptions along with meta information about the threshold setup and which server provides each signcrypted share of the result. 
-Since the signcryption is based on secret sharing it means that only a subset, specifically >1/3 of the total signatures (if n nodes are signing), is required to recover the result (assuming all returned signcryptions are correct). 
+Since the signcryption is based on secret sharing it means that only a subset, specifically >1/3 of the total signature, is required to recover the result (assuming all returned signcryptions are correct). 
 
 #### Query Parameters
 
-Multiple parameters must be supplied as a json file. 
+Multiple parameters must be supplied as a JSON file:
 - `signature`: A hex (lower-case) encoded EIP712 signature on the parameters of the request by a key owner permitted to do reencrypt of the ciphertext in question. 
 - `client_address`: An EIP-55 encoded address (that is, including the `0x` prefix) of the end-user who is supposed to learn the reencrypted response.
 - `enc_key`: The hex (lower-case) encoded public encryption key (libsodium) which the reencryption should be signcrypted under.