Chain-specific addresses

[John-Status]

Hi @lukasschor I’ve been thinking about a related issue for some time, see these two comments for some earlier thoughts on this topic:

Increasing address size from 20 to 32 bytes

Proposal: any new address schema should support encoding multiple shard and L2 rollup chain IDs in a single address The shard and L2 rollup chain IDs that are encoded in the address would represent the destination chains into which the address owner is happy to receive tokens e.g. If an address includes the IDs for say the Ethereum L1, Optimism L2 and ZKSync L2 chains, this would signal that the owner of the address is happy for tokens sent to this address to be sent on the Ethereum L1, Optimism…

EIP-3220 crosschain id specification

@weijia31415 I think it’s very important that any enhancement of Ethereum’s address format includes the ability to encode multiple chain IDs, not just a single chain ID that is possible with EIP-1191. I’d like to experiment to see if it’s possible to devise a scheme that uses EIP-55 style case encoding to encode multiple Chain IDs into today’s Ethereum address format. This would be incompatible with also encoding an EIP-55 checksum into an address, but as we move towards a multi-chain world t…

I see the ability to attach multiple chain-IDs to an ethereum address as an important requirement.

However since writing these posts my thinking has shifted a bit and I now think that adding chain-ids to Ethereum addresses (either via extending the address format or via backwards compatible letter case encoding) is not the best approach.

Encoding chain-ids into Ethereum addresses has a fundamental problem in that once Alice shares her address with Bob, and Bob saves Alice’s address into his address book, it is very unlikely that Bob will ever update the copy of Alice’s address that he has saved in his address book. However the wallet that Alice is using is supporting more and more L2s as time goes on, however Bob will remain unaware that Alice is happy to receive funds to the L2s that Alice’s wallet only recently started supporting because the version of Alice’s address that is saved in Bob’s address book only contains the chain ID’s that Alice’s wallet supported at the time the address was shared. Even worse, say Alice switches to a different wallet that doesn’t support some of the L2s that Alice’s wallet previously supported at the time Alice shared her address with Bob (or alternatively Alice’s wallet stops supporting an L2 that it previously supported). Now next time Bob sends funds to Alice, there is a good chance that Bob’s wallet will send funds to Alice on a chain she can’t address.

I think the solution to this problem is that instead of trying to encode chain-IDs into ethereum addresses, we should use resolver services (e.g. an ENS like service) to check on which chains (chain-IDs) the owner of any given ethereum address is happy for funds to be sent to at any given time. By using a resolver service for this, the chainIDs associated with an ethereum address could be updated by the address owner’s wallet at any time.

An even better solution might be to use an identify service to further abstract this, I had a brief conversation about this with the iden3.io folks last week.

Happy to hop on a call to discuss, the Ethereum wallet community needs to align around a solution to this problem (how to determine which chains an owner of an Ethereum address is using)