Make Keplr Suggest Chain derivable from Registration

[JeremyParish69]

Keplr wallet, being a leadier wallet among the comsos, it makes sense to keep in mind how the Cosmos Chain Registry can cooperate with the Wallet's API. As per Keplr's Suggest Chain documentation, we need many input parameters in order to properly and completely add a chain to a user's Keplr walllet if not already added as a default chain (most aren't). Currently, many dapp frontends have to have hardcoded every chain's corresponding values to work with the Keplr API. It would be nice to have all the required data be registered to the Cosmos Chain registry so that each dapp doesn't have to individually maintain their own copy--simply update the chain registry which updates for all dapps.

Although much of the information is already added to the chain registry, there is much info that isn't. Here is what the ChainInfo interface accepts:

• [x] rpc - many endpoints can already be added to chain.json
• [x] rest - many endpoints can already be added to chain.json
• [x] chainId - already added to chain.json as chain_ID
• [x] stakeCurrency - this could go into chain.json, or be added as a property of the tokens when listed in assetlists.json. If placed in chain.json, really, all we'd need is a coinMinimalDenom/base, and then it could reference to the assetlist.json for further details. (see: Add Staking Metadata to Chain Schema #435)
• [x] bip44.coinType - already added to chain.json as slip44
• [x] bech32Config - bech32 prefix can already be added to chain.json as bech32_prefix, but other forms, such as for public keys and validators cannot yet be specified with the current chain.schema. (for now we can move on, since we've never needed to add more than the basic prefix for suggest chainlist)
• [x] currencies - it is probably safe to assume that all tokens listed in the assetlist.json file are acceptable currencies
• [x] feeCurrencies - we can specify fee tokens in chain.json as fees::fee_tokens::denom, and so could stay in chain.json, or be added as a property of the tokens when listed in assetlists.json. If placed in chain.json, really, all we'd need is a coinMinimalDenom/base, and then it could reference to the assetlist.json for further details.
• [x] gasPriceStep - although we can specify a minimum in chain.json as fees::fee_tokens::fixed_min_gas_price, there isn't much opportunity to specify a range for all fee currencies. Personally, I think we should accommodate for {min, low, avg, high}. We'd also need a new range for each acceptable fee currency. This could go into chain.json, or be added as a property of the tokens when listed in assetlists.json. (see: Add low avg high gas fees to chain schema #436)
• [x] features, incl. { secretwasm , ibc-transfer , cosmwasm , ibc-go , stargate , ibc-transfer , no-legacy-stdTx } - many of these can be derived by knowing other things about the chain.
  • [x] The cosmosSdk version. (e.g., stargate if cosmosSdk v 0.40+, no-legacy-stdTx if cosmos sdk v 0.43+, ibc-go if cosmosSdk v 0.43 ). Since all chains registered to the Cosmos Chain Registry are cosmos chains, they all will use the cosmosSdk, and so it could make sense to add a property such "cosmos_sdk_version" to chain.json. (see: Add Cosmos SDK and Tendermint Versions #418)
  • [x] Another can be determined if we had properties for confirming IBC parameters status; "ibc-transfer" could be determined if there was an object for listing ICS standards have been enabled on the chain. e.g., "ibc-standards": { "ics20", "ics27" } in chain.json could indicate that IBC fungible token transfer and IBC interchain acocunts have been enabled on the chain. such a property voids needing a speciable property just to indicate ibc compability. (see PR: Add chain ibc data #546)
  • [x] Finally, a property for cosmwasm version could help with the cosmwasm feature, as well as being potentially useful for other purposes regarding comswasm development. E.g., "cosmwasm_version:" into chain.json (see Issue: Add cosmwasm to chain.json? #419, see PR: Add cw to chain schema #453)

Personally thinking that, to save from having to make several lists of tokens in chain.json, one for staking, one for fees, one for governance, and more for whatever functions may arise in the future, I think these should probably just be properties under the corresponding tokens in assetlist.json. Imagine a chain where fees are payable by any token on the chain--that'd require essentially repeating the entire assetlist in the chain.json file, and any token additions would require an update to both files, when it could've been done in just one file.

[JeremyParish69]

Perhaps the discussion on IBC properties should be continued on #39

[JeremyParish69]

Discussion for cosmos sdk version can be continued on #40

[JeremyParish69]

Discussion of identifying staking and fee assets (and gas step?) can continue on #126

[JeremyParish69]

Discussion of whether and how to include cosmwasm data can continue on #419

[JeremyParish69]

Should we add ability for WalletUrl and WalletUrlForStaking?

[pyramation]

prototyping this here

module: https://www.npmjs.com/package/@chain-registry/keplr code: https://github.com/cosmology-tech/chain-registry/blob/main/packages/keplr/src/index.ts

[JeremyParish69]

Keplr's suggest chain API feature is now theoretically fully derivable from data that can be stored on the Chain Registry! Next step is to fill in missing data that other dApps already have and bring it over to the Chain Registry.