[Temp Check] l2.eth to Enable Chain-Specific Addresses

[clowes.eth]

@5pence.eth

it should be done by the DAO owning the name and only assigning management rights to the multisig that @jrudolf proposed (this would allow the multisig to manage subnames under l2.eth while the ENS DAO retains ultimate ownership and the ability to intervene if necessary

I like that.

@nick.eth

I don’t follow. This and zk.eth were exactly the scenarios I had in mind when writing that proposal.

I think this (l2.eth) and zk.eth are different unless the intention is that zk.eth similarly is an ‘infrastructure’ name.

@0xtiti

l2.eth is the most suitable and available option we’ve found so far (chain.eth isn’t available). An address like alice.eth@rollupname.l2.eth#ABCD1234 would be abstracted to alice.eth@rollupname, leveraging 7828 with no TLD for resolving l2.eth.

Could you clarify on this further please? In this example rollupname.l2.eth is resolved to get data about that chain, and then the address for alice.eth is resolved for that chain?

@0xtiti

For L3s, each resolver could either live within its corresponding L2, or follow a pattern like l3name.l2.eth

Do you mean like ape.arbitrum.l2.eth for example? Where because ape finalizes against Arbitrum its chaindata is surfaced through an additional subdomain level? Works for me.

Although… what about Solana