Coin metadata

[sunnya97]

Bank module should have a store that keeps metadata about different denoms.
Examples:

• decimals per denom
• is allowed to transfer through IBC
• max total supply (?)

[fedekunze]

Interesting proposal @sunnya97. Should we also add the origin zone where the coins get minted ?

[sunnya97]

Yeah, maybe we can put the the IBC transfer path prefixing (#842) as a metadata property, so the token name doesn't have to grow super large.

[rigelrozanski]

Based on a previous discussion, we decided this was postlaunch, as we already keep track of the total supply for atoms in staking - which is the only total supply we'll need to know at launch

[fedekunze]

blocked by #3972

[jackzampolin]

Good pick up @fedekunze

[fedekunze]

As @sunnya97 explained to me the other day, #4255 doesn't address this issue. This will have to be spec'ed out prior to implementation

[fedekunze]

I think this metadata also could apply to NFTs (cc: @okwme @marbar3778). Maybe it makes sense to have an Asset interface which NFT and coins also comply with

[okwme]

I'd be really into a separation of asset and metadata. I think the fungible and non-fungible token should do only what they're meant to do: represent an asset with denomination (+origin chain) and amount (ID in the case of NFTs). The metadata should be linked to the generalized asset type of fungible or non-fungible token and should be able to have as much or as little depth as needed.

I'm kind of into the schema.org way of nested categorization:
https://schema.org/docs/full.html

Assets could use this format as well as some way of describing which aspects of this format they satisfy. There could also be a protocol for expanding the schema with versions that various projects could keep in sync with.

For games:
https://schema.org/VideoGame
General assets NFT or otherwise:
https://schema.org/TypeAndQuantityNode
Currency:
https://schema.org/currency (maybe needs to be extended)

As a standard used outside of our specific context with an organization dedicated to it it might be good as a common denominator between all sorts of assets which require metadata

https://github.com/schemaorg/schemaorg

[jackzampolin]

This needs an ADR. IBC also needs some thinking about white/black listing denoms.

[fedekunze]

We need to reprioritize this because it can provide a better UX for IBC users. @sunnya97 can you write an ADR by the end of this week?

[cwgoes]

What was the idea behind "is allowed to transfer over IBC"? Is that a sort of whitelist?

Ref cosmos/gaia#269.

[fedekunze]

What was the idea behind "is allowed to transfer over IBC"? Is that a sort of whitelist?

I think it means that tokens cannot be transferred out from their source chain. Maybe some private chains would like to keep their tokens within their domain.

[cwgoes]

What was the idea behind "is allowed to transfer over IBC"? Is that a sort of whitelist?

I think it means that tokens cannot be transferred out from their source chain. Maybe some private chains would like to keep their tokens within their domain.

As in, prevent users from transferring their tokens? Seems a bit authoritarian to me.

[fedekunze]

Seems a bit authoritarian to me.

That's exactly the use case lol. Think of it as a SendEnabled param from bank

[cwgoes]

Seems a bit authoritarian to me.

That's exactly the use case lol. Think of it as a SendEnabled param from bank

Hmm, OK. I would personally vote against such an authoritarian option but it is technically possible!

[alexanderbez]

We certainly need this. Moving this alongside the ADR issue to v0.39 release.