Two mainnet chains (bitbadges and cosmos) using 'cosmos' as their bech32_prefix key value

[rayraspberry]

Because bitbadges chain.json uses 'cosmos' for its bech32_prefix and because B is antecedent to C in the alphabet, tools like chain-registry have started returning BitBadges chain information for the prefix cosmos rather than the Cosmos Hub chain data.

I don't know what the policy or terms are regarding this type of situation with regards to managing the content of the registry.

https://github.com/cosmos/chain-registry/blob/master/bitbadges/chain.json
https://github.com/cosmos/chain-registry/blob/master/cosmoshub/chain.json

[JeremyParish69]

Could you please be more specific which tool you're referring to?

[rayraspberry]

Specifically the tool I was referring to was a tool I'd written.

However, I can now confirm that the duplicate bech32_prefix values of 'cosmos' has at broken least one large live in-production app in Cosmos.

Without unique bech32_prefix fields for chains there is no reliable way to resolve the origin chain for any address without a secondary mechanism setting a preference as to which network to select.

The issue is more prominent here because BitBadges is antecedent to Cosmos Hub in the Alphabet.

[JeremyParish69]

The prefix was changed about a week ago, so an app break feels to me like a shortcoming in the app's functionality.

There also still exists a case of bech32 prefix being re-used among mainnets, (Terra Classic vs Terra 2.0), and many are re-used across mainnet to testnet counterparts. So for the time being I thin it would be difficult to justify and implement a requirement for unique bech32_prefixes.

This same discussion has occurred simultaneously in the TG chat.

[rayraspberry]

Agreed on Terra, but I think it's the outlier on this issue and not specific to the issue, but your point helps to clarify the two issues:

1] multiple mainnet type live status chains sharing the same address prefix

It's an issue because multiple chains sharing the bech32_prefix inhibits the ability of using chain-registry to determine the chain to address or contract affiliation using chain-registry alone. I believe that will lead to devaluing the chain-registry utility itself.

The context around Terra was that sharing a prefix was done for expediency in the migration process to ease the emergency transition and because the existing chain was created by the same organization and had continuity in branding, community, and, I'm sure, other factors. Having been through that experience personally, it did provide some ease with the addresses being the same on both chains, but it did create some confusion with contracts as those addresses are not the same on both chains.

It could be argued as you pointed out that you can't tell mainnet vs testnet, but for simplification of argument, let's assume we're talking about mainnets, and with the registry you can pull only mainnets and live status chains.

2] With the specific issue being raised here the entities now sharing a prefix have no formal relationship as far as I'm aware, with no consent or approval (not saying it was required) from the existing prefix user, Cosmos Hub. In the case of Terra, the same entity created both Terra and Terra classic chains. Maybe if the chain was part of ICS or in the AEZ, but it's not.

I think there's an argument to be made that any impact regarding the Terra prefix overlap was the parties (same party) were consenting and it could be argued that they are responsible for any issues may arise.

This is setting the precedent to allow for additional unaffiliated chains to duplicate the prefix of an existing chain. I can understand that a unified address across multiple chains could benefit the user experience, but it could also harm the user and developer experience. Allowing duplicate bech32_prefixes creates additional trade-offs in the user and developer experience. While it is technical possibly, I am not convinced it's practically beneficial.

For clarity, my recommendation would not to allow unaffiliated parties to create registry entries using the bech32_prefix of an existing chain.