cosmos / chain-registry Goto Github PK

Need to figure out standard for this

How can we do versioning for the schemas so that we know when there's breaking changes?

https://github.com/ovrclk/cosmos-omnibus

ping.pub's REST API endpoints are listed at their repo publicly.

Would be nice to if we can auto-include them.

This is the latest version supported by VS Code

Hi guys ! I've had a hard time trying to make a request in order to broadcast an Osmosis transaction , i created a transaction object like that :

{
    "chain_id": "osmosis-1",
    "account_number": "164427",
    "sequence": "0",
    "fee": {
        "gas": "80000",
        "amount": [
          {
            "denom": "uosmo",
            "amount": "0"
          }
        ]
    },
    "msgs": [
      {
          "type": "cosmos-sdk/MsgSend",
          "value": {
            "from_address": "from",
            "to_address": "to",
            "amount": [
              {
                "denom": "uosmo",
                "amount": "2000000"
              }
            ]
          }
      }
    ],
    "memo": ""
}

then i generate the tx_64bytes the same i did for cosmo ( using the cosmopy library for python that i adapted for osmo and cosmo) , and then i tried to broadcast the transaction using the APIs here :
https://github.com/cosmos/chain-registry/blob/master/osmosis/chain.json

i've tried all of them and i get the same error message : expected 2 wire type, got 3: tx parse error
here's the complete response object :

{
    "jsonrpc": "2.0",
    "id": -1,
    "result": {
        "code": 2,
        "data": "",
        "log": "expected 2 wire type, got 3: tx parse error",
        "codespace": "sdk",
        "hash": "895B9320CC7FF7960A4E2982F493BD4390174729B4528BAC44CA08AE37C0D10A"
    }
}

and the request : GET / https://rpc-osmosis.keplr.app/broadcast_tx_sync?tx="tx_64bytes"

Does anyone know how to broadcast a transaction using the REST APIs ?? Thank you !!

previously described here: cosmos/cosmos-registrar#20

This would be a github action that is run periodically to check the RPC endpoints to make sure they're online.

If they're offline, they should be removed from the list and a new issue should be opened (or some other way to signify that they are down and should'nt be checked again until manually added again)

@dheerajkd30 Can you add info for the Comdex block explorers please?

As a general usecase, e.g. security advisor notifications, the version field should be split into:
recommended_version and compatible_versions

How important is the chain-registry being kept up to date? If a governance upgrade of a chain is approved, should there be fields in the chain registry for enabling end-user node setup scripts to get the right version at exactly the right time? What about other consumers of the chain-registry, we expect this to expand a lot. E.g. IBC usecases, security notification usecases, etc.

The importance of this depends on how "core" to the emerging cosmos ecosystem the chain registry is intended to become.

There will likely be many ways to handle fees emerging throughout cosmos. We should specify the type of fee pricing accepted as well. E.g. EIP1559 will make it dynamically priced. No need to spec out how to specify EIP1559 fees rn, but we should allow a way to specify new types at least.

if I can dig them up I'll fix it.

Grpc provides functionality to easily create clients that show all possible queries and possible msg types supported by a chain. As the cosmos ecosystem has adopted grpc already it would be best to include it into the chain registry.

Example:

This would help with building tools like lens from Strangelove

cc @sunnya97

Blocked on cosmos/mainnet#159

We should create an ibc.json file in the root directory that contains all the preferred channels, non preferred channels and a trust hash

As a rough idea:

"cosmos": { // should be unique chain identifier
    "trust_hash": "" // some hash
        "osmosis": { // also unique chain identifier
            "preferred_channel": "141-0",
            "non_preferred_channels": [
                "189-23",
                "123-456",
                //etc..
            ]
        },
        "akash": {
            "preferred_channel": "184-17",
            "non_preferred_channels": [
                //etc..
            ]
       }
       // Repeat for each chain that has an IBC connection
// Repeat for each chain

Not sure what's the best way to notate those channels. @sunnya97 @jackzampolin ?

Currently not sure how to automatically populate these, but we need this file and start adding them manually at first.

A list of chains who need more metadata added because they are missing or are only stubs right now.

• Sommelier
• Injective
• IrisNet (is Stub)
• Band Chain
• Switcheo
• Fetch.ai
• Omniflix
• Ryzon
• Odin Network
• Vidulum
• Chihuahua
• Dig Chain
• Konstellation Network

Would be nice to have an endpoint that balances over all the nodes

Looks like they made their source code private.

IPFS link for the binary does not work anymore.

Though, their tendermint RPC and REST API endpoints are live.

After their recent upgrade

If this registry can be used as an npm package, then it can be built into any JS application.

I may add this if this is desireable, currently looking into ways to make it work.

Should there be a field for if the chain supports statesync? And if the chain supports state sync, should the expectation be that all persistent peers provide statesync snapshots?

Right now, fee and/or staking tokens are listed in two places:

1. under fees in chain.json
2. in assetlist.json

However, there's a possibility that some chains use a different token for fees than for staking. Should we make it clear what the native staking token is? And if so, in which file? Assetlist.json mentions it in the description, but we should probably just have a specific field for that. What do y'all think?

I understand the need of JSON. But the chain information are maintained manually.

Probably better if we use YAML (or something similar as TOML) for readability and compile and serve them as JSON.

https://github.com/satoshilabs/slips/blob/master/slip-0173.md

This is more a convenience thing, but it could be good to optionally link a public URL so clients can look that up. Could also go one step further and include a public key + URL/pubkey.txt, so the webmaster can attest that the website is authenticated by on-chain gov.

Negative here is if projects opt to do this they are enshrining an official page that could imply singular control.

While chain-ids can change in the wild, we should consider creating a single alphanumeric chain name that stays the same regardless of any future updates.

Need to create a file that shows the preferred ics20 channels between every pair of chains.

Archive nodes should be added as an item to the chain registry.

Currently the address field for seeds refers to its socket address. The standalone word address here is confusing with on-chain addresses, which is basically what the id is.

We should change address here to ip, socket_address or url.

A suggestion

As you can see, in both blockchains, the basecro denominator is the CRO symbol and the same coingecko_id=crypto-com-chain. Then look at the cro denom exponent, you can see that exponent=18 for cronos and exponent=8 for crypto-org.

Which exponent value is correct or is the mistake somewhere else? Maybe they have different coinecko_id?

Thank you very much!

tendermint_version
sdk_version

Problem

There is currently no way to identify assets used for staking on a given chain.

Solutions

1. Asset.features property

Adjacent to a keplr chain config's features: ["stargate", "ibc-transfer", ... ], property, we could add a features property to assets as such:

features: ["stake", "fee", ... ]

2. Chain.staking property

Along the same lines as Chain.fees, we could add Chain.staking as such:

    "staking": {
        "staking_tokens": [
            {
                "denom": "uosmo",
            }
        ]
    },

Notes

The latter may be more conducive for interchain staking, as it wouldn't make much sense to put IBC tokens in the native asset lists.

chain.json should include a category called ibc with at least the following:

• ibc_go_version
• ibc_enabled (true / false)
• supported_ics

Add a CI script to ensure that there aren't multiple chain.json's with the same chain-id, chain-name, or pretty-name

https://github.com/terra-money/assets/blob/master/cw20/tokens.js

Previously here: cosmos/registry#7

This would be to take the contents of the peernodes section of the JSON and put it into a place that is easy to copy and paste into a config file for node operators.

Alternatively (or in addition) this could be a github action that generated a markdown file like this:
https://github.com/osmosis-labs/networks/blob/main/peers.md
or
https://hackmd.io/@KFEZk8oMTz6vBlwADz0M4A/BkKEUOsZu#

I had move genesis from being an object to being just a url string, but I think it might be good to put it back into an object for future metadata additions such as zipped or not, etc.

For example: https://www.mintscan.io/osmosis/account/${accountAddress}

chain.json provides both a genesis_url and recommended_version, but these are not enough to actually start a mainnet node syncing from genesis. To make this possible, I would propose that we modify the standard codebase struct, to include both a genesis_version, and an upgrades value, which specifies enough information to automate stepping through each upgrade (either with cosmovisor, or through halt heights / external tooling).

ex (for osmosis):

"codebase": {
        "git_repo" : "https://github.com/osmosis-labs/osmosis",
        "genesis_version" : "v3.1.0",
        "upgrades" : [
          {
            "height" : 1314500,
            "version" : "v.4.2.0",
            "name" : "v4",
          },
          {
            "height" : 2383300,
            "version" : "v6.0.0",
            "name" : "v5",
          },
        ],
    }

I don't know why it's there, and seems to cause issues

@Thunnini do you know if we still need it?

Add an assetlist (https://github.com/osmosis-labs/assetlists/blob/main/assetlist.schema.json) for the native assets of all chains.