Correct minor typos

docs/content/api/api.en.md

@@ -67,9 +67,9 @@ enum TransferState {
     UNSPECIFIED = 0;  // the transfer state is unknown or not specified
     STARTED = 1;      // this is the first message in the TRISA workflow
     PENDING = 2;      // action is required by the sending party
-    REVIEW = 3;       // action is required by the recieving party (rarely used)
+    REVIEW = 3;       // action is required by the receiving party (rarely used)
     REPAIR = 4;       // some state of the travel rule exchange requires repair
-    ACCEPTED = 5;     // the travel rule exchange is accepted and waiting the transaction
+    ACCEPTED = 5;     // the travel rule exchange is accepted and awaiting the transaction
     COMPLETED = 6;    // the travel rule and on-chain transaction have been completed
     REJECTED = 7;     // the travel rule exchange is rejected and should not proceed
 }

docs/content/api/errors.en.md

@@ -48,7 +48,7 @@ See the [error protocol buffers](https://github.com/trisacrypto/trisa/blob/main/
 | 103 | UNVERIFIED | Could not verify certificates with any certificate authority. |
 | 104 | UNTRUSTED | A trusted connection could not be established. |
 | 105 | INVALID_SIGNATURE | An HMAC signature could not be verified. |
-| 106 | INVALID_KEY | The transaction bundle cannot be decrypted with the specified key |
+| 106 | INVALID_KEY | The transaction bundle cannot be decrypted with the specified key. |
 | 107 | ENVELOPE_DECODE_FAIL | Could not decode or decrypt private transaction data. (Alias: Sygna BVRC Rejected Type) |
 | 107 | PRIVATE_INFO_DECODE_FAIL | Could not decode or decrypt private transaction data. (Alias: Sygna BVRC Rejected Code) |
 | 107 | BVRC005 | Could not decode or decrypt private transaction data. |

docs/content/api/workflows.md

@@ -42,9 +42,9 @@ flowchart LR
 
 ## Workflows
 
-While the flow diagram above does a good job explaining how to transition a Transfer between states, it does not describe how those states might be engaged in practice using the `TransferRPC` and different payloads. This section contains sequence diagrams for standard worklows and exchanges.
+While the flow diagram above does a good job explaining how to transition a Transfer between states, it does not describe how those states might be engaged in practice using the `TransferRPC` and different payloads. This section contains sequence diagrams for standard workflows and exchanges.
 
-Keep in mind that **the goal of a TRISA workflow is ensure that both counterparties have the exact same Travel Rule payload**, stored using a cryptographic method that
+Keep in mind that **the goal of a TRISA workflow is to ensure that both counterparties have the exact same Travel Rule payload**, stored using a cryptographic method that
 only they can decrypt.
 
 In practice, this means that an RPC request may be "echoed" as a response -- e.g. you may receive a secure envelope where the only action you have to take to "accept" the request is to send the same payload back to the requester, encrypted using the requester's public keys. This also means that you should not omit travel rule information payloads from each response as the last message contains the payload in the "final state" ready to be stored for the compliance statute of limitations.
@@ -142,7 +142,7 @@ sequenceDiagram
     end
 ```
 
-Note that the originator VASP should not perform any actions on the blockchain specified after receiving a rejection according to the rules of their jurisdiction. If the beneficary VASP recieves the block chain transaction anyway, they should proceed by quarantining the transaction according to the rules of their jurisdiction. Keep in mind that sending a TRISA rejection message does not prevent any blockchain transactions, it is simply a signal to the counterparty not to proceed.
+Note that the originator VASP should not perform any actions on the blockchain specified after receiving a rejection according to the rules of their jurisdiction. If the beneficiary VASP receives the block chain transaction anyway, they should proceed by quarantining the transaction according to the rules of their jurisdiction. Keep in mind that sending a TRISA rejection message does not prevent any blockchain transactions, it is simply a signal to the counterparty not to proceed.
 
 ### Repair Workflow
 

proto/trisa/api/v1beta1/api.proto

@@ -129,9 +129,9 @@ enum TransferState {
     UNSPECIFIED = 0;  // the transfer state is unknown or not specified
     STARTED = 1;      // this is the first message in the TRISA workflow
     PENDING = 2;      // action is required by the sending party
-    REVIEW = 3;       // action is required by the recieving party (rarely used)
+    REVIEW = 3;       // action is required by the receiving party (rarely used)
     REPAIR = 4;       // some state of the travel rule exchange requires repair
-    ACCEPTED = 5;     // the travel rule exchange is accepted and waiting the transaction
+    ACCEPTED = 5;     // the travel rule exchange is accepted and awaiting the transaction
     COMPLETED = 6;    // the travel rule and on-chain transaction have been completed
     REJECTED = 7;     // the travel rule exchange is rejected and should not proceed
 }