fix some typos

docs/docs/02-apps/01-transfer/01-overview.md

@@ -138,7 +138,7 @@ a multi-denom collections of tokens is also allowed (i.e. forwarding of tokens o
 ### Unwind tokens
 
 Taking again as an example the topology from the previous section, we assume that native tokens on chain `A`
-have been transfered to chain `C`. The IBC vouchers on chain `C` have the denomination trace
+have been transferred to chain `C`. The IBC vouchers on chain `C` have the denomination trace
 `transfer/channelCtoB/transfer/channelBtoA`, and with forwarding it is possible to submit a transfer message 
 on chain `C` and automatically unwind the vouchers through chain `B` to chain `A`, so that the tokens recovered
 on the origin chain regain their native denomination. In order to execute automatic unwinding, the transfer

docs/docs/02-apps/01-transfer/09-client.md

@@ -42,7 +42,7 @@ The additional flags that can be used with the command are:
 
 - `--packet-timeout-height` to specify the timeout block height in the format `{revision}-{height}`. The default value is `0-0`, which effectively disables the timeout. Timeout height can only be absolute, therefore this option must be used in combination with `--absolute-timeouts` set to true.
 - `--packet-timeout-timestamp` to specify the timeout timestamp in nanoseconds. The timeout can be either relative (fromthe current UTC time) or absolute. The default value is 10 minutes (and thus relative). The timeout is disabled when set to 0.
-- `--absolute-timeouts` to interpret the timeout timestamp as an aboslute value (when set to true). The default value is false (and thus the timeout timeout is considered relative to current UTC time).
+- `--absolute-timeouts` to interpret the timeout timestamp as an absolute value (when set to true). The default value is false (and thus the timeout timeout is considered relative to current UTC time).
 - `--memo` to specify the memo string to be sent along with the transfer packet. If forwarding is used, then the memo string will be carried through the intermediary chains to the final destination.
 - `--forwarding` to specify forwarding information in the form of a comma separated list of source port ID/channel ID pairs at each intermediary chain (e.g. `transfer/channel-0,transfer/channel-1`).
 - `--unwind` to specify if the tokens must be automatically unwound to there origin chain. This option can be used in combination with `--forwarding` to forward the tokens to the final destination after unwinding. When this flag is true, the tokens specified in the `coins` option must all have the same denomination trace path (i.e. all tokens must be IBC vouchers sharing exactly the same set of destination port/channel IDs in their denomination trace path). Arguments `[src-port]` and  `[src-channel]` must not be passed if the `--unwind` flag is specified.

docs/docs/02-apps/01-transfer/10-ICS20-v1/09-client.md

@@ -45,7 +45,7 @@ The additional flags that can be used with the command are:
 
 - `--packet-timeout-height` to specify the timeout block height in the format `{revision}-{height}`. The default value is `0-0`, which effectively disables the timeout. Timeout height can only be absolute, therefore this option must be used in combination with `--absolute-timeouts` set to true.
 - `--packet-timeout-timestamp` to specify the timeout timestamp in nanoseconds. The timeout can be either relative (fromthe current UTC time) or absolute. The default value is 10 minutes (and thus relative). The timeout is disabled when set to 0.
-- `--absolute-timeouts` to interpret the timeout timestamp as an aboslute value (when set to true). The default value is false (and thus the timeout timeout is considered relative to current UTC time).
+- `--absolute-timeouts` to interpret the timeout timestamp as an absolute value (when set to true). The default value is false (and thus the timeout timeout is considered relative to current UTC time).
 - `--memo` to specify the memo string to be sent along with the transfer packet. If forwarding is used, then the memo string will be carried through the intermediary chains to the final destination.
 
 #### `total-escrow`

docs/requirements/path-unwinding-forwarding-requirements.md

@@ -6,7 +6,7 @@ The implementation of fungible token path unwinding vastly simplifies token tran
 
 Path unwinding reduces the complexity of token transfer for the end user; a user simply needs to choose the final destination for their tokens and the complexity of determining the optimal route is abstracted away. This is a huge user experience improvement.
 
-In addition to unwinding, when a user recieves their token on a destination chain, they then want to use the token in some way. By enabling token forwarding, a user can recieve a token, perform some action with that token, for example a swap, and then send the token onto another chain. We observe that the complexity of IBC is increasingly being abstracted away from end users and automating workflows such as transfer, swap and forward with a single signed transaction significantly enhances usability. 
+In addition to unwinding, when a user receives their token on a destination chain, they then want to use the token in some way. By enabling token forwarding, a user can receive a token, perform some action with that token, for example a swap, and then send the token onto another chain. We observe that the complexity of IBC is increasingly being abstracted away from end users and automating workflows such as transfer, swap and forward with a single signed transaction significantly enhances usability. 
 
 ## Problem
 

docs/tutorials/02-channel-upgrades/06-incentivize-packet.md

@@ -102,4 +102,4 @@ pagination:
   total: "2"
 ```
 
-An amount of `1075samoleans` has been deducted, which is what we expected: `1000samoleans` have been transfered to `VALIDATOR_CHAIN2` and `75stake` have been paid for the receive and acknowledgment fees. The timeout fee has been refunded to `VALIDATOR_CHAIN1` and the relayer address `RLY_CHAIN1` should have gained `75samoleans` for submitting the `MsgRecvPacket` and the `MsgAcknowledgement` messages.
+An amount of `1075samoleans` has been deducted, which is what we expected: `1000samoleans` have been transferred to `VALIDATOR_CHAIN2` and `75stake` have been paid for the receive and acknowledgment fees. The timeout fee has been refunded to `VALIDATOR_CHAIN1` and the relayer address `RLY_CHAIN1` should have gained `75samoleans` for submitting the `MsgRecvPacket` and the `MsgAcknowledgement` messages.