EIP-2015: Wallet Update Chain JSON-RPC Method (`wallet_updateChain`)

json-rpc
#1

Following up on this discussions of the wallet_ namespaced methods, I’ve published a draft for the wallet_updateChain method first proposed here.

The EIP-2015 describes how to format a request to switch chains and the best practices to handle it and display it to the user.

1 Like
#2

The EIP is looking good so far and I’m happy with the specification to be implemented.

I would only suggest that we keep JSON-RPC requests consistent and only use hexadecimal encoded values on the parameters.

Just as eth_chainId returns the chainId value hex encoded, we should also pass this parameter and networkId on wallet_updateChain value hex encoded.

However as @danfinlay pointed out here, the EIP-747 uses decimal values but I since this EIP is also on Draft, I personally would like to suggest to change it also to have only hexdecimal values.

Add `wallet_` methods to improve dapp to wallet interaction
#3

thanks for the initiative! +1 for hex encoding and the change to 747

2 thoughts on this EIP:
should nativeCurrency get a (optional) decimals? There might be chains that don’t default to 18 here
should we make rpcURL to an array so we can pass multiple (redundancy) - we also have an array for it in https://github.com/ethereum-lists/chains
It can still just use one or even an empty array - just makes it more flexible

2 Likes
#4

Good point! Let’s add the decimals for the nativeCurrency and default it to 18.

I’m also happy with turning the rpcUrl field into an array. It will most likely include one url but makes it more flexible

1 Like
#5

Thanks for the proposal. That will be very valuable for applications that require to act on multiple chain.

Regarding, rpcUrl, this parameter should be optional as purely decentralised app will have nothing to provide for it.

1 Like
#6

yea - perhaps we should completely drop rpcUrl to not encourage going down this centralized path any further …

#7

In this scenario it does not necessarily mean that we are taking a centralized path here.

We are communicating to the wallet to switch to a different chain. This chain could be know or unknown to the Wallet. As I described on the EIP as part of the best practices, the Wallet should resort to a known node if it has the same chainId, otherwise it should use the provided rpcUrl.

Thus we are using the rpcUrl as fallback so it should be a requirement to provide this fallback endpoint in case the Wallet doesn’t have any known nodes to connect to.

#8

I think it leads us a bit more in direction centralization and I cant wait for the day the whole RPC-mess is gone …
But it might be a bit of an bold move to remove it from here. So let’s keep it - it is optional anyway if we have it as an array as the array could be empty.

1 Like
#9

Alright, let’s make it into an array and optional

#10

with an array it is already optional - the array can have a size of 0 - I think that’s cleaner - less cases to check

1 Like
#11

thinking about this more made me realize a “name” parameter can be really helpful so the wallet can display what chain the user is on in a more human way.

#12

Agreed, however I would make make it optional since this is metadata. Which also makes me realize that nativeCurrency should also be optional since it’s also metadata.

Hence the interface would be as follows:

interface NativeCurrency {
    name: string;
    symbol: string;
    decimals: number;
}

interface Eip2015Params {
    chainId: number;
    networkId: number;
    rpc: string[];
    name?: string;
    nativeCurrency?: NativeCurrency;
}

interface Eip2015Request {
    id: number;
    jsonrpc: '2.0';
    method: 'wallet_updateChain';
    params: [ Eip2015Params ];
}

PS - we still haven’t decided formally if the chainId and networkId should be decimal numbers or hexdecimal strings