cosmos / chain-registry

Creative Commons Attribution 4.0 International
513 stars 1.23k forks source link

Modifications to the repository struct #246

Open CmpHDL opened 2 years ago

CmpHDL commented 2 years ago

Addresses issue #126

We need general normalization for common applications that use chain and asset information. On top of this normalization, some fields and configuration requirements should be present, either with a Github Actions Linter or another form of integrated UnitTests. General requirements are loosely defined below, however, will be more explicitly defined within another ticket. Because one depends on another, it will have to follow some decision making on this issue.

Here is the keplr definition of a currency, one of the most widely used cosmos wallets.

export interface Currency {
  readonly coinDenom: string;
  readonly coinMinimalDenom: string;
  readonly coinDecimals: number;
  /**
   * This is used to fetch asset's fiat value from coingecko.
   * You can get id from https://api.coingecko.com/api/v3/coins/list.
   */
  readonly coinGeckoId?: string;
  readonly coinImageUrl?: string;
}

Currently, we classify each "Currency" as assets within our assetlist.json for each chain folder. There are 3 places where Currency is required and chains will want to correctly configure accordingly, this information is currently lacking.

currencies: <Currency[]>[],
feeCurrencies: <Currency[]>[],
stakeCurrency: <Currency>{},

On each chain.json we should have assets that represent these functionalities to allow for wallet configuration from chain information alone.

Oddly enough, there are multiple ways to go about this that both make sense for different reasons. Lets designate these as option A and option B so as not to confuse with #126


Option A

With current convention we have it as

ChainFolder
    > assetlist.json
    > chain.json

We could modify this to be along the lines of the following to maintain current convention.

ChainFolder
    > assetlist.json
    > stakingAsset.json
    > feeAssetlist.json

Option B

We can also attach this metadata directly to the chain.json, making it easier in general to parse this information. Adding "assets" type <Asset[]> Adding "feeAssets" type <Asset[]> Adding "stakeAsset" type <Asset>

Although I am a larger fan of this approach it would add a "redundancy" as assets would be in both assetlist.json and within an array on the chain.json. I believe there are some philosophical reasons behind having assetlist separated out, however, I think we should also include the array on the chain.json as well for continuity reasons. If not, "assets" can be left off the chain.json and Keplr requirements would still be met.


Gas Price Steps

Additional to these fields, we also need the gas price information for a given chain; defined in low, average, and high steps.

gasPriceStep: {
    low: 0.01,
    average: 0.025,
    high: 0.04,
},

This allows chain creators to specify the increments their chain use for gas fees, we can have a default recommendation in place for chains that are new, unsure, or don't wish to directly configure this.

JeremyParish69 commented 2 years ago

we now allow for gasPriceStep in chain.json under the feeAssets object.

staking assets will soon be added to chain.json in PR #435 Edit: staking assets have been added by now