Description:
A unified chain-specific address format that allows specifying the account as well as the chain on which that account intends to transact.
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, andens-subdomain
that is just a segment of a name between dots. E.g.user.app.eth
is a name,user
andapp
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 ::=
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.
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