From 8f40a23a6ce87a534d146fc535ede654067a82fc Mon Sep 17 00:00:00 2001 From: Laetho Date: Mon, 23 Sep 2024 15:04:15 +0700 Subject: [PATCH] fix some typos (#7320) --- docs/docs/02-apps/01-transfer/01-overview.md | 2 +- docs/docs/02-apps/01-transfer/09-client.md | 2 +- docs/docs/02-apps/01-transfer/10-ICS20-v1/09-client.md | 2 +- docs/requirements/path-unwinding-forwarding-requirements.md | 2 +- docs/tutorials/02-channel-upgrades/06-incentivize-packet.md | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/docs/02-apps/01-transfer/01-overview.md b/docs/docs/02-apps/01-transfer/01-overview.md index 31433d34f0f..d61ac19dbfb 100644 --- a/docs/docs/02-apps/01-transfer/01-overview.md +++ b/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 diff --git a/docs/docs/02-apps/01-transfer/09-client.md b/docs/docs/02-apps/01-transfer/09-client.md index 2a5940f4631..3ba88e6dfc1 100644 --- a/docs/docs/02-apps/01-transfer/09-client.md +++ b/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. diff --git a/docs/docs/02-apps/01-transfer/10-ICS20-v1/09-client.md b/docs/docs/02-apps/01-transfer/10-ICS20-v1/09-client.md index d55b8531271..20d8c2f10a0 100644 --- a/docs/docs/02-apps/01-transfer/10-ICS20-v1/09-client.md +++ b/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` diff --git a/docs/requirements/path-unwinding-forwarding-requirements.md b/docs/requirements/path-unwinding-forwarding-requirements.md index 1c0c7a447a7..973cd4f25f9 100644 --- a/docs/requirements/path-unwinding-forwarding-requirements.md +++ b/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 diff --git a/docs/tutorials/02-channel-upgrades/06-incentivize-packet.md b/docs/tutorials/02-channel-upgrades/06-incentivize-packet.md index f6b14a5b87b..49139fde97f 100644 --- a/docs/tutorials/02-channel-upgrades/06-incentivize-packet.md +++ b/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.