From 2bfad67098e64bbfa57d388f6da925e1696b1492 Mon Sep 17 00:00:00 2001 From: argentpapa Date: Wed, 18 Dec 2024 16:43:27 +0800 Subject: [PATCH] chore(docs):spellchecker (#7719) * chore(docs):spellchecker * chore: update github.com/cosmos/ics to github.com/cosmos/ibc in markdown files --------- Co-authored-by: Damian Nolan --- docs/architecture/adr-015-ibc-packet-receiver.md | 2 +- docs/architecture/adr-026-ibc-client-recovery-mechanisms.md | 6 +++--- docs/docs/01-ibc/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/docs/04-middleware/02-callbacks/01-overview.md | 2 +- docs/tutorials/02-channel-upgrades/06-incentivize-packet.md | 2 +- docs/versioned_docs/version-v4.6.x/01-ibc/01-overview.md | 2 +- docs/versioned_docs/version-v5.4.x/01-ibc/01-overview.md | 2 +- docs/versioned_docs/version-v6.3.x/01-ibc/01-overview.md | 2 +- docs/versioned_docs/version-v7.8.x/01-ibc/01-overview.md | 2 +- docs/versioned_docs/version-v8.5.x/01-ibc/01-overview.md | 2 +- docs/versioned_docs/version-v9.0.x/01-ibc/01-overview.md | 2 +- .../version-v9.0.x/02-apps/01-transfer/09-client.md | 2 +- .../02-apps/01-transfer/10-ICS20-v1/09-client.md | 2 +- .../04-middleware/02-callbacks/01-overview.md | 2 +- 16 files changed, 18 insertions(+), 18 deletions(-) diff --git a/docs/architecture/adr-015-ibc-packet-receiver.md b/docs/architecture/adr-015-ibc-packet-receiver.md index 591694ba3b8..3fbe090ce94 100644 --- a/docs/architecture/adr-015-ibc-packet-receiver.md +++ b/docs/architecture/adr-015-ibc-packet-receiver.md @@ -295,5 +295,5 @@ Proposed ## References -- Relevant comment: [cosmos/ics#289](https://github.com/cosmos/ics/issues/289#issuecomment-544533583) +- Relevant comment: [cosmos/ics#289](https://github.com/cosmos/ibc/issues/289#issuecomment-544533583) - [ICS26 - Routing Module](https://github.com/cosmos/ibc/tree/master/spec/core/ics-026-routing-module) diff --git a/docs/architecture/adr-026-ibc-client-recovery-mechanisms.md b/docs/architecture/adr-026-ibc-client-recovery-mechanisms.md index 2c295ad9ae7..efad623b5c9 100644 --- a/docs/architecture/adr-026-ibc-client-recovery-mechanisms.md +++ b/docs/architecture/adr-026-ibc-client-recovery-mechanisms.md @@ -84,7 +84,7 @@ No neutral consequences. ## References -- [Prior discussion](https://github.com/cosmos/ics/issues/421) -- [Epoch number discussion](https://github.com/cosmos/ics/issues/439) -- [Upgrade plan discussion](https://github.com/cosmos/ics/issues/445) +- [Prior discussion](https://github.com/cosmos/ibc/issues/421) +- [Epoch number discussion](https://github.com/cosmos/ibc/issues/439) +- [Upgrade plan discussion](https://github.com/cosmos/ibc/issues/445) - [Migration from gov v1beta1 to gov v1](https://github.com/cosmos/ibc-go/issues/3672) diff --git a/docs/docs/01-ibc/01-overview.md b/docs/docs/01-ibc/01-overview.md index d2918a09519..504a0c4039d 100644 --- a/docs/docs/01-ibc/01-overview.md +++ b/docs/docs/01-ibc/01-overview.md @@ -157,7 +157,7 @@ under the path and a proof to the counterparty chain. Proofs are passed from core IBC to light clients as bytes. It is up to light client implementations to interpret these bytes appropriately. - The paths that all IBC implementations must use for committing IBC messages is defined in -[ICS-24 Host State Machine Requirements](https://github.com/cosmos/ics/tree/master/spec/core/ics-024-host-requirements). +[ICS-24 Host State Machine Requirements](https://github.com/cosmos/ibc/tree/master/spec/core/ics-024-host-requirements). - The proof format that all implementations must be able to produce and verify is defined in [ICS-23 Proofs](https://github.com/cosmos/ics23) implementation. ### [Ports](https://github.com/cosmos/ibc-go/blob/main/modules/core/05-port) diff --git a/docs/docs/02-apps/01-transfer/09-client.md b/docs/docs/02-apps/01-transfer/09-client.md index c9dfac2c992..80c3910b3de 100644 --- a/docs/docs/02-apps/01-transfer/09-client.md +++ b/docs/docs/02-apps/01-transfer/09-client.md @@ -41,7 +41,7 @@ of amount and denomination (e.g. `100uatom,100uosmo`) in the `coins` option. 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. +- `--packet-timeout-timestamp` to specify the timeout timestamp in nanoseconds. The timeout can be either relative (from the 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 absolute value (when set to true). The default value is false (and thus the 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`). 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 5b4c57dc0fa..2634673adca 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 @@ -44,7 +44,7 @@ The `coins` parameter accepts the amount and denomination (e.g. `100uatom`) of t 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. +- `--packet-timeout-timestamp` to specify the timeout timestamp in nanoseconds. The timeout can be either relative (from the 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 absolute value (when set to true). The default value is false (and thus the 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. diff --git a/docs/docs/04-middleware/02-callbacks/01-overview.md b/docs/docs/04-middleware/02-callbacks/01-overview.md index eae194b2b96..6dce7ed4759 100644 --- a/docs/docs/04-middleware/02-callbacks/01-overview.md +++ b/docs/docs/04-middleware/02-callbacks/01-overview.md @@ -51,5 +51,5 @@ And the following diagram shows how a typical `SendPacket` and `WriteAcknowledge - The receive packet callback does not pass IBC Actor's address, this is because the IBC Actor lives in the counterparty chain and cannot be trusted. :::warning -If the callbacks middleware wraps the transfer application, we strongly discourage the usage of source callbacks if [`MsgTransfer` includes forwarding information](https://github.com/cosmos/ibc-go/blob/v9.0.0-rc.0/proto/ibc/applications/transfer/v1/tx.proto#L54-L55) (which is only supported from ICS20 v2). Source callback information will be executed on the last hop before the destination chain, not on the sending chain. The explanation for this behaviour is that, if the tokens are routed through intermediary chains, then the transfer application on the sending chain will construct a packet data where the [`memo` field](https://github.com/cosmos/ibc-go/blob/v9.0.0-rc.0/proto/ibc/applications/transfer/v2/packet.proto#L38) is empty, and any [memo string](https://github.com/cosmos/ibc-go/blob/v9.0.0-rc.0/proto/ibc/applications/transfer/v1/tx.proto#L51) included in `MsgTransfer` is placed in the [`destination_memo` field](https://github.com/cosmos/ibc-go/blob/v9.0.0-rc.0/proto/ibc/applications/transfer/v2/packet.proto#L48). This makes it impossible to trigger the source callbacks on the sending chain, since the memo string is not available in the `memo` field. Then, on the chain before the final destination chain, the transfer application will construct the packet data with the memo string back in the `memo` field, so that it can be consumed by the callbacks middleware on the destination chain. However, if the `memo` field of `FungibleTokenPacketDataV2` is not empty on the chain before the final destination and the transfer application on that chain is wrapped by callbacks middleware, then the source callbacks would be triggered. Therefore, in order to prevent this unexpected behaviour (i.e. source callbacks triggered not on sending chain, but on the intermediary chain before the final destination) we are strongly recommeding to not include source callbacks information in the `memo` field of `MsgTransfer`. +If the callbacks middleware wraps the transfer application, we strongly discourage the usage of source callbacks if [`MsgTransfer` includes forwarding information](https://github.com/cosmos/ibc-go/blob/v9.0.0-rc.0/proto/ibc/applications/transfer/v1/tx.proto#L54-L55) (which is only supported from ICS20 v2). Source callback information will be executed on the last hop before the destination chain, not on the sending chain. The explanation for this behaviour is that, if the tokens are routed through intermediary chains, then the transfer application on the sending chain will construct a packet data where the [`memo` field](https://github.com/cosmos/ibc-go/blob/v9.0.0-rc.0/proto/ibc/applications/transfer/v2/packet.proto#L38) is empty, and any [memo string](https://github.com/cosmos/ibc-go/blob/v9.0.0-rc.0/proto/ibc/applications/transfer/v1/tx.proto#L51) included in `MsgTransfer` is placed in the [`destination_memo` field](https://github.com/cosmos/ibc-go/blob/v9.0.0-rc.0/proto/ibc/applications/transfer/v2/packet.proto#L48). This makes it impossible to trigger the source callbacks on the sending chain, since the memo string is not available in the `memo` field. Then, on the chain before the final destination chain, the transfer application will construct the packet data with the memo string back in the `memo` field, so that it can be consumed by the callbacks middleware on the destination chain. However, if the `memo` field of `FungibleTokenPacketDataV2` is not empty on the chain before the final destination and the transfer application on that chain is wrapped by callbacks middleware, then the source callbacks would be triggered. Therefore, in order to prevent this unexpected behaviour (i.e. source callbacks triggered not on sending chain, but on the intermediary chain before the final destination) we are strongly recommending to not include source callbacks information in the `memo` field of `MsgTransfer`. ::: diff --git a/docs/tutorials/02-channel-upgrades/06-incentivize-packet.md b/docs/tutorials/02-channel-upgrades/06-incentivize-packet.md index 49139fde97f..ef766ad6e2e 100644 --- a/docs/tutorials/02-channel-upgrades/06-incentivize-packet.md +++ b/docs/tutorials/02-channel-upgrades/06-incentivize-packet.md @@ -30,7 +30,7 @@ simd q ibc-fee counterparty-payee channel-0 $RLY_CHAIN2 --node http://localhost: counterparty_payee: cosmos1vdy5fp0jy2l2ees870a7mls357v7uad6ufzcyz ``` -We see that the counterparty payee address matches what we expected (i.e. the `RLY_CHAIN1` address). In this tutorial we are going to send only one packet from chain `chain1` to chain `chain2`, so we only need to register the counterparty payee on chain `chain2`. In real life circumstances relayers relay packets on both directions (i.e. from chain `chain1` to `chain2` and also viceversa), and thus relayers should register as well on chain `chain1` the counterparty payee address to be compensated for delivering the `MsgRecvPacket` on chain `chain1`. +We see that the counterparty payee address matches what we expected (i.e. the `RLY_CHAIN1` address). In this tutorial we are going to send only one packet from chain `chain1` to chain `chain2`, so we only need to register the counterparty payee on chain `chain2`. In real life circumstances relayers relay packets on both directions (i.e. from chain `chain1` to `chain2` and also vice-versa), and thus relayers should register as well on chain `chain1` the counterparty payee address to be compensated for delivering the `MsgRecvPacket` on chain `chain1`. ## Multi-message transaction with single `MsgPayPacketFee` message diff --git a/docs/versioned_docs/version-v4.6.x/01-ibc/01-overview.md b/docs/versioned_docs/version-v4.6.x/01-ibc/01-overview.md index 3bb823536d6..a804002a2e7 100644 --- a/docs/versioned_docs/version-v4.6.x/01-ibc/01-overview.md +++ b/docs/versioned_docs/version-v4.6.x/01-ibc/01-overview.md @@ -137,7 +137,7 @@ under the path and a proof to the counterparty chain. Proofs are passed from core IBC to light-clients as bytes. It is up to light client implementation to interpret these bytes appropriately. - The paths that all IBC implementations must use for committing IBC messages is defined in -[ICS-24 Host State Machine Requirements](https://github.com/cosmos/ics/tree/master/spec/core/ics-024-host-requirements). +[ICS-24 Host State Machine Requirements](https://github.com/cosmos/ibc/tree/master/spec/core/ics-024-host-requirements). - The proof format that all implementations must be able to produce and verify is defined in [ICS-23 Proofs](https://github.com/confio/ics23) implementation. ### [Capabilities](https://github.com/cosmos/cosmos-sdk/blob/main/docs/learn/advanced/10-ocap.md) diff --git a/docs/versioned_docs/version-v5.4.x/01-ibc/01-overview.md b/docs/versioned_docs/version-v5.4.x/01-ibc/01-overview.md index 3bb823536d6..a804002a2e7 100644 --- a/docs/versioned_docs/version-v5.4.x/01-ibc/01-overview.md +++ b/docs/versioned_docs/version-v5.4.x/01-ibc/01-overview.md @@ -137,7 +137,7 @@ under the path and a proof to the counterparty chain. Proofs are passed from core IBC to light-clients as bytes. It is up to light client implementation to interpret these bytes appropriately. - The paths that all IBC implementations must use for committing IBC messages is defined in -[ICS-24 Host State Machine Requirements](https://github.com/cosmos/ics/tree/master/spec/core/ics-024-host-requirements). +[ICS-24 Host State Machine Requirements](https://github.com/cosmos/ibc/tree/master/spec/core/ics-024-host-requirements). - The proof format that all implementations must be able to produce and verify is defined in [ICS-23 Proofs](https://github.com/confio/ics23) implementation. ### [Capabilities](https://github.com/cosmos/cosmos-sdk/blob/main/docs/learn/advanced/10-ocap.md) diff --git a/docs/versioned_docs/version-v6.3.x/01-ibc/01-overview.md b/docs/versioned_docs/version-v6.3.x/01-ibc/01-overview.md index 3bb823536d6..a804002a2e7 100644 --- a/docs/versioned_docs/version-v6.3.x/01-ibc/01-overview.md +++ b/docs/versioned_docs/version-v6.3.x/01-ibc/01-overview.md @@ -137,7 +137,7 @@ under the path and a proof to the counterparty chain. Proofs are passed from core IBC to light-clients as bytes. It is up to light client implementation to interpret these bytes appropriately. - The paths that all IBC implementations must use for committing IBC messages is defined in -[ICS-24 Host State Machine Requirements](https://github.com/cosmos/ics/tree/master/spec/core/ics-024-host-requirements). +[ICS-24 Host State Machine Requirements](https://github.com/cosmos/ibc/tree/master/spec/core/ics-024-host-requirements). - The proof format that all implementations must be able to produce and verify is defined in [ICS-23 Proofs](https://github.com/confio/ics23) implementation. ### [Capabilities](https://github.com/cosmos/cosmos-sdk/blob/main/docs/learn/advanced/10-ocap.md) diff --git a/docs/versioned_docs/version-v7.8.x/01-ibc/01-overview.md b/docs/versioned_docs/version-v7.8.x/01-ibc/01-overview.md index 637508f6359..33a152c3624 100644 --- a/docs/versioned_docs/version-v7.8.x/01-ibc/01-overview.md +++ b/docs/versioned_docs/version-v7.8.x/01-ibc/01-overview.md @@ -137,7 +137,7 @@ under the path and a proof to the counterparty chain. Proofs are passed from core IBC to light-clients as bytes. It is up to light client implementation to interpret these bytes appropriately. - The paths that all IBC implementations must use for committing IBC messages is defined in -[ICS-24 Host State Machine Requirements](https://github.com/cosmos/ics/tree/master/spec/core/ics-024-host-requirements). +[ICS-24 Host State Machine Requirements](https://github.com/cosmos/ibc/tree/master/spec/core/ics-024-host-requirements). - The proof format that all implementations must be able to produce and verify is defined in [ICS-23 Proofs](https://github.com/cosmos/ics23) implementation. ### [Capabilities](https://github.com/cosmos/cosmos-sdk/blob/main/docs/learn/advanced/10-ocap.md) diff --git a/docs/versioned_docs/version-v8.5.x/01-ibc/01-overview.md b/docs/versioned_docs/version-v8.5.x/01-ibc/01-overview.md index 62673d6c171..e0bf581dea4 100644 --- a/docs/versioned_docs/version-v8.5.x/01-ibc/01-overview.md +++ b/docs/versioned_docs/version-v8.5.x/01-ibc/01-overview.md @@ -157,7 +157,7 @@ under the path and a proof to the counterparty chain. Proofs are passed from core IBC to light-clients as bytes. It is up to light client implementation to interpret these bytes appropriately. - The paths that all IBC implementations must use for committing IBC messages is defined in -[ICS-24 Host State Machine Requirements](https://github.com/cosmos/ics/tree/master/spec/core/ics-024-host-requirements). +[ICS-24 Host State Machine Requirements](https://github.com/cosmos/ibc/tree/master/spec/core/ics-024-host-requirements). - The proof format that all implementations must be able to produce and verify is defined in [ICS-23 Proofs](https://github.com/cosmos/ics23) implementation. ### [Capabilities](https://github.com/cosmos/cosmos-sdk/blob/main/docs/learn/advanced/10-ocap.md) diff --git a/docs/versioned_docs/version-v9.0.x/01-ibc/01-overview.md b/docs/versioned_docs/version-v9.0.x/01-ibc/01-overview.md index d2918a09519..504a0c4039d 100644 --- a/docs/versioned_docs/version-v9.0.x/01-ibc/01-overview.md +++ b/docs/versioned_docs/version-v9.0.x/01-ibc/01-overview.md @@ -157,7 +157,7 @@ under the path and a proof to the counterparty chain. Proofs are passed from core IBC to light clients as bytes. It is up to light client implementations to interpret these bytes appropriately. - The paths that all IBC implementations must use for committing IBC messages is defined in -[ICS-24 Host State Machine Requirements](https://github.com/cosmos/ics/tree/master/spec/core/ics-024-host-requirements). +[ICS-24 Host State Machine Requirements](https://github.com/cosmos/ibc/tree/master/spec/core/ics-024-host-requirements). - The proof format that all implementations must be able to produce and verify is defined in [ICS-23 Proofs](https://github.com/cosmos/ics23) implementation. ### [Ports](https://github.com/cosmos/ibc-go/blob/main/modules/core/05-port) diff --git a/docs/versioned_docs/version-v9.0.x/02-apps/01-transfer/09-client.md b/docs/versioned_docs/version-v9.0.x/02-apps/01-transfer/09-client.md index c9dfac2c992..80c3910b3de 100644 --- a/docs/versioned_docs/version-v9.0.x/02-apps/01-transfer/09-client.md +++ b/docs/versioned_docs/version-v9.0.x/02-apps/01-transfer/09-client.md @@ -41,7 +41,7 @@ of amount and denomination (e.g. `100uatom,100uosmo`) in the `coins` option. 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. +- `--packet-timeout-timestamp` to specify the timeout timestamp in nanoseconds. The timeout can be either relative (from the 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 absolute value (when set to true). The default value is false (and thus the 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`). diff --git a/docs/versioned_docs/version-v9.0.x/02-apps/01-transfer/10-ICS20-v1/09-client.md b/docs/versioned_docs/version-v9.0.x/02-apps/01-transfer/10-ICS20-v1/09-client.md index 5b4c57dc0fa..2634673adca 100644 --- a/docs/versioned_docs/version-v9.0.x/02-apps/01-transfer/10-ICS20-v1/09-client.md +++ b/docs/versioned_docs/version-v9.0.x/02-apps/01-transfer/10-ICS20-v1/09-client.md @@ -44,7 +44,7 @@ The `coins` parameter accepts the amount and denomination (e.g. `100uatom`) of t 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. +- `--packet-timeout-timestamp` to specify the timeout timestamp in nanoseconds. The timeout can be either relative (from the 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 absolute value (when set to true). The default value is false (and thus the 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. diff --git a/docs/versioned_docs/version-v9.0.x/04-middleware/02-callbacks/01-overview.md b/docs/versioned_docs/version-v9.0.x/04-middleware/02-callbacks/01-overview.md index eae194b2b96..6dce7ed4759 100644 --- a/docs/versioned_docs/version-v9.0.x/04-middleware/02-callbacks/01-overview.md +++ b/docs/versioned_docs/version-v9.0.x/04-middleware/02-callbacks/01-overview.md @@ -51,5 +51,5 @@ And the following diagram shows how a typical `SendPacket` and `WriteAcknowledge - The receive packet callback does not pass IBC Actor's address, this is because the IBC Actor lives in the counterparty chain and cannot be trusted. :::warning -If the callbacks middleware wraps the transfer application, we strongly discourage the usage of source callbacks if [`MsgTransfer` includes forwarding information](https://github.com/cosmos/ibc-go/blob/v9.0.0-rc.0/proto/ibc/applications/transfer/v1/tx.proto#L54-L55) (which is only supported from ICS20 v2). Source callback information will be executed on the last hop before the destination chain, not on the sending chain. The explanation for this behaviour is that, if the tokens are routed through intermediary chains, then the transfer application on the sending chain will construct a packet data where the [`memo` field](https://github.com/cosmos/ibc-go/blob/v9.0.0-rc.0/proto/ibc/applications/transfer/v2/packet.proto#L38) is empty, and any [memo string](https://github.com/cosmos/ibc-go/blob/v9.0.0-rc.0/proto/ibc/applications/transfer/v1/tx.proto#L51) included in `MsgTransfer` is placed in the [`destination_memo` field](https://github.com/cosmos/ibc-go/blob/v9.0.0-rc.0/proto/ibc/applications/transfer/v2/packet.proto#L48). This makes it impossible to trigger the source callbacks on the sending chain, since the memo string is not available in the `memo` field. Then, on the chain before the final destination chain, the transfer application will construct the packet data with the memo string back in the `memo` field, so that it can be consumed by the callbacks middleware on the destination chain. However, if the `memo` field of `FungibleTokenPacketDataV2` is not empty on the chain before the final destination and the transfer application on that chain is wrapped by callbacks middleware, then the source callbacks would be triggered. Therefore, in order to prevent this unexpected behaviour (i.e. source callbacks triggered not on sending chain, but on the intermediary chain before the final destination) we are strongly recommeding to not include source callbacks information in the `memo` field of `MsgTransfer`. +If the callbacks middleware wraps the transfer application, we strongly discourage the usage of source callbacks if [`MsgTransfer` includes forwarding information](https://github.com/cosmos/ibc-go/blob/v9.0.0-rc.0/proto/ibc/applications/transfer/v1/tx.proto#L54-L55) (which is only supported from ICS20 v2). Source callback information will be executed on the last hop before the destination chain, not on the sending chain. The explanation for this behaviour is that, if the tokens are routed through intermediary chains, then the transfer application on the sending chain will construct a packet data where the [`memo` field](https://github.com/cosmos/ibc-go/blob/v9.0.0-rc.0/proto/ibc/applications/transfer/v2/packet.proto#L38) is empty, and any [memo string](https://github.com/cosmos/ibc-go/blob/v9.0.0-rc.0/proto/ibc/applications/transfer/v1/tx.proto#L51) included in `MsgTransfer` is placed in the [`destination_memo` field](https://github.com/cosmos/ibc-go/blob/v9.0.0-rc.0/proto/ibc/applications/transfer/v2/packet.proto#L48). This makes it impossible to trigger the source callbacks on the sending chain, since the memo string is not available in the `memo` field. Then, on the chain before the final destination chain, the transfer application will construct the packet data with the memo string back in the `memo` field, so that it can be consumed by the callbacks middleware on the destination chain. However, if the `memo` field of `FungibleTokenPacketDataV2` is not empty on the chain before the final destination and the transfer application on that chain is wrapped by callbacks middleware, then the source callbacks would be triggered. Therefore, in order to prevent this unexpected behaviour (i.e. source callbacks triggered not on sending chain, but on the intermediary chain before the final destination) we are strongly recommending to not include source callbacks information in the `memo` field of `MsgTransfer`. :::