EIP-5139: Remote Procedure Call Provider Lists

1 Like

Any time I see these sort of “registry” or “list” ideas, I ask the obvious question: who is allowed to maintain this list.

I’m not in any way arguing that this is or is not a good idea. (In fact, I think it is a good idea), but without at least a discussion of mechanism involved in who manages this list, this has all the obvious problems.

  1. who reviews it?
  2. who says who’s a valid entry?
  3. what are the criteria for a valid entry?
  4. how do we avoid people paying to be included (or paying to remove someone else)?

At the very least these questions should be addressed in the document. In fact, I think one would need to fully flesh out how this would work. The fact that these considerations are non-existent in the EIP is a non-starter for me.

1 Like

ChainId being listed ultimately is for readability, a wallet would be remise to not check for chainId/netVersion when connecting to a new rpc endpoint.

Yeah, I’d expect wallets to continue to do that.

Net Version is used by metamask fwiw.

I’m mostly going for compatibility with EIP-3326, which uses chain id as the key. Would adding net version help wallets verify the RPC endpoint, and if so, how often do net versions change?

It would ultimately be up to the end user to review whatever list they choose to use. Most of the time, users would default to the list provided by their wallet, which would be maintained by the wallet developers. Since we already give ultimate control over private keys to wallets, it seems reasonable to also delegate provider list maintenance to wallet devs.

In a formatting sense, wallets would be expected to validate lists against the JSON schema. In a more practical sense, that’s really up to the user to decide who to subscribe to. Maybe some service will come along that monitors your RPC activity and in exchange recommends products and services you might like :rofl:

If the schema validates, it’s a valid list. If the providers listed don’t work, then it’s a bad list and you shouldn’t subscribe to it.

We don’t. I completely expect each wallet to have their own list and not list competing providers. That’s no different from what we have now. The benefit of this standard is to allow users to easily choose other lists, without normalizing adding random one-off providers from whatever dapp you happen to be on.

I’ll add some of this to the document.

I do not think net_version helps at all actually, more of an artifact of a pre-ChainId environment.

Are you wanting to use the latest JSON-Schema format as I see its using https://json-schema.org/draft/2020-12/schema version? I ask because I would have thought using OpenRPC format would be natural (I do not know the differences if any).

Are you also wanting to enumerate custom RPC methods that may be supported by difference RPC Providers? What sort of help do you want?


Good to know, I won’t include it then.

I did choose the latest version, though I’m not super familiar with JSON Schema. I can use an older version if there’s a good reason?

I think OpenRPC is for defining an interactive API, while JSON Schema is for defining the structure of a single file, though I may be mistaken. These lists are single files, so I went with JSON Schema.

I have a few concerns about adding this kind of information:

  1. What is the value of adding this information to the list instead of the wallet trying the functions itself?
  2. How do you account for different implementations of the same function (eth_signTypedData being a prime example)?
  3. Is this a lot to ask of list maintainers?

Will get back to you after hearing more about this its looking nice :+1: