-
Notifications
You must be signed in to change notification settings - Fork 28
IBC: ChannelID and Denom Relationship
A few pages are related to this issue.
- IBC Channel Detail Page, Messages section
- Transactions List Page
- Account Detail Page, Transactions section
For Messages on a specific IBC Channel, api/v1/ibc/channels/<channel-id>/messages
The full message parsed by indexing server is under response.result[0].message
.
Warning!
For this API, you might find three denoms unber each result
entry.
-
response.result[0].denom
: Not recommend, could be inibc/xxx
format. Will fix it soon. -
response.result[0].message.params.token.denom
: Not recommend, could be inibc/xxx
format. -
response.result[0].message.params.packetData.denom
: USE THIS! Always in[<port-id>/<channel-id>/]<original-denom>
format.
For Transactions list, api/v1/transactions
The full message parsed by indexing server is under response.result[0].messages[X].content
.
For Account transaction list: api/v1/accounts/<account>/transactions
The full message parsed by indexing server is under response.result[0].messages[X].content
.
The most important information for a message, is under the params
key for each full message.
In the following sections, I will list the denom
formats in different messages' params
key.
More examples on IBC full message is available to download here: https://github.com/crypto-com/chain-indexing/issues/645#issuecomment-993101357.
Two denom
s available under params
.
-
params.token.denom
:<original-denom>
-
params.packetData.denom
(Recommend):<original-denom>
-
params.token.denom
:ibc/XXXX
-
params.packetData.denom
(Recommend):<source-port>/<source-channel>/<original-denom>
- It is using
port
andchannel
on this chain.
Two denom
s available under params
.
-
params.maybeMsgTransfer.denom
:<counterparty-original-denom>
-
params.maybeMsgTransfer.maybeDenominationTrace.denom
:-
ibc/XXXX
=ibc/
+sha256(<destination-port>/<destination-channel>/<counterparty-original-denom>)
- It is using
port
andchannel
on this chain.
-
-
params.maybeMsgTransfer.denom
:<source-port>/<source-channel>/<original-denom>
- It is using
port
andchannel
on counterparty chain.
-
params.maybeMsgTransfer.denom
:<original-denom>
-
params.maybeMsgTransfer.denom
:<source-port>/<source-channel>/<original-denom>
- It is using
port
andchannel
on this chain.
-
params.maybeTransfer.refundDenom
:<orignal-denom>
-
params.maybeTransfer.refundDenom
:<source-port>/<source-channel>/<original-denom>
- It is using
port
andchannel
on this chain.
MsgTimeout
on Explorer example: https://crypto.org/explorer/tx/DBE9B18CD42387C09AA52242F01CBD0003B95292E5BA015187FCCDAE637DFFBD
Its corresponding MsgTransfer
on Explorer: https://crypto.org/explorer/tx/005E3859616C307A105F3C30A2C6AA33D99AE918769BDF6F8BB1CABC24A9CEC8
I can't find any real example for this. But we could just apply the same logic as MsgTimeout
.
For display the above mentioned IBC messages, I suggest to bypass the ibc/xxx
denom format and to only use the denom in [<port-id>/<channel-id>/]<original-denom>
format.
As every message contains a denom that are in [<port-id>/<channel-id>/]<original-denom>
format, which is more user friendly.
However, for account balance, the API response could still have ibc/xxx
format denom. As it is from Cosmos RPC and not controlled by our indexing server.