RFC: ICS20 Metadata

[AdityaSripal]

There have been requests from multiple teams at this point for an in-protocol communication of fungible token metadata. This could be the transfer of information like decimal place, abbreviations, aliases, or logos. After the launch of IBC, this was difficult to add since there was no backwards compatible way of introducing a new packet type to existing channels. However with the introduction of channel upgradability, we can implement a metadata packet that can be optionally adopted by chains without forcing a network-wide upgrade.

This proposal will also be relevant for NFT transfer, since there is a discussion happening there on how best to propagate changes to NFT metadata. See discussion here: #615 (comment)

In both cases, it is theoretically possible for off-chain users to retrieve metadata from the source chain. However, existing infrastructure and UX expects this information to live on the same chain as the asset.

Given the pain points from IBC frontends on the inaccessibility of metadata (currently for ICS20 and in the future for ICS721) and the reduced cost of deploying this with the introduction of channel upgradability. It will be good to understand exactly what metadata is desirable for users of ICS-20 and provide a specification for how to propagate metadata both as a one-time packet when a new asset travels through a channel and as an update if the metadata changes at the source.

From what I have already gathered from users, the following fields would be helpful:

DecimalPlace: uint64

Logo: string

// specifically requested by Osmosis. This would be the in-state denom that the previous chain in the transfer path
// used for the token.
PreviousChainDenom: string

I would like to understand if there is any other metadata that would be important for chains/frontends to have in-state on destination chains.

cc: @alexanderbez @okwme @charleenfei @jackzampolin @sunnya97 @ValarDragon @michaelfig

Ref:
cosmos/ibc-go#366
https://github.com/cosmos/ibc/blob/master/spec/core/ics-004-channel-and-packet-semantics/UPGRADES.md

[AdityaSripal]

Sorry I forgot that this discussion already existed: #607

As discussed earlier, now that channel upgradability is going to be worked on this becomes a viable feature that we can reopen for discussion. Further rationale and suggested metadata is provided in the linked discussion.

[michaelfig]

Quoting from #607:

It is a general problem that user interfaces for a chain need to at least understand some metadata (number of decimal places, preferred name, symbol, etc). These concerns are addressed on Cosmos by the coin metadata ADR, and on Agoric by our ERTP brand displayInfo.

I think it would be desirable for ICS-20 to be extended by a subprotocol that can convey this information over the transfer protocol. Attaching the metadata to transferred tokens is a sane default, just like ICS-20 already uses a single piece of metadata: the denomination. The issue of trusting the metadata is separate, but it is easier to say "attach the conveyed metadata to the token, and decide later if you value the token in the same way" rather than "default to no metadata, and require governance or a registry to install an ex nihilo idea of what the metadata should be".

I think chain token metadata interop would greatly improve the ergonomics for new tokens transferred to a given chain. Because we lack this interop, the Agoric chain essentially needs a governance action for the first of what should be a permissionless token transfer. This is because Agoric's token metadata is deeply wired into the chain, and every asset transfer conveys it. In fact, the number of decimal places is considered even more fundamental in Agoric than the denomination name; we use "petnames" for asset types assigned by the user rather than a centrally-controlled name.

I hope to discuss this in a future IBC meeting, @AdityaSripal. Also tagging @JimLarson, @dtribble, @warner on the Agoric side.

[michaelfig]

From @hxrts:

Also relevant to the following efforts:

• https://github.com/osmosis-labs/assetlists
• https://github.com/cosmos/registry + Add chain info from external sources registry#25
• And eventually https://github.com/tendermint/cns

[ethanfrey]

Great initiative.

And a point for all future protocols, that they should not just have one packet type, but some sort of enum / union type that can be more easily extended.

I don't have much time to dig in, but would love to see info like DecimalPlaces. Also, user-visible name, like on the normal bank metadata (uatom, 6 decimal places, ATOM) - these 3 pieces would help with wallets a lot

I haven't seen logo used on-chain except for cw20 so I wonder if this would be used much or a possible attack vector with urls.