Add ERC: Human readable names for Interoperable Addresses #735

jrudolf · 2024-11-27T10:44:55Z

No description provided.

eip-review-bot · 2024-11-27T10:45:28Z

File `ERCS/erc-7828.md`

Requires 1 more reviewers from @g11tech, @SamWilsn, @xinbenlv

eip-review-bot

All Reviewers Have Approved; Performing Automatic Merge...

niran · 2024-11-27T20:44:12Z

ERCS/erc-chain_specific_addresses.md

+
+The resolution of a `address@chain` on the contrary, imposes that the left-hand resolves to an address and the right-hand to a chain identifier.
+
+When given a `[email protected]`, the wallet can resolve `rollup.eth` to get a chain identifier and `user.rollup.eth` to get an address. In any other case it fails.


This doesn't require a new syntax: When the wallet is resolving user.rollup.eth, the standard resolution process should be resolve to resolve the way you described: resolve rollup.eth to get a chain identifier and user.rollup.eth to get an address.

This approach also allows user.rollup.eth to override this behavior by setting a record for their own preferred chain identifier to use when their ENS name is resolved. *.rollup.eth names will likely never override this, but I'd expect almost every user.eth to want to receive funds on some chain that isn't L1.

niran · 2024-11-27T20:47:09Z

ERCS/erc-chain_specific_addresses.md

+```
+### Note: default fallbacks
+
+If a user receives a legacy address without chain name, the wallet can:


I don't think any of these fallbacks should be our target behavior. Users should be able to control on which chain assets sent to their ENS name arrive. I think ENS experts should lead the way on this resolution process via an ENSIP.

ERCS/erc-chain_specific_addresses.md

vbuterin · 2024-11-29T02:29:27Z

ERCS/erc-chain_specific_addresses.md

+account ::= <user>@<chain>
+```
+
+Note the difference between `ens-name`, which is a full ENS name, and `ens-subdomain` that is just a segment of a name between dots. E.g. `user.app.eth` is a name, `user` and `app` are subdomains.


In the below examples, isn't the user also just <address> | <ens-name>?

In the examples below it's indeed an but if I understand correctly it could also use an ens-subdomain such as [email protected] which might mean something different from [email protected].

The former would resolve user locally on arbitrum, and the latter (being a fully-qualified name) would resolve user.eth on L1. Is that not the intention?

This actually opens up a very big issue that I believe it’s not discussed here: in theory, user should beuser across the whole Ethereum ecosystem at least, but in fact there are many Domain Name Services beyond ENS that are local to some L2s or even just one.

For example, I have jaack.eth, and also registered jaack.avax on Avalanche C-Chain and jaack.blast on Blast.

First, I believe we should consider ENS as the ‘main router’ for DNS resolutions, because it’s stated as a requirement in the ERC. Since this is the case, then resolution should be global across Ethereum, including rollups. So user needs to be `user.eth on any chain, especially considering that this ERC would likely be implemented around the time that Namechain will be at least on testnet, so the ENS registry is itself on a ‘service’ L2.

@yoavw the case where an address is local only to its chain is the one where most addresses owned by users are smart wallets / accounts that are not the same across chains (unlike EOAs, that have the same pubkey / privkey across any EVM).

Co-authored-by: Andrew B Coathup <[email protected]>

SamWilsn

This is close to acceptable for a draft. My biggest issue is that it is written very vaguely, and doesn't present a solid/definite algorithm for name resolution. You have a lot of can/could language, and present several alternatives instead of picking one specification.

SamWilsn · 2025-04-15T19:59:32Z

ERCS/erc-7828.md

+This proposal builds off of [ERC-7785](./eip-7785.md) (on-chain configs) to provide a standard and human-readable format for chain-specific L2 addresses:
+- A unified format for accounts that specifies, together with the address, the chain where the address lives.
+- The use of human-readable chain names and how they can be resolved to chain identifiers using ENS on L1.
+- The use of human-readable account names and how they can be resolved to addresses using ENS on L2.


Your abstract is a bit too much like an introduction. It doesn't contain enough detail to give the reader a technical overview of how the proposal accomplishes its goals. I'd expect to see at least an example of what an address looks like, and a brief sketch of how resolution works.

SamWilsn · 2025-04-15T20:00:37Z

ERCS/erc-7828.md

+```
+L1-TLD ::= eth | sepolia | …
+chain_id ::= 0x[a-fA-F0-9]{1,64}
+address ::= 0x[a-fA-F0-9]{40}
+chain ::= <chain_id> | <L1-TLD> | <ens-name> . <L1-TLD>
+user ::= <address> | <ens-subdomain>
+account ::= <user>@<chain>
+```


It would be nice to note what format these snippets are in.

SamWilsn · 2025-04-15T20:01:47Z

ERCS/erc-7828.md

+- [email protected]
+```
+
+Option 2: using : instead of @ 


You should write proposals as if they are already Final. It gets confusing otherwise. If you have multiple options, choose one for now and  the rest.

SamWilsn · 2025-04-15T20:02:42Z

ERCS/erc-7828.md

+Two desired properties:
+1) checksums are MANDATORY
+2) checksum hash goes over the entire address, so users can't just go and replace a component and expect it to stay valid


This type of content belongs in the Rationale section, as it is describing why you made particular choices. Keep the Specification section as close to just requirements as possible so it's easy for an implementer to follow.

SamWilsn · 2025-04-15T20:05:49Z

ERCS/erc-7828.md

+### A special case for ENS resolution
+
+Any ENS name today can be resolved to a chain identifier or to an address.
+We could imagine having a name `user.eth` that points to a record of the form `{address ; chain_id}`. Given such an address a wallet can verify it resolves to a valid account.
+The advantage of this format is that it is very flexible and can accommodate a number of use cases, however it can also lead to confusion for users because a name does not necessarily resolve to a valid account. The same `user.eth` could lead to a website, a NFT or multiple addresses.
+
+The resolution of a `address@chain` on the contrary, imposes that the left-hand resolves to an address and the right-hand to a chain identifier.
+
+When given a `[email protected]`, the wallet can resolve `rollup.eth` to get a chain identifier and `user.rollup.eth` to get an address. In any other case it fails.


This section is really mixing rationale and specification. I can't tell if line 129 is a requirement ("In any other case it fails.") or just context.

SamWilsn · 2025-04-15T20:07:30Z

ERCS/erc-7828.md

+
+### L2 resolution
+
+In case an address is not registered on L1, but only on a L2, the resolution can be processed using [ERC-3668](./eip-3668.md) and [ERC-2544](./eip-2544.md)'s  Wildcard Resolution.


We don't allow links to ENSIPs, but if you'd like to request an exception the process is documented in EIP-5757.

SamWilsn · 2025-04-15T20:08:56Z

ERCS/erc-7828.md

+
+#### Note: avoiding the http gateway
+
+In order to avoid contacting an external http gateway, we could define the gateway to be a ENS contract on the L2. In this way a wallet operator would need to only rely on a node following the L1 and a node following the L2.


Who is this an instruction for (like who is "we" here)? If this is a note to the authors, wrap it in a TODO comment:

Suggested change

In order to avoid contacting an external http gateway, we could define the gateway to be a ENS contract on the L2. In this way a wallet operator would need to only rely on a node following the L1 and a node following the L2.

u59149403 · 2025-04-20T00:41:07Z

ERCS/erc-7828.md

+- [email protected]
+
+My ENS name is registered on rollup1, but I want to receive funds on rollup2
+- [email protected]


Too quirky. It is too hard to understand that alice.eth part of [email protected] should be resolved on arbitrum.eth chain, but alice.rollup1.eth part of [email protected] should be resolved on rollup1.eth

u59149403 · 2025-04-20T00:43:34Z

ERCS/erc-7828.md

+- [email protected]
+```
+
+Option 2: using : instead of @ 


: implies totally different hierarchy. I. e. a:b means that b is located inside of a

u59149403 · 2025-04-20T00:47:56Z

ERCS/erc-7828.md

+
+### L1 resolution
+
+Ethereum Mainnet and its testnets can be resolved to their corresponding chain identifiers using a centralized list, which remains unchanged from how it works today. Other L1 registrations are out of scope for this EIP.


Other L1 registrations are out of scope for this EIP

I totally don't like this. Other L1s should be supported somehow

taken care of 😎

u59149403 · 2025-04-20T00:50:00Z

ERCS/erc-7828.md

+
+### Note: clashes of L1 and TLD
+
+In the above proposal the ENS TLD and chain name coincide which may be confusing or incorrect in some cases. A more explicit approach could be to have an additional suffix for the chain name.


I totally agree with SamWilsn comment above: ERCs should be written as if they are already final. So, just stick to some particular approach instead of writing "A more explicit approach could be..."

u59149403 · 2025-04-23T00:53:31Z

@lucemans

Have a look at ENSIP-9 (defining different records for different chains)
https://docs.ens.domains/ensip/9

ENSIP-9 tries to support not only EVM chains, but also bitcoin, etc. This is good thing. But it invents its own way to refer to various chains. This is bad. New version of ENSIP-9 should be created, which refers to caip-10 ( https://chainagnostic.org/CAIPs/caip-10 ) instead. Everybody should stick to CAIP-10. See also this very good comment: https://ethereum-magicians.org/t/chain-specific-addresses/6449/28 by rekmarks

7828 name only rewrite

u59149403 · 2025-04-29T01:12:02Z

ERCS/erc-7828.md

+- The chain portion can be an ERC-7785 domain name when that standard is ready, or use solutions similar to ethereum-lists/chains in the immediate future.
+- The address portion can be either the appropriate type of address for the chain, or a domain name.
+- The address portion and the chain portion should be resolved separately.
+- Checksum hash goes over the entire address & chain, so users can't just replace a component and expect it to stay valid.


Checksum is needed for cases, when user manually types address, which does not have any intrinsic meaning for the user. For example, 0xdAC17F958D2ee523a2206206994597C13D831ec7. If the user types such address manually, then they can easily make mistake. And checksum here helps: it minimizes probability of mistake.

But if we have meaningful address, such as vitalik.eth, then we don't need checksum. Because checksum here makes typing of this address harder, not easier!

vitalik.eth#2cb81d22c001 is harder both to type and memorize than vitalik.eth. We don't have checksums in meaningful URLs, right? We type github.com to URL bar, not github.com#2cb81d22c001, right?

Okay, so, as well as I understand, ERC-7828 is designed for addresses, meaningful for humans, as opposed to CAIP-10, CAIP-50, CAIP-350 and ERC-7930. So it should not have checksums at all

Because checksum here makes typing of this address harder, not easier!

it's not necessary for users to type the checksum, the idea would be for the users to type [email protected] and the wallet to generate the checksum based on what address said name resolves to.

Okay, so, as well as I understand, ERC-7828 is designed for addresses, meaningful for humans, as opposed to CAIP-10, CAIP-50, CAIP-350 and ERC-7930. So it should not have checksums at all

I believe checksums have a place in human-readable names, since they could help prevent:

unicode glyph collision attacks (vitаlik.eth)

squatting of domains with common typos (vitslik.eth)

And they could also provide a link between addresses representing the same on-chain entity (e.g, [email protected]#FFFFFFFF might display as [email protected]#FFFFFFFF on a wallet which has trouble resolving the ENS name) which gives user the idea of the addresses potentially being the same, which would make simple failures less obscure

u59149403 · 2025-04-29T01:23:30Z

ERCS/erc-7828.md

+
+Non-evm chain
+- bc1..23@bip122:000000000019d6689c085ae165831e93#CCCCCCCC
+- alice.eth@bip122:000000000019d6689c085ae165831e93#CCCCCCCC


Where this alice.eth is resolved? Please, specify this. It it meant to be resolved on Ethereum, then I totally don't understand why in alice.eth@bip122:000000000019d6689c085ae165831e93#CCCCCCCC the alice.eth part should be resolved on Ethereum and in [email protected]#AAAAAAAA the alice.eth part should be resolved in Arbitrum Nova. In any case, all this should be specified

I tried to make this part more legible as a repository of possible name formats than a normative specification on how to resolve each one, which in the scope for later sections.

In particular, the core of this proposal is for the .eth part to determine how should the name be resolved. By using .eth, this name implies it should be resolved via ENS, and what contract to call is an ENS detail (in particular, ENS resolution always starts on ethereum mainnet, but might jump somewhere else via CCIP calls)

u59149403 · 2025-04-29T01:27:31Z

ERCS/erc-7828.md

+5. Look up the TLD (characters from the last dot up to the end of the string) of the result of step 1. For this example it's `.eth`, meaning we should attempt resolution via ENS
+6. As per ENSIP-11, convert the eip155 chainid into an ENSIP-11-specific `coinType`: `0x80000000 & 0x0000000A == 0x8000000A` [^1]
+7. Compute the namehash of the result of step 1, according to ENSIP-1.
+8. Query the ENS registry for the appropiate resolver by calling `resolver(bytes32 node)` with the result of the step above


Which ENS registry I should call? Ethereum's one or oeth's one?

in the address naming section, we specify the following:

Resolution and reverse-resolution of chain names is to be executed as defined in ENSIP-19, ENSIP-16, ENSIP-11 and ENSIP-10.

in particular (and as described in step 6) we are using ENSIP-11, which instructs resolvers to use the mainnet ENS registry

mm-zk · 2025-04-30T08:53:42Z

ERCS/erc-7828.md

+
+[ERC-7930]: ./ERC-7930.md
+[ERC-7785]: ./ERC-7785.md
+[name resolver registry]: TODO


do we have any link / draft doc for name resolver registry?

not really for now, we're planning on extending ethereum-lists/chains to contain the name resolver registry as well

mm-zk · 2025-04-30T08:54:56Z

ERCS/erc-7828.md

+##### Chain naming
+
+###### Supported CASA namespaces
+Only those explicitly listed here


you might want to mention that we want to include all the stuff from ethereum-lists/chains (otherwise the reader thinks that we will have only 5 entries here ;-)

that's a good point, my idea is to remove this list and have that information in the name resolver registry, similar to what I did on ERC-7930 with CAIP-350

mm-zk · 2025-04-30T09:30:07Z

ERCS/erc-7828.md

+- [email protected]#00000000
+
+Rollup
+- 0x12345...6789@eip155:4270#AAAAAAAA


when converting to binary format - what would be the 'chain resolver' set to in this example?
(as we have only 0x0000 (which is for .short) and 0x0001 (for .eth))

Good find. In this case in particular, you could use a v1 address, which does not include resolver information and requires the address and chainid are displayed raw.

however, it's not possible to define the address xor chainid to be displayed raw. I'll update it to add an id meaning no resolution is intended

kelemeno · 2025-04-30T16:13:25Z

ERCS/erc-7828.md

+## Motivation
+The current Ethereum address landscape is leading to an ecosystem that will have hundreds and eventually thousands of L2s that use the same address format as Ethereum mainnet. This means an address by itself is not enough information to know which chain the address is related to. This can be problematic if funds are sent to an unreachable address on the incorrect chain. From the user account it should be possible to obtain the right chain identifier (chainID) to include in a transaction. 
+
+The mapping from chain names to identifiers has, since [EIP-155](./eip-155.md), been maintained off chain using a centralized list. This solution has a few shortcomings:


Deprecating/decentralising this list has a danger, as now the chainIds of different chains could clash. Maybe it would be better to not imply that this ERC completely deprecates it.

would be better to not imply that this ERC completely deprecates it.

what wording in particular implies this standard deprecates it? My intention with this standard has always been to be a building block to eventually deprecate it, but this ERC alone is not enough to deprecate it. That's a concern of ERC-7785, with which am I not involved

nategraf

Thanks for putting this together!

nategraf · 2025-04-30T17:09:16Z

ERCS/erc-7828.md

+<raw-chain>:           := [.-:_a-zA-Z0-9]*
+<scoped-name>:         := <subdomain> . <L0-TLD>
+<L0-TLD>:              := [a-zA-Z][-a-zA-Z0-9]{0,9}
+<subdomain>:           := [a-zA-Z][-a-zA-Z0-9]*


One thing to clarify about this grammar, which I think is true based on your comment below: multiple levels of subdomains are allowed, ya? So in the user.app.eth example you have the layers of user.app.eth -> user.app -> .eth. I think this currently would not parse, if I read this right.

good find, thanks! I'll re-define it so there can be multiple submdomain levels

github-actions · 2025-05-02T00:21:01Z

The commit 1f9eb33 (as a parent of 0ee950b) contains errors.
Please inspect the Run Summary for details.

jrudolf added 8 commits November 27, 2024 00:00

Create erc-chain_specific_addresses

520176f

Update erc-chain_specific_addresses

2074bbd

Update erc-chain_specific_addresses

94a581d

Update erc-chain_specific_addresses

7db61f0

Update erc-chain_specific_addresses

d1eb6b8

Update erc-chain_specific_addresses

6595ed2

rationale update

9482704

require EIPs

ec2bd97

jrudolf requested a review from eip-review-bot as a code owner November 27, 2024 10:44

eip-review-bot changed the title ~~Add ERC: chain-specific addresses using ENS~~ Add ERC: Chain-specific addresses using ENS Nov 27, 2024

eip-review-bot enabled auto-merge (squash) November 27, 2024 10:45

eip-review-bot previously approved these changes Nov 27, 2024

View reviewed changes

github-actions bot added the w-ci label Nov 27, 2024

Rename erc-chain_specific_addresses to erc-chain_specific_addresses.md

32b8276

SamWilsn dismissed eip-review-bot’s stale review via 32b8276 November 27, 2024 14:56

github-actions bot added c-new s-draft t-erc labels Nov 27, 2024

eip-review-bot added e-consensus e-review labels Nov 27, 2024

niran reviewed Nov 27, 2024

View reviewed changes

abcoathup reviewed Nov 28, 2024

View reviewed changes

ERCS/erc-chain_specific_addresses.md Outdated Show resolved Hide resolved

abcoathup reviewed Nov 28, 2024

View reviewed changes

ERCS/erc-chain_specific_addresses.md Outdated Show resolved Hide resolved

vbuterin reviewed Nov 29, 2024

View reviewed changes

jrudolf and others added 2 commits December 2, 2024 12:48

Merge branch 'ethereum:master' into master

5e7c7c9

add EIP number

d988615

Co-authored-by: Andrew B Coathup <[email protected]>

auto-merge was automatically disabled December 2, 2024 17:50
Head branch was pushed to by a user without write access

github-actions bot removed the w-ci label Dec 2, 2024

add eth magicians URL

680bd56

0xteddybear added 4 commits April 14, 2025 17:49

fix: proofreading

f6e7bfa

non-normative parts & proofreading

c27ef1b

fix: feedback from racu

6e2f92b

chore: update authors

90a842a

SamWilsn reviewed Apr 15, 2025

View reviewed changes

0xteddybear added 2 commits April 17, 2025 12:53

chore: reference Interoperable Address ERC

46eecaf

chore: clarify ENS usage for reverse resolution

2e193e7

u59149403 reviewed Apr 20, 2025

View reviewed changes

0xteddybear and others added 3 commits April 23, 2025 13:30

chore: update front matter

37e44e0

chore: update motivation

1b68784

Merge pull request #2 from defi-wonderland/7828-name-only-rewrite

7c84d2c

7828 name only rewrite

eip-review-bot changed the title ~~Add ERC: Chain-specific addresses using ENS~~ Add ERC: Human readable names for Interoperable Addresses Apr 28, 2025

github-actions bot added w-ci and removed w-ci labels Apr 28, 2025

u59149403 reviewed Apr 29, 2025

View reviewed changes

jrudolf mentioned this pull request Apr 29, 2025

L2 Interop Working Group Call #8 - April 30, 2025 ethereum/pm#1509

Closed

0xteddybear mentioned this pull request Apr 30, 2025

New CAIP profile: interoperable address binary specification ChainAgnostic/CAIPs#350

Open

mm-zk reviewed Apr 30, 2025

View reviewed changes

kelemeno reviewed Apr 30, 2025

View reviewed changes

nategraf reviewed Apr 30, 2025

View reviewed changes

0xteddybear added 2 commits May 1, 2025 21:05

chore: typos

0a71c7a

feat: security consideration on unicode collisions

1f9eb33


		The resolution of a `address@chain` on the contrary, imposes that the left-hand resolves to an address and the right-hand to a chain identifier.

		When given a `[email protected]`, the wallet can resolve `rollup.eth` to get a chain identifier and `user.rollup.eth` to get an address. In any other case it fails.


		### L2 resolution

		In case an address is not registered on L1, but only on a L2, the resolution can be processed using [ERC-3668](./eip-3668.md) and [ERC-2544](./eip-2544.md)'s Wildcard Resolution.


		#### Note: avoiding the http gateway

		In order to avoid contacting an external http gateway, we could define the gateway to be a ENS contract on the L2. In this way a wallet operator would need to only rely on a node following the L1 and a node following the L2.


		### L1 resolution

		Ethereum Mainnet and its testnets can be resolved to their corresponding chain identifiers using a centralized list, which remains unchanged from how it works today. Other L1 registrations are out of scope for this EIP.


		### Note: clashes of L1 and TLD

		In the above proposal the ENS TLD and chain name coincide which may be confusing or incorrect in some cases. A more explicit approach could be to have an additional suffix for the chain name.

Add ERC: Human readable names for Interoperable Addresses #735

Are you sure you want to change the base?

Add ERC: Human readable names for Interoperable Addresses #735

Conversation

jrudolf commented Nov 27, 2024

eip-review-bot commented Nov 27, 2024 • edited Loading

File ERCS/erc-7828.md

eip-review-bot left a comment

Choose a reason for hiding this comment

niran Nov 27, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SamWilsn left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

u59149403 commented Apr 23, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mm-zk Apr 30, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kelemeno Apr 30, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nategraf left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented May 2, 2025

eip-review-bot commented Nov 27, 2024 •

edited

Loading

File `ERCS/erc-7828.md`

niran Nov 27, 2024 •

edited

Loading

mm-zk Apr 30, 2025 •

edited

Loading

kelemeno Apr 30, 2025 •

edited

Loading