Provide blockchain info for wallets via RPC endpoint

[PeterTheOne]

I'd like to get some feedback before submitting a draft:

Intro

Every wallet (Metamask, Mobile Wallets, Web Wallets, etc.) that deals with multiple networks need some basic information for every blockchain that it connects to. Metamask for example asks for: "Network Name", "New RPC URL", "ChainID (optional)", "Symbol (optional)", "Block Explorer URL (optional)".

Most of the time there is a good default for these values, only in edge cases a user would want to customize them. There are lists for these values like https://github.com/ethereum-lists/chains where a user could manually look up the correct values. Often some networks are already pre configured by the wallet.

Proposal

There should be an RPC endpoint to fetch these values. Once the user enters the RPC url the values can be fetched from the RPC and the form fields can be filled automatically. Currently there only seems to be an endpoint to fetch the chainId.

The endpoint would provide these values when configured:

• Network Name
• ChainId
• (NetworkId)
• (Native Coin Name)
• Native Coin Symbol
• Blockchain Explorer URL (and explorer type? blockscout, etherscan, etc. to figure out the url structure...)
• (Faucet URL)

[github-actions]

Since this is your first issue, we kindly remind you to check out EIP-1 for guidance.

[tjayrush]

The two URLs can clearly not be standardized with any value other than localhost.

[MicahZoltu]

Since this would be a one-to-many relationship, there is little need for standardization. I recommend building the API you have proposed, documenting it with API docs, and then lobbying various wallets to use it. No EIP necessary. 😄

[MicahZoltu]

Ah, maybe I misunderstood. Are you wanting a new JSON-RPC method on all clients that can be queried to get the other details, so the user would only need to put in a single JSON-RPC endpoint and then fetch the rest? If so, I recommend creating an EIP for each of the endpoints you would like to see added.

[PeterTheOne]

Ah, maybe I misunderstood. Are you wanting a new JSON-RPC method on all clients that can be queried to get the other details, so the user would only need to put in a single JSON-RPC endpoint and then fetch the rest?

This is what I meant!

If so, I recommend creating an EIP for each of the endpoints you would like to see added.

Ok, so one endpoint for every value? If that is the recommended way, then I'll go with that.

[MicahZoltu]

One endpoint per value seems like a more modular solution than a single monolithic endpoint. Different wallets may want to query for different sets of data, and while there are solutions like GraphQL for that, introducing GraphQL into Ethereum clients is a bigger project (though one that there is an EIP for).

If you are going to create multiple endpoints, then I recommend one EIP per endpoint.

Note: One vs many endpoints is my personal opinion, not that of an EIP Editor. One EIP per endpoint is my EIP Editor statement, as we really prefer EIPs to be very small/modular (and it increases the chance of adoption).

[BelfordZ]

@PeterTheOne good call on this one, and thanks for taking the time to write it up. Any chance you could write the method specification using OpenRPC "method" syntax? This way we can get this added to the JSON RPC standard method set, and regenerate sdk's so we can get to using these values in a sane way :)

[PeterTheOne]

@BelfordZ Sure, please show me an example of an EIP with spec in OpenRPC syntax. The spec for eth_symbol would be very similiar to eth_chainId https://github.com/etclabscore/ethereum-json-rpc-specification/blob/255254545293e0a901bc85dda5c6bd282f98f9fc/openrpc.json#L148-L162 .

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.