ERC-7828: Chain-specific addresses using ENS

ERCs
1

Description:
A unified chain-specific address format that allows specifying the account as well as the chain on which that account intends to transact.

3 Likes
2

Doesn’t this assume the desired L2 ENS names like optimism.eth and arbitrum.eth are all owned by the L2s? How does this proposal deal with squatting and other potential issues for future L2s? Or maybe I missed how rollup ENS name resolution is made.

Also this part didn’t seem consistent to me:

The spec:

chain ::= <chain_id> | <L1-TLD> | <ens-name> . <L1-TLD>
user ::= <address> | <ens-subdomain>
account ::= <user>@<chain>

the note

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.

and the examples below that:

Rollup
- 0x12345...6789@chainId
- 0x12345...6789@arbitrum.eth
- alice.eth@arbitrum.eth

According to the note ens-name is a full ENS name like arbitrum.eth. Since chain can be an <ens-name> . <L1-TLD> I’d have expected the chain to be arbitrum.eth.eth. Either the example " user.app.eth is a name" is wrong (user.app is the ens-name) or the spec should not have <L1-TLD> in chain ::=

3 Likes
3

Why not adopt CAIP-10? It’s a previously existing standard (but not an EIP) that occupies the same space, and either deserves deference or an explanation in the rationale why it was dismissed.

1 Like
4

thanks for the note, and definitely agree we shouldve made a note in the ERC. The main motivation for this rather than CAIP-10 is to optimize for human-readability. In addition to what Sam mentioned here

1 Like
5

Should ERC-7828 explicitly define a rule that only L2 projects themselves should register their own ENS domains?