osmosis-labs / assetlists Goto Github PK

This repo has a custom modified version of the Chain Registry's assetlist JSON schema. Over time they may grow out increasingly of sync and the Chain Registry might change in some way that breaks this repo. In addition, this repo might potentially accumulate bad data while the Chain Registry continues to improve and adapt to the changing Cosmos landscape. It is therefore in our interest to try to keep this repo's assetlist schema reasonably synchronized with the Chain Registry's.

Because there are custom modifications to this repo's assetlist schema, we cannot simply utilize overly simple automation to can the schemas exactly identical.

One suggestion I have is to separate this repo's custom data into another file, as this would allow us to switch to an assetlist schema that exactly matches to Chain Registry's, and it then it becomes very simple to keep the schema up to date using automation.

We can fairly easily make sure to account for all the custom data in a separate file. Some properties that immediately come to mind are: internal keywords (to keep track of which Osmosis views on which each asset appears), pools (e.g., OSMO pool, ATOM pool, USDC.axl pool) (to keep track to which pool ids are the 'primary' for each asset), and override data (e.g., symbol: "USDC.axl"--because Axelar opts for 'axlUSDC', or token logo images including a particular trace marker--like a little axelar icon at the bottom right of WETH)

Example:

"assets": [
  {
    "chain_name": "cosmoshub",
    "base": "uatom",
    "pools": {
      "OSMO": 1
    },
    "osmosis-main": true,
    "osmosis-frontier": true,
    "osmosis-info": true
  },
  ....
  {
    "chain_name": "axelar",
    "base": "uusdc",
    "pools": {
      "OSMO": 678
    },
    "osmosis-main": true,
    "osmosis-frontier": true,
    "osmosis-info": true,
    "override_properties": {
      "symbol": "USDC.axl"
      "logo_URIs": {
        "svg": "https://raw.github.com/chain-registry/main/axelar/images/axlusdc.svg"
      }
    }
  }
  ""
]

with this list also used to maintain view default ordering (i.e., the order in which assets appear on Osmosis Zone), we can have the assetlist file completely generated. It also gets us closer to letting the Osmosis Frontend pull its list of assets directly from this repo, rather than needing manual input of each asset (and chain) there as well.

I could imagine this file eventually being the only file needing manual change to enlist a token onto Osmosis (assuming they have already registered it to the Chain Registry). All other files, including those in Osmosis Frontend repo, would be automatically generated.

TGD token has "display": "tgrade", but in denom_units there is only "utgd" and "tgd".
As written in the scheme, "display" name must be in "denom_units"
in PR #207

Pool 1470

-No APR showing (API returns 0 as value)

@JeremyParish69 @sunnya97

Problem

There are an increasing number of assets on Osmosis (we're preparing for this to further explode in the future). Some of them are related; frequently within the same project. (Terra, Juno)

Solution

Adding synonyms would allow people adding assets to specify arbitrary keywords that would help users identify their project.

Once we migrate to assetslist repo, we could pull these terms into our filter/search engine on the frontend. Users could almost "google" for certain assets on the frontend and they'd appear.

Example: for the Terra network, they have a few associated stable coins on Osmosis as well as their native LUNA token. For the stable coins, we could add Terra and LUNA as synonyms so that when a user searches "Terra" or "LUNA" their stablecoins would magically appear as well.

Task

• Update existing assets to include synonym keywords (consider consulting each asset's project's stakeholders)

Please, take a look at this closely:
ethereum-lists/chains#1216
ethereum-lists/chains#1216 (comment)
https://twitter.com/mr_ligi/status/1532866855257399296

i.e. USDC.axl instead of axlUSDC

Make a sequence diagram To have a clear idea of the process, it is important that we have an idea of the generation of the different asset lists, with the different integration on chain-registry & if possible the mention of the CI/CD pipelines

We should make a CI job that checks correctness of all the IBC hashes.

Basically doing automatically what Jeremy did here: #266 (comment)

A few assets were verified in our frontend but not on the assetlist, and then got unverified once osmosis-labs/osmosis-frontend#2368 was merged.

We should reverify them. Some off the top of my head

• BUSD
• LUNC
• RAW
• BOOT
• DARC
• HASH
• LUNA
• CRE
• CUDOS
• DORA

Howdy, y'all. I'm looking to update and further automate the Assetlists repo.

I want to create a small, simple file (exemplified below) in the assetlists repo, and have it be the only file needing to be touched to add a token to the assetlists repo (after having registered the chain and asset):

If would list all the listed assets, ordered as seen on Osmosis Zone, and only contain:

• minimal asset specification (just base denom and chain name),
• pool ids,
• osmosis-specific keywords, and
• override data, where applicable (rare).

The current assetlist.json file we have now would still exist roughly as is, but no longer be manually modified; it would instead be auto-generated (using the data from this proposed new file and the Chain Registry) whenever an asset is listed or modified.

The generated assetlist.json file will eventually be able to automatically feed into the Osmosis frontend, thus drastically simplifying the manual aspects of listing a token.

"assets": [
  {
    "chain_name": "osmosis",
    "base": "uosmo",
    "pools": {
      "ATOM": 1,
      "USDC.axl": 678
    },
    "osmosis-main": true,
    "osmosis-frontier": true,
    "osmosis-info": true
  },
  {
    "chain_name": "osmosis",
    "base": "uion",
    "pools": {
      "OSMO": 2
    },
    "osmosis-main": true,
    "osmosis-frontier": true,
    "osmosis-info": true
  },
  {
    "chain_name": "axelar",
    "base": "uusdc",
    "pools": {
      "OSMO": 678
    },
    "osmosis-main": true,
    "osmosis-frontier": true,
    "osmosis-info": true,
    "override_properties": {
      "symbol": "USDC.axl"
      "logo_URIs": {
        "svg": "https://raw.github.com/chain-registry/main/axelar/images/axlusdc.svg"
      }
    }
  },
...
  {
    "chain_name": "cosmoshub",
    "base": "uatom",
    "pools": {
      "OSMO": 1
    },
    "osmosis-main": true,
    "osmosis-frontier": true,
    "osmosis-info": true
  },
  ....

]

Thoughts? Objections? Would greatly appreciate feedback.

@dogemos for IBC you labeled it "osmo-channel"

"source-channel": "channel-35",
"osmo-channel": "channel-1"

I think we should label it something else ("destination-channel"?). This standard will probably end up being used for more than Osmosis.

$baddog was taken off front end about an hour ago, right when $bad was added. Concerning need response. thank you.

MKR token logo broken--looks like a yellow circle with a '?' question mark.

Is there a script that can create go types for the asset list schema from the json? Or if there's already generated types in one of the osmosis go library which I can use?

I envision this repo acting as a one-stop-shop for token additions, and including some data about chains could help teams validate their chain registry additions, and help the Osmosis Frontend update its token and chain data.

Combining the assets defined in this repo with the Chain data in the Chain Registry, we could effectively pre-compose the chainInfos data needed on the Osmosis Frontend. I could see it looking somewhat like this file: https://github.com/osmosis-labs/osmosis-frontend/blob/master/packages/web/config/chain-infos.ts , hoping to replace it completely and automate the synchronization of their copy from this repo's copy.

All the data can be derived pulling from the Chain Registry and from this repo's assetlist file, with the exception of some of the endpoints (e.g., from Chainapsis) which are not public to the Chain Registry, but used for the Osmosis Frontend. I could think of a few ways to handle.

Of course, this may be too out of scope for this repo--in which case, please inform me Just think it would make for a nice one-stop-shop for adding (and verifying) token additions without needing to visit the frontend repo. It would take a lot of work away from the Osmosis Frontend repo and drastically simplify the token listing process for various cosmos project teams.

osmo1e3dcl9jk2wclslyk93ak8726mhwdhps8fhvfwg
Faucet

Now that there are chain-specific assetlists in github.com/cosmos/chain-registry, should we move all the image assets there, and update the links in our Osmosis assetlist to point to the files in the chain-registry?

@IbrarMakaveli thoughts?

Sample structure : https://github.com/cosmos/chain-registry/blob/master/terra/assetlist.json#L69 :

• Should we keep "cw20:" at beginning of "denom" and "base" ?
• Change "port" value ("transfer") for IBC it's different for CW20 token
• Should we keep "kind" key or should be optional, or maybe not needed if "cw20:" at beginning of "denom" and "base" ?

@sunnya97 @ValarDragon @dogemos

PR: #120

Current incorrect:
https://api.coingecko.com/api/v3/coins/konstellation

As per Coingecko API, it should be changed to "darcmatter-coin":
https://api.coingecko.com/api/v3/coins/darcmatter-coin