Return hashed denom with denom-traces query

[okwme]

Summary

It's great to get a list of the human readable IBC denoms with gaiad q ibc-transfer denom-traces. However it's difficult to correlate them with the results of gaiad q bank total. There's a path for resolving a single hashed denom using gaiad q ibc-transfer denom-trace <denom> but would be tedious to do for each one. Otherwise it's difficult to tell how many tokens exist for each IBC denom. I'd like to know how many uatoms exist on the hub that have multiple hops.

- base_denom: uatom
  path: transfer/channel-141/transfer/channel-2/transfer/channel-12
- base_denom: uatom
  path: transfer/channel-141/transfer/channel-5/transfer/channel-9/transfer/channel-141/transfer/channel-5/transfer/channel-9
- base_denom: uatom
  path: transfer/channel-141/transfer/channel-6/transfer/channel-0
- base_denom: uatom
  path: transfer/channel-141/transfer/channel-95/transfer/channel-4

These are all atoms on the hub that are non longer fungible with native atoms because they need to be unwould back through the osmosis chain (channel-141).

Alternatively, it would be great to be able to query the number of tokens locked up in each channel to get some ideas of use of channels

or maybe there's already another method to do this?

Problem Definition

Proposal

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged/assigned

[crodriguezvega]

So should we add an extra field that would look like this?

- base_denom: uatom
  path: transfer/channel-141/transfer/channel-2/transfer/channel-12
  ibc_denom: ibc/2154552F1CE0EF16FAC73B41A837A7D91DD9D2B6E193B53BE5C15AB78E1CFF40

[okwme]

this would certainly be an improvement as it removes one of the steps to finding out how many tokens have been transferred between chains. However there would still be quite cumbersome:

 for row in $(gaiad q ibc-transfer denom-traces | jq -r '. ibc_denom[] | select(.base_denom=="uosmo") | .path'); do
  gaiad q bank total --output json | jq '.supply[] | select(.denom=="$row")'
done

I'm unsure of the engineering lift or drawbacks of including a bank query for the total of each denom returned but that would be the ideal result. Although having the denom hash would definitely make it easier to make that query manually.

The times that I needed to query the balance of a channel were:

• removing the liquidity module from the cosmos hub requires users to remove tokens from liquidity pools. Removing those tokens means burning the corresponding LP tokens that represent those positions. This could be forced upon the user unless the LP tokens were moved off chain via IBC. We needed to check to see how many LP tokens had actually been transferred out.
• when Terra was going down we wanted to see how much UST or Luna was actually on the hub, to asses the need to manually closing the terra IBC channel. This was very difficult to do under current circumstances.
• when collecting data about which chain uses the hub the most it was difficult to asses based on the number of tokens transferred

i realize that the base_denom is also not a safe target for collecting this info. Maybe thinking about it from fundamentals there might be a client query that lists how many channels and ports are associated with it as well as the number of tokens that have been moved out through it as well as in through it with some reference to the paths they took to suggest they came from common origins. Services like mintscan are beginning to provide these kinds of insights but when the exact data you're looking for isn't supported there is no recourse.

[crodriguezvega]

Thanks for your comment, @okwme. So I think for now the simplest solution would be to include the ibc_denom field in the denom_traces query. Then you can see which IBC denoms have uatom as base denom and with the result of the gaiad q bank total you can add up the supply for all of those denoms to calculate the total supply for uatom.

I realize that you will still need to do some scripting to get the value that you're after, but let's see how it goes with this solution and maybe in the future implement something more sophisticated. We see that there are now a couple of use cases that intersect IBC and SDK's x/bank module (like this other issue). So maybe this is something to discuss with SDK team.

[crodriguezvega]

Closing the issue on the basis of being stale. We haven't received any other requests to return the IBC denom in the denom traces query (which has now been replaced with the denoms request anyway).