You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/docs/02-apps/01-transfer/10-IBCv2-transfer.md
+24Lines changed: 24 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -63,3 +63,27 @@ Because IBC v2 no longer uses channels, it is no longer possible to rely on a fi
63
63
## Changes to the application module interface
64
64
65
65
Instead of implementing token transfer for `port.IBCModule`, IBC v2 uses the new application interface `api.IBCModule`. More information on the interface differences can be found in the [application section](../../01-ibc/03-apps/00-ibcv2apps.md).
66
+
67
+
## MsgTransfer Entrypoint
68
+
69
+
The `MsgTransfer` entrypoint has been retained in order to retain support for the common entrypoint integrated in most existing frontends.
70
+
71
+
If `MsgTransfer` is used with a clientID as the `msg.SourceChannel` then the handler will automatically use the IBC v2 protocol. It will internally call the `MsgSendPacket` endpoint so that the execution flow is the same in the state machine for all IBC v2 packets while still presenting the same endpoint for users.
72
+
73
+
Of course, we want to still retain support for sending v2 packets on existing channels. The denominations of tokens once they leave the origin chain are prefixed by the port and channel ID in IBC v1. Moreover, the transfer escrow accounts holding the original tokens are generated from the channel IDs. Thus, if we wish to interact these remote tokens using IBC v2, we must still use the v1 channel identifiers that they were originally sent with.
74
+
75
+
Thus, `MsgTransfer` has an additional `UseAliasing` boolean field to indicate that we wish to use IBC v2 protocol while still using the old v1 channel identifiers. This enables users to interact with the same tokens, DEX pools, and cross-chain DEFI protocols using the same denominations that they had previously with the IBC v2 protocol. To use the `MsgTransfer` with aliasing we can submit the message like so:
76
+
77
+
```go
78
+
MsgTransfer{
79
+
SourcePort: "transfer",
80
+
SourceChannel: "channel-4", //note: we are using an existing v1 channel identiifer
81
+
Token: "uatom",
82
+
Sender: {senderAddr},
83
+
Receiver: {receiverAddr},
84
+
TimeoutHeight: ZeroHeight, // note: IBC v2 does not use timeout height
85
+
TimeoutTimestamp: 100_000_000,
86
+
Memo: "",
87
+
UseAliasing: true, // set aliasing to true so the handler uses IBC v2 instead of IBC v1
0 commit comments