Fix send_transfer
#2
Conversation
…lafer/send_transfer_fix
| // This applies to all other tokens created on this | ||
| // sovereign SDK chain. The token name is not guaranteed to | ||
| // be unique, and hence we must use the token address (which | ||
| // is guaranteed to be unique) as the ICS-20 denom to ensure |
There was a problem hiding this comment.
I am seeing, when transferring tokens between two Sovereign chains, we exclusively use the token address as the denom, disregarding the token's name.
Whether the token lives on the source chain, in which case the denom is based on the token address, or if the IBC mints the token on the source chain (which represents a token on the destination chain). In latter, we use a prefixed denom, where the base denom comes from a MsgRecvPacket, which was earlier crafted by relayers based on an emitted TransferEvent from the destination chain...Where the denom is also set as the token address!
There was a problem hiding this comment.
when transferring tokens between two Sovereign chains
In the initial version, we will only support sending tokens to Tendermint-based chains, as we will only have a tendermint light client installed.
In latter, we use a prefixed denom, where the base denom comes from a MsgRecvPacket, which was earlier crafted by relayers based on an emitted TransferEvent from the destination chain...Where the denom is also set as the token address!
However, if we were to support Sovereign <-> Sovereign transfers, then the denom of tokens we receive would indeed represent the address of the token on the other chain. Note that the token we mint on our side would have a different address, but its denom would be set to the string representation of the address of the token on the other chain. However, for received tokens, we treat the token name as a black box; we never try to interpret it in any way.
There was a problem hiding this comment.
the denom of tokens we receive would indeed represent the address of the token on the other chain
Exactly. And looks like it holds true for bunch of other non-Cosmos chains, which makes string reps of token addresses the most common denom.
By the way, the transfer module stores the "denom → token_address" in the minted_token field. This allows us to map, e.g. the channel-1/port-1/0xb79…4f5ea received from MsgRecvPacket to the corresponding token address on the source chain. So, I'm still a bit puzzled about why can't we work with the MsgTransfer and include the string reps of the token's address as denom? What required us to define SDKTokenTransfer on top of that?
Anyway, as chatted earlier, Let's dive deeper into these details when writing tests.
This PR fixes
send_transfer()to ensure that ICS-20 token denoms are always unique.