Hey all. This post is inspired by this tweet I made a few weeks ago. I was trying to navigate the different EIPs / CAIPs but haven’t found them to be quite satisfactory. Or at least I don’t quite see how one of these standards is able to solve the problems we are facing with bringing Gnosis Safe as a smart contract wallet onto different networks. Therefore I was just aiming to propose a minimally viable solution for chain-specific addresses that would provide optimal UX. I am aware that I might have missed quite a few compatibility aspects etc. and that my proposed solution is not viable, so happy to receive feedback or pointers of any kind.
A standard for encoding the network into blockchain address URIs
A standard to be adapted by wallets and dApps to ensure addresses on EVM-based networks remain deterministic.
The need for this EIP emerges from the increasing adoption of non-Ethereum networks that use the Ethereum Virtual Machine. In this context, addresses are not deterministic anymore, as the same address may refer to an EOA on-chain X or a smart contract on-chain Y.
This will eventually lead to Ethereum users losing funds due to human error. For example, users sending funds to a smart contract wallet address that was not deployed on the chain the user actually did the transfer on.
This is not just a hypothetical problem, but users are actually already losing significant funds.
Besides these security issues, there are also quite a few UX reasons why chain-specific addresses should become the default:
- When a user sends someone an address they don’t want to have to explain what networks their wallet supports and where they can receive assets
- Moving funds from one network to another may result in additional costs or delays. So with more chains emerging and finding adoption, a user would want to specify the network anyways most of the times
- Transaction sender also don’t want to have to ask a recipient what their preferred network is. Or risking sending on a network that then causes inconvenience to the recipient
Chain-specific addresses are constructed as follows:
Chain-specific address = "network" ":" address” network = STRING address = STRING
network is mandatory and MUST be a valid short name from GitHub - ethereum-lists/chains: provides metadata for networkIDs and chainIDs
address is mandatory and MUST be a EIP-55 compatible hexadecimal address
I think the above-proposed solution would be the most user-friendly and easiest to coordinate the community around. Especially the human-readable nature of the network shortnames has some nice properties. Because they would mean that even if some users might not yet be used to this new address format and would remove the network identifier in favor of the traditional address format, they still understand that they should only do transactions on the network mentioned. This might not be the case with some of the alternatives below.
It would be possible to use the EIP-155 compatible chainIDs instead of the shortname
I.e. 0x...abcd@1 instead of eth:0x…abcd
Using the chainID would be technically the preferred option, as this would eliminate the dependency on the ethereum-lists repository. It would also allow for better compatibility with existing standards such as EIP-681. Basically, this would mean defining a new minimal standard as a sub-standard to EIP-681 only defining the chainID postfix.
However, the shortname is easier to understand and harder to confuse with other networks due to its human-readable nature.
The Chain Agnostic Improvement Proposals CAIP-2/CAIP-10 try to establish network identifiers that are also inclusive of non-EVM based networks. The problem is that different chain ecosystems have established their own standards for network identifiers similar to EIP-155, such as BIP122 for Bitcoin-chains, LIP9 for Lysk-chains. CAIP2 aims to solve this by referencing those standards in the chainID in order to deterministically define a given network. Potentially CAIP-2 could be utilized to establish chain-specific addresses beyond EVM-based networks. However, this would necessarily lead to a degradation in UX. As the addresses would have to look something like this in order to be compliant with CAIP-2
Ethereum mainnet 0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb@eip155:1 Bitcoin mainnet 128Lkh3S7CkDTBZ8W7BbpsN3YYizJMp8p6@bip122:000000000019d6689c085ae165831e93
This address format does not seem very user-friendly and will therefore likely be quite controversial. Therefore I argue that an EVM-focused solution is preferred as it is easier to coordinate community around the standard and shows better user experience properties.
EIP-831 and other standards define an “ethereum:” schema as part of the URI format and an optional prefix as a use-case definition.
request = "ethereum" ":" [ prefix "-" ] payload
It might be possible to leverage this prefix for network indicators.
3a) Using shortname
3b) Using chainID
This would mean using a network identifier as a prefix essentially works the same way as the
pay- prefix but specific to a given network.
This would allow for future expansion of the standard into a more chain-agnostic standard, where “ethereum:” as an indicator for EVM-based (EIP-155 compatible) chains can be replaced with for example “bitcoin:" allowing to also refer to specific networks in other blockchain ecosystems. However, having Ethereum mentioned in the address, even for EVM sidechains etc. might be misleading.
I think it would be very important for the entire community to come together and adopt chain-specific addresses as a default. In order to make the transition for users as smooth as possible, this would probably have to be a two-step process:
Dapps and wallets accept chain-specific addresses as input across the board and are just generally able to deal with chain-specific addresses
Dapps and wallets start displaying all addresses as chain-specific addresses, so users would also copy the chain-specific address and use them to communicate a given address. At this point, most dapps and wallets hopefully already implemented step 1 and the transition would be smooth for users.