osmosis-labs / assetlists Goto Github PK
View Code? Open in Web Editor NEWLicense: Apache License 2.0
License: Apache License 2.0
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
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
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
osmo1e3dcl9jk2wclslyk93ak8726mhwdhps8fhvfwg
Faucet
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
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?
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.
We should make a CI job that checks correctness of all the IBC hashes.
Basically doing automatically what Jeremy did here: #266 (comment)
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?
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)
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.
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:
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.
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.
@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.
i.e. USDC.axl instead of axlUSDC
$baddog was taken off front end about an hour ago, right when $bad was added. Concerning need response. thank you.
Please, take a look at this closely:
ethereum-lists/chains#1216
ethereum-lists/chains#1216 (comment)
https://twitter.com/mr_ligi/status/1532866855257399296
Sample structure : https://github.com/cosmos/chain-registry/blob/master/terra/assetlist.json#L69 :
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.