ethereum-lists / chains Goto Github PK

View Code? Open in Web Editor NEW

8.2K 495.0 5.7K 151.36 MB

provides metadata for chains

Home Page: https://chainid.network

License: MIT License

Kotlin 94.11% JavaScript 5.89%

ethereum evm chainid eip155 chains hacktoberfest

chains's People

Contributors

Stargazers

Watchers

Forkers

spadebuilders ethersocialnetwork petertheone pyskell lukaszmatczak swader chandanthundercore metadium mickdegraaf nicemanss dappstore123 etclabscore fiersk17 yorugac thundercore defi-chain chainpunk freighttrust sambacha soc1c chain-id tmpfork rb-iexec cybermiles iquidus rekmarks ttblack jeanmaritain graomelo dfadden424 kianhongkh fbaud ejhanrienaout the-peso-g itzmeanjan unclezoro diodechain saurik karlfloersch ilblackdragon root-servers energywebfoundation waitoff truechain solomonic-exchange bryceweiner rubidiumchain zemse roninkaizen joys-digital meterio xlc yangwao 420integrated reppin vieyang akhekade anilchinchawale rudreshsolanki97 sebvera dominicletz stealthgerbil kjhman21 scott-ss cleancoindev poplexity aldwychnetworkdevs aldwychnetwork rlan35 mansoob verbose-void aaronmboyd frederikbolding whynoteasybro domecloud vkoskiv boundless-forest purestake paulinaparangerhr clover-network wm-chen weijia31415 antonnell coinexchain amadeobrands thaifi hicommonwealth apocentre chainsafe evrice stefneil piotrezpl goodata-org raullenchai iotexproject k-ho zalam003 tpmccallum ssemres cgc951

chains's Issues

Use GH Pages instead of Netlify

copy the just-the-docs theme in (GH Pages doesn't support it in remote theme mode)
change DNS to point to GitHub
change settings to build from GH Pages

@bmann refactor of root comment

@ligi reported SSL issues, which is a Netlify temporary issue with their CDN

I was just getting https errors from chainid.network

After talking to @bmann it seems netifly is to blame as they also currently have API connectivity issues:

I do not really see why we need netifly in the first place and would signal to just remove it.
cc @pedrouid

ChainID 101 conflict

There are two chains with the chain_id 101. We need to remove one of them!

  {
    "name": "Webchain",
    "short_name": "web",
    "chain": "WEB",
    "network": "mainnet",
    "chain_id": 101,
    "network_id": 37129,
    "rpc": []
  },
  {
    "name": "EtherInc",
    "short_name": "web",
    "chain": "WEB",
    "network": "mainnet",
    "chain_id": 101,
    "network_id": 1,
    "rpc": []
  }

Add consensus_type field

wonder if we should add a type field - POW,POA,POS

Add gas price provider

the simplest one for e.g. xDAI could be "fixed" to 1Gwei - for others we should define interfaces (e.g. to ethgasstation)

add evan

https://evan.network
ChainId : 0x4b
NodeList: https://in3.slock.it/evan/nd-3

Gitcoin Grant

@pedrouid @ligi I've already talked a bit to Pedro about this in a related email thread.

I'd like to create a Gitcoin Grant for this chains work, set at 250DAI per month.

This would go into a multisig, 2-of-3 wallet. I set it up already, let me know what addresses you want me to use for you two.

The purpose of this is to lead by example in showing the community that they can support work they find valuable, and to support the Gitcoin Grants initiative -- and more importantly the CLR matching that they are experimenting with https://medium.com/gitcoin/gitcoin-grants-clr-matching-ecbc87b10038

Not about the money, but rather an acknowledgement of value, and a default way to ask for support / thanks, which we would post on the public site and in the README.

Add BlockExplorer information

It would be great to have information about blockexplorers for the chains. It would be even better if this information is enough to generate links for [transactions,addresses,..]

add tobalaba

ChainId : 0x44d
Status : https://in3.slock.it?n=tobalaba
NodeList: https://in3.slock.it/tobalaba/nd-3

https://tobalaba.slock.it/faucet

complete info_url's

not yet all networks have the info_url - follow up from #45

Feature request: sort by id

It'd be nice to be able to sort the chains by the numerical value of their id, either ascending or descending.

Add forkid as field

thought came when thinking about ChainAgnostic/CAIPs#22

add slip44-id

Needed e.g. for Multi-Coin ENS

Use CAIP-2 as filename

currently we use EIP-155 for the filename - but this can lead to collisions (or better a problem adding chains) as @matejcik pointed out here: https://twitter.com/yangWao/status/1330871940534448128

A solution can be to use CAIP-2 as basis for the filename

Please veto now if you see problems ahead with this!

cc @pedrouid @bmann

complete info_url's

not yet all networks have the info_url - follow up from #45

Edits to EIP-155

Should we propose an edit to EIP-155 to make this the canonical source for chains?

@ligi @pedrouid

Fix chains.json order

The generated JSON file at https://chainid.network/chains.json needs to be ordered by chain_id

[New Chain / Network]

Fill out the following to add your chain / network id, OR propose a Pull Request making your edits to the _data/chains.json file directly

{
  "name": "Ethereum Mainnet",
  "shortName": "eth",
  "chain": "ETH",
  "network": "mainnet",
  "chainId": 1,
  "networkId": 1,
  "rpc": ["https://mainnet.infura.io"],
  "faucets": [],
  "infoURL: "https://ethereum.org",
  "nativeCurrency": {"name":"Ether","symbol":"ETH","decimals":18}
}

Prevent extra "," in json

@matejcik fixed one occurrence in #125 - but the CI should prevent them from slipping in
seems Klaxon does lenient parsing by default

Add GasPrice information

this is a follow-up and replaces #24

we should add a field "gasPrice" like this:

{
"infoURL": "https://gasnow.org",
"eips": [ "1599" ],
"defaultValue": "2000000000" 
}

Still thinking about a field that indicates if a gas price is stable "Under ordinary circumstances," like in xDAI
https://challenge.xdaichain.com/cost-estimates

how to build and run this project ?

invalid JSON format in chains.json

current https://chainid.network/chains.json has an empty token as the first entry.
It contains invalid JSON format "chainId": , "networkId": ,

  "name": "",
    "chainId": ,
    "shortName": "",
    "chain": "",
    "network": "",
    "networkId": ,
    "nativeCurrency": {"name":"","symbol":"","decimals":},
    "rpc": [],
    "faucets": [],
    "infoURL": ""
  },

Request: Publish as npm package

For consumers of chains.json that don't want to query the chainId.network website, it'd be nice if chains.json were published as an npm package. I'd be happy to help maintain the package if that would be helpful.

Deploy to ENS

Context/spark: https://twitter.com/kevingaspar/status/1273785607479844866

website as in http://chainid.network
and the json

opening as issue to discuss the following with @pedrouid and @bmann :

deployment pipeline
ENS key handling
update frequency (after each PR?)
fee handling

API keys

follow up from this mail from infura:


7 days remaining to update your Infura API authentication | 7 days remaining to update your Infura API authentication | 7 days remaining to update your Infura API authentication
-- | -- | --
7 days remaining to update your Infura API authentication | 7 days remaining to update your Infura API authentication
7 days remaining to update your Infura API authentication
This is the final message being sent prior to a very important change that will impact all users of the Infura API endpoints.  In this January 17th blog post,  we provided the latest timeline to deprecate our legacy API  authentication. Requests will start to require a Project ID generated  from the Infura Dashboard. More information on how to send requests  using a Project ID can be found in our docs. The next upcoming change will occur on:  March 27, 2019, 20:00 UTC Support will officially stop for all requests not sent using an Infura Dashboard-generated Project ID.  This transition will ensure that our service reliability and performance  is consistent for all users. For more information about the changes  please see the blog post linked above.  What do I need to do? If you haven’t done so already, create a free account at https://infura.io/register.  Once you log in to the Dashboard, simply create a new project, and your  Project ID (and associated Infura API endpoint URLs) will be generated.  Replace your old Infura URL in your code with the newly generated URL  from the Dashboard.  You may also create multiple projects to isolate traffic for multiple  dapps/use-cases. Stats can be viewed in aggregate or on a per-project  basis.  If you maintain a library that leverages Infura, please reach out directly to help you with this transition.  How do I know I am using the correct API endpoint URL? Prior to July 2018, your Infura API endpoint would have looked like this:  https://mainnet.infura.io/[YOUR_KEY]   The updated API endpoint using the new authentication generated in the Infura Dashboard will look like this:  https://mainnet.infura.io/v3/[PROJECT_ID]   If you have any questions please post them at community.infura.io or email us at [email protected]. | This is the final message being sent prior to a very important change that will impact all users of the Infura API endpoints.  In this January 17th blog post,  we provided the latest timeline to deprecate our legacy API  authentication. Requests will start to require a Project ID generated  from the Infura Dashboard. More information on how to send requests  using a Project ID can be found in our docs. The next upcoming change will occur on:  March 27, 2019, 20:00 UTC Support will officially stop for all requests not sent using an Infura Dashboard-generated Project ID.  This transition will ensure that our service reliability and performance  is consistent for all users. For more information about the changes  please see the blog post linked above.  What do I need to do? If you haven’t done so already, create a free account at https://infura.io/register.  Once you log in to the Dashboard, simply create a new project, and your  Project ID (and associated Infura API endpoint URLs) will be generated.  Replace your old Infura URL in your code with the newly generated URL  from the Dashboard.  You may also create multiple projects to isolate traffic for multiple  dapps/use-cases. Stats can be viewed in aggregate or on a per-project  basis.  If you maintain a library that leverages Infura, please reach out directly to help you with this transition.  How do I know I am using the correct API endpoint URL? Prior to July 2018, your Infura API endpoint would have looked like this:  https://mainnet.infura.io/[YOUR_KEY]   The updated API endpoint using the new authentication generated in the Infura Dashboard will look like this:  https://mainnet.infura.io/v3/[PROJECT_ID]   If you have any questions please post them at community.infura.io or email us at [email protected]. | This is the final message being sent prior to a very important change that will impact all users of the Infura API endpoints.  In this January 17th blog post,  we provided the latest timeline to deprecate our legacy API  authentication. Requests will start to require a Project ID generated  from the Infura Dashboard. More information on how to send requests  using a Project ID can be found in our docs. The next upcoming change will occur on:  March 27, 2019, 20:00 UTC Support will officially stop for all requests not sent using an Infura Dashboard-generated Project ID.  This transition will ensure that our service reliability and performance  is consistent for all users. For more information about the changes  please see the blog post linked above.  What do I need to do? If you haven’t done so already, create a free account at https://infura.io/register.  Once you log in to the Dashboard, simply create a new project, and your  Project ID (and associated Infura API endpoint URLs) will be generated.  Replace your old Infura URL in your code with the newly generated URL  from the Dashboard.  You may also create multiple projects to isolate traffic for multiple  dapps/use-cases. Stats can be viewed in aggregate or on a per-project  basis.  If you maintain a library that leverages Infura, please reach out directly to help you with this transition.  How do I know I am using the correct API endpoint URL? Prior to July 2018, your Infura API endpoint would have looked like this:  https://mainnet.infura.io/[YOUR_KEY]   The updated API endpoint using the new authentication generated in the Infura Dashboard will look like this:  https://mainnet.infura.io/v3/[PROJECT_ID]   If you have any questions please post them at community.infura.io or email us at [email protected].
This is the final message being sent prior to a very important change that will impact all users of the Infura API endpoints.  In this January 17th blog post,  we provided the latest timeline to deprecate our legacy API  authentication. Requests will start to require a Project ID generated  from the Infura Dashboard. More information on how to send requests  using a Project ID can be found in our docs. The next upcoming change will occur on:  March 27, 2019, 20:00 UTC Support will officially stop for all requests not sent using an Infura Dashboard-generated Project ID.  This transition will ensure that our service reliability and performance  is consistent for all users. For more information about the changes  please see the blog post linked above.  What do I need to do? If you haven’t done so already, create a free account at https://infura.io/register.  Once you log in to the Dashboard, simply create a new project, and your  Project ID (and associated Infura API endpoint URLs) will be generated.  Replace your old Infura URL in your code with the newly generated URL  from the Dashboard.  You may also create multiple projects to isolate traffic for multiple  dapps/use-cases. Stats can be viewed in aggregate or on a per-project  basis.  If you maintain a library that leverages Infura, please reach out directly to help you with this transition.  How do I know I am using the correct API endpoint URL? Prior to July 2018, your Infura API endpoint would have looked like this:  https://mainnet.infura.io/[YOUR_KEY]   The updated API endpoint using the new authentication generated in the Infura Dashboard will look like this:  https://mainnet.infura.io/v3/[PROJECT_ID]   If you have any questions please post them at community.infura.io or email us at [email protected]. | This is the final message being sent prior to a very important change that will impact all users of the Infura API endpoints.  In this January 17th blog post,  we provided the latest timeline to deprecate our legacy API  authentication. Requests will start to require a Project ID generated  from the Infura Dashboard. More information on how to send requests  using a Project ID can be found in our docs. The next upcoming change will occur on:  March 27, 2019, 20:00 UTC Support will officially stop for all requests not sent using an Infura Dashboard-generated Project ID.  This transition will ensure that our service reliability and performance  is consistent for all users. For more information about the changes  please see the blog post linked above.  What do I need to do? If you haven’t done so already, create a free account at https://infura.io/register.  Once you log in to the Dashboard, simply create a new project, and your  Project ID (and associated Infura API endpoint URLs) will be generated.  Replace your old Infura URL in your code with the newly generated URL  from the Dashboard.  You may also create multiple projects to isolate traffic for multiple  dapps/use-cases. Stats can be viewed in aggregate or on a per-project  basis.  If you maintain a library that leverages Infura, please reach out directly to help you with this transition.  How do I know I am using the correct API endpoint URL? Prior to July 2018, your Infura API endpoint would have looked like this:  https://mainnet.infura.io/[YOUR_KEY]   The updated API endpoint using the new authentication generated in the Infura Dashboard will look like this:  https://mainnet.infura.io/v3/[PROJECT_ID]   If you have any questions please post them at community.infura.io or email us at [email protected].
This is the final message being sent prior to a very important change that will impact all users of the Infura API endpoints.  In this January 17th blog post,  we provided the latest timeline to deprecate our legacy API  authentication. Requests will start to require a Project ID generated  from the Infura Dashboard. More information on how to send requests  using a Project ID can be found in our docs. The next upcoming change will occur on:  March 27, 2019, 20:00 UTC Support will officially stop for all requests not sent using an Infura Dashboard-generated Project ID.  This transition will ensure that our service reliability and performance  is consistent for all users. For more information about the changes  please see the blog post linked above.  What do I need to do? If you haven’t done so already, create a free account at https://infura.io/register.  Once you log in to the Dashboard, simply create a new project, and your  Project ID (and associated Infura API endpoint URLs) will be generated.  Replace your old Infura URL in your code with the newly generated URL  from the Dashboard.  You may also create multiple projects to isolate traffic for multiple  dapps/use-cases. Stats can be viewed in aggregate or on a per-project  basis.  If you maintain a library that leverages Infura, please reach out directly to help you with this transition.  How do I know I am using the correct API endpoint URL? Prior to July 2018, your Infura API endpoint would have looked like this:  https://mainnet.infura.io/[YOUR_KEY]   The updated API endpoint using the new authentication generated in the Infura Dashboard will look like this:  https://mainnet.infura.io/v3/[PROJECT_ID]   If you have any questions please post them at community.infura.io or email us at [email protected].

wonder how we deal with mandatory api keys in rpc services

Add RPC endpoints

wonder if we should add a list of RPC endpoints (can also be an empty list - so the field is optional) for the chains.
Inspired by #10 (comment)

This would also allow a ci-script to make checks for the chain_id (also inspired by the very same PR)

Disadvantage might be that it is widening the scope too much - what does the rest of the team think?

import from Trezor ethereum networks list

For Trezor we maintain a similar list here: https://github.com/trezor/trezor-common/blob/master/defs/ethereum/networks.json

You might want to add new networks from the list and also add the fields from our list. Except for blockbook all of them are not-specific for Trezor and could be useful for everybody.

Feel free to ask for details if needed.

Add grant link to about page

with a text like "Help to cover the DNS and ENS fees" with our gitcoin grant.

should do after deployment to ENS

Add domain to attach to GH Pages

Website is now building to GH Pages, just talking to @expede about access to evm.network as the domain to attach here.

The temporary example site is still at https://quizzical-noether-15cda1.netlify.com

Add chainIDs from IN3 whitepaper

in section 6.1 of the incubed whitepaper:

https://download.slock.it/whitepaper_incubed_draft.pdf

we find some more chainIDs that are not in our list. I am not yet sure where some of them originate (e.g. IPFS as I am not aware of any EIP155 signing there - also googleing for 0x07da ipfs mainly surfaces the slock.it in3 whitepaper)
We should still think about adding them - also e.g. the chainSpec field from their config: https://github.com/slockit/in3/blob/master/src/client/defaultConfig.json
I would even signal to add all chain-specific data from this json file so we can run IN3 clients for the chains with this information. But this might be a bit opinionated and out of scope - cc @pedrouid @bmann

@simon-jentzsch @CJentzsch can you elaborate where 0x07da from the whitepaper is coming from?

duplicated chainID

wonder if we should remove the chainID as it is already the key. feels WET - would love it to be more DRY

Add ENS registries

from: https://docs.ens.domains/ens-deployments

Mainnet, at 0x314159265dd8dbb310642f98f50c066173c1259b.
Ropsten, at 0x112234455c3a32fd11230c42e7bccd4a84e02010.
Rinkeby, at 0xe7410170f87102df0055eb195163a03b7f2bff4a.
Goerli, at 0x112234455c3a32fd11230c42e7bccd4a84e02010.

Experiment with radicle

Can we use Radicle for storing this info? Experiment with this. https://radicle.xyz

Add derivative JSON with infos from RPC

e.g. the clientVersion(s) from RPC might be interesting and e.g. nice to display on a details page for the chains on chainid.network

Ethereum Mainnet
Client:Geth/v1.8.22-omnibus-260f7fbd/linux-amd64/go1.11.1
BlockNumber:7355326
GasPrice:2000000000
Client:Parity-Ethereum//v2.2.11-stable-8e31051-20190220/x86_64-linux-gnu/rustc1.32.0
BlockNumber:7355326
GasPrice:6000000000

Expanse Network
Client:null
BlockNumber:null
GasPrice:null

Ethereum Testnet Ropsten
Client:Geth/v1.8.22-omnibus-260f7fbd/linux-amd64/go1.11.1
BlockNumber:5190189
GasPrice:1000000000

Ethereum Testnet Rinkeby
Client:Geth/v1.8.20-omnibus-c5febb98/linux-amd64/go1.11.1
BlockNumber:4018578
GasPrice:1000000000

Ethereum Testnet Görli
Client:Geth/v1.9.0-unstable-f0233948/linux-amd64/go1.11.5
BlockNumber:227729
GasPrice:10000000000
Client:Parity-Ethereum//v2.4.0-unstable-UNKNOWN-UNKNOWN/x86_64-linux-musl/rustc1.31.1
BlockNumber:227730
GasPrice:10000000000
Client:Geth/v1.9.0-unstable-1a3e25e4/linux-amd64/go1.12
BlockNumber:227729
GasPrice:10000000000

Ethereum Classic Testnet Kotti

Ubiq Network Mainnet
Client:null
BlockNumber:769585
GasPrice:20000000000

Ubiq Network Testnet

Ethereum Social

Rootstock Mainnet
Client:RskJ/0.6.1/Linux/Java1.8/SNAPSHOT-6c4fcde8
BlockNumber:1207861
GasPrice:65164000

Rootstock Testnet
Client:RskJ/0.6.1/Linux/Java1.8/SNAPSHOT-6c4fcde8
BlockNumber:395272
GasPrice:0

Ethereum Testnet Kovan
Client:Parity-Ethereum//v2.2.10-stable-7b1d3e1-20190213/x86_64-linux-gnu/rustc1.32.0
BlockNumber:10537566
GasPrice:1000000000

GoChain
Client:null
BlockNumber:5194156
GasPrice:2000000000

Ethereum Classic Mainnet
Client:Parity-Ethereum//v2.2.10-stable-7b1d3e1-20190213/x86_64-linux-gnu/rustc1.32.0
BlockNumber:7648988
GasPrice:1100000000

Ethereum Classic Testnet

Ellaism
Client:Parity//v1.10.6-unstable/x86_64-linux-gnu/rustc1.26.2
BlockNumber:3464831
GasPrice:0

Mix
Client:Parity-Ethereum//v2.3.5-stable-ebd0fd0-20190227/x86_64-linux-gnu/rustc1.32.0
BlockNumber:3852222
GasPrice:50000000000

POA Network Sokol
Client:Parity-Ethereum//v2.3.2-beta-678138f-20190203/x86_64-linux-gnu/rustc1.31.1
BlockNumber:7596757
GasPrice:1000000000

TomoChain
Client:tomo/sun/v1.3.0-stable/linux-amd64/go1.10.8
BlockNumber:1219702
GasPrice:252000000

POA Network Core
Client:Parity-Ethereum//v2.3.2-beta-678138f-20190203/x86_64-linux-gnu/rustc1.31.1
BlockNumber:7758381
GasPrice:1000000000

xDAI Chain
Client:Parity-Ethereum//v2.3.2-beta-678138f-20190203/x86_64-linux-gnu/rustc1.31.1
BlockNumber:2614496
GasPrice:0

Webchain
Client:webchaind/v0.2.0/linux/go1.10rc2
BlockNumber:1860795
GasPrice:200000000000

EtherInc
Client:Geth/v1.8.0-unstable-ac1228ad/linux-amd64/go1.9.2
BlockNumber:2601741
GasPrice:20000000000

Callisto Mainnet
Client:Geth/v1.8.23-stable-d511f55f/linux-amd64/go1.11.1
BlockNumber:2214682
GasPrice:1300000000

Callisto Testnet

Atheios
Client:gath/v1.0.3-phi-45cf16e9/linux/go1.6.2
BlockNumber:1194657
GasPrice:20000000000

Teslafunds
Client:Gtsf/v1.2.1-stable-bb816bcb/linux-amd64/go1.11.1
BlockNumber:47768
GasPrice:10000000000

EtherGem
Client:egem/v1.0.7-tolkien-fixed-dc5c6d30/linux-amd64/go1.10.8
BlockNumber:2227598
GasPrice:20000000000

EOS Classic

Webchain (after block xxxxxxx)
Client:webchaind/v0.2.0/linux/go1.10rc2
BlockNumber:1860795
GasPrice:200000000000

Ethersocial Network
Client:Gesn/v0.3.6-stable-51f14708/linux-amd64/go1.9.4
BlockNumber:2710918
GasPrice:20000000000

Akaroma
Client:Geth/v0.4.1-akroma-98d020be/linux-amd64/go1.11.5
BlockNumber:2770875
GasPrice:20000000000

ARTIS sigma1
Client:Parity-Ethereum//v2.2.9-stable-5d5b372-20190203/x86_64-linux-gnu/rustc1.31.1
BlockNumber:2021844
GasPrice:1100000000

ARTIS tau1
Client:Parity-Ethereum//v2.2.10-stable-7b1d3e1-20190213/x86_64-linux-gnu/rustc1.32.0
BlockNumber:1324462
GasPrice:1100000000

Ether-1
Client:Geth/v1.1.7.1-Ether1-Security-Update/linux-amd64/go1.11.5
BlockNumber:1945374
GasPrice:30000000000

Musicoin
Client:GMC/v2.7.0-beta-b4e0f8d0/linux-amd64/go1.11.1
BlockNumber:4514672
GasPrice:10000000000

IOLite
Client:null
BlockNumber:null
GasPrice:null

Pirl
Client:Pirl/v1.8.2-hulk-ccd6d082/linux-amd64/go1.10
BlockNumber:3274693
GasPrice:30000000000

Lisinski
Client:Geth/v1.8.23-stable-c9427004/linux-amd64/go1.10.4
BlockNumber:86475
GasPrice:1000000000

ThunderCore Mainnet
Client:thunder/v0.5.0-95879392644fbfd9060b955aaef25ce58d2e0e90/linux-amd64/go1.10.2
BlockNumber:1206503
GasPrice:10000000000

ThunderCore Testnet
Client:thunder/v0.5.0-2e89418c30eee9c2a356840c0d77cdf2e55a6644/linux-amd64/go1.10.2
BlockNumber:4582700
GasPrice:25000000000

Metadium Mainnet
Client:Geth/v1.8.23-stable-18244f12/linux-amd64/go1.10.3
BlockNumber:24
GasPrice:80000000000

Metadium Testnet
Client:Geth/v1.8.15-unstable-c080b206/linux-amd64/go1.10.1
BlockNumber:115498
GasPrice:18000000000

Add faucets

I think this could be very practical. Also a defined token for an address.In KEthereum I use a token like this for it:

"https://goerli-faucet.slock.it/?address=%address%"

introduce field baseTokenName

I think this could be helpful - I currently actually need it ;-)

one json per network

the json containing all chains will grow hard to edit at some point. in the ethereum-lists/tokens repo we switched to one token json files then that afterwards get assembled by the ci to a single json file.
What do you think @bmann @pedrouid

False alarm, I can't read

Sorry to alarm you guys, my bad. Please delete this ASAP.

Auxilium chain causing problems on Windows

chains/_data/chains/28945486.json

Line 15 in 16fcf0d

"shortName": "aux",

the Auxilium chain uses short name aux.
This is a reserved file name on Windows. I'm not sure if it's a problem when it is a directory (if we ever add Auxilium tokens, the tokens repo will need to get a aux subdir), but it is definitely a problem with a file.

We ran into this when storing icons as <shortName>.png

If it's OK, I propose changing the shortName to auxi

Add chain reference resolvers to CAIP-2 namespaces

This has been previously discussed and something that should be done asap

CAIP-2 should require namespaces to reference how to resolve chain references from its node endpoints

Deeplink support for the chains

Just when doing this post - I thought it would be nice to be able to deep link to a network on https://chainid.network so users see all details we have about this networkd. Something like https://chainid.network/byID/5

differentiate EVM <> OVM

currently we list optimism in our list - but when we would deploy EVM bytecode it would fail
so I think a VM field would make sense - it would default to EVM - but for optimistic chains we can add:

"vm":"OVM"

Add projectName and projectShortName fields

Right now, there is no explicit, non-heuristic way to distinguish which chains are part of the same "project" or "system of networks" (i.e. which chains are "siblings" — maintained by the same community, run by the same validators, etc.)

I want to be able to look at e.g. ETH Mainnet, Ropsten, Kovan, Rinkeby, and Görli, and be able to automatically determine "those are all Ethereum"; and then look at e.g. ETC Mainnet, Kotti, Morden, and Mordor, and be able to automatically determine "those are all Ethereum Classic." I want to be able to build hierarchical navigation logic where you can first pick a project, and then pick a network/chain "of" that project. Right now, doing this requires that I manually scrub and enrich the chains.json data, which kind of betrays the principle of having this data all already available and fetchable in machine-readable form.

Theoretically, this is what networkId should mean. But that's a lost cause — because of all the pre-CHAINID chains that use distinct networkIds despite being part of the same project, networkId is basically meaningless at this point, except as machine-readable data to talk to some very old node software.
Grouping by chainName doesn't really work (despite this seeming to be the purpose of the chainName field?) as there are separate projects that reuse a "parent" project's chainName, e.g. https://www.elastos.org/ and https://primusmoney.com both having a chainName of "ETH" despite not having any affiliation with Ethereum. (They're only "Ethereum" to the degree that they run on the same node software, as all EIP155 chains do.)
Grouping by infoUrl almost works for this! but there are exceptions, e.g. Görli having its own separate infoUrl instead of pointing at https://ethereum.org.

What does ~basically work, is parsing the name field and dropping the words Testnet/Mainnet and anything that comes after them.

IMHO, it'd be very helpful if there was a field in each chain that effectively contained the "first part" of what the name field contains. In other words, a projectName. Unlike chainName, it'd be human-readable. Also unlike chainName, it'd actually work for grouping :)

Some additional thoughts:

The "other part" of the name field could be put into its own field as well, maybe something like componentName or serviceName. Seemingly right now networkName is being used as a slug-ified representation of this information, but it'd be helpful to be able to get it in human-readable form. (Also, there's nothing forcing contributors to use networkName this way, so it has exceptions in it as well, e.g. chain-211 Freight Trust Network having a networkName of "freight & trade network". That's not even a slug!)
The resulting projects data would be somewhat repetitive and hard to maintain. It might be easier to normalize it—i.e. break these fields out into files in a separate directory _data/projects, assigning each project its own (arbitrary) foreign-key sequential ID number, and updating the chains in _data/chains to reference the project they belong to by its ID. This file could contain:
- a human-readable name
- a shortName or slug
- an infoUrl for the project itself
- potentially, the chainId for the "primary" or "production" chain that the project's community's efforts are focused toward
- potentially, a projectId that this project is a "forkOf" (e.g. in the case of Ethereum Classic)
- potentially, a projectId for a "parent" or "umbrella" project, if this project isn't a fork (= no difference in community membership), but is a set of networks that both "belong to" a parent project while also being their own thing (as e.g. the ETH2.0 networks are to the greater ETH community/ecosystem.)

Görli

wonder if we should rename görli as it will become chainID 5 - 6284 is just temp as far as I understood @5chdn correctly

"6284": {
    "name": "Ethereum Görli",
    "chain": "eth",
    "network": "gorli",
    "chainId": 6284,
    "networkId": 6284
  }

duplicate shortNames in the dataset

ERROR colliding chain name ELAETHSC: eth:ETH:20 (ELA-ETH-Sidechain Mainnet), eth:tETH (ELA-ETH-Sidechain Testnet)
ERROR colliding chain name bnb: eth:BNB (Binance Smart Chain Mainnet), eth:tBNB (Binance Smart Chain Testnet)
ERROR colliding chain name matic: eth:MATIC:137 (Matic Mainnet), eth:MATIC:80001 (Matic Mumbai)
ERROR colliding chain name ath: eth:ATH:1620 (Atheios), eth:ATH:43110 (Athereum)
ERROR colliding chain name ats: eth:ATS (ARTIS sigma1), eth:tATS (ARTIS Testnet tau1)
ERROR colliding chain name near: eth:NEAR (NEAR MainNet), eth:tNEAR (NEAR TestNet)

i'll be sending a PR to resolve the above shortly. however, this repo should do duplicate detection before accepting a definition

scheduled chain releases

just had in #48 the case that a chain is not yet released. hence I do not want to merge so no one runs into a non function chain. But it would be great to merge in "draft" state - so e.g. the chainID is already announced and so perhaps collisions avoided.

Prevent empty strings

seen in #172 (review)

CI should prevent

Add description & git URI fields

field name: description

A human readable short paragraph that describes the chain.

type: long text. No limit, but suggested to keep it tweet length, 280 characters. May contain Markdown.

field name: git

A link to a git repo or organization that represents the chain.

type: URI

This could be an array, maybe keep it simple and just be empty or 1 URI.

Ethereum

description: The main public chain for Ethereum
git: https://github.com/ethereum

Ethereum Classic

description: The Classic Ethereum chain that resulted from the split after the DAO hack.
git: https://github.com/ethereumclassic

Görli

description: The Görli testnet
git: https://github.com/goerli

I started with git as we can focus on technical resources. A website field could also be added, but then I would have to link to EthereumDotOrg and be embarrassed 🤣

Add Rubidium chainId/networkId

Fill out the following to add your chain / network id, OR propose a Pull Request making your edits to the _data/chains.json file directly

{
  "name": "Wegochain Rubidium Mainnet",
  "chain": "RBD",
  "network": "mainnet",
  "rpc": [
    "https://proxy.wegochain.io",
    "http://wallet.wegochain.io:7764"
  ],
  "faucets": [],
  "nativeCurrency": {
    "name": "Rubid",
    "symbol": "RBD",
    "decimals": 18
  },
  "infoURL": "http://wegochain.io",
  "shortName": "rbd",
  "chainId": 5869,
  "networkId": 5869
}

Add bip122 URL

bip122 urls could be useful

Create a Definitions page

Create a field definitions page that explains each field, what it contains, and any usage / consumption details.

This will help in people programmatically consuming the JSON file, since we can’t put comments in JSON.