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

DAO-Wide Temp Check
1

Intro

This Temperature Check asks the ENS DAO to authorize creation of the two-character second-level domain l2.eth to be used for the L2 interop initiative around “interoperable addresses” (aka chain-specific addresses) organized by several groups across Ethereum in collaboration with the EF and the “L2 interop working group”.

Minting l2.eth (details below) will give ERC-7828 “Interoperable Addresses” a permanent home inside ENS via a future custom wildcard resolver. Today’s discussions concerns only the minting and transfer of the name.

Context

The chain-specific-address initiative is driven by two complementary standards:

  • ERC-7930 introduces a canonical binary format for (chain, address) pairs.
  • ERC-7828 layers human-readable names on top of that binary format, allowing strings such as alice.eth@rollupname.l2.eth#ABCD1234.

For ERC-7828 to work in a fully decentralized way, chain names themselves should live inside a reliable registry, such as ENS. Registering l2.eth gives the DAO a neutral namespace under which every L2 can publish its canonical name (e.g., optimism.l2.eth ⇆ chainId 10).

Read more details about how ERC-7828 and ERC-7930 changes the game for chain-specific addresses here: RFC: Universal Address Formats for Interoperability (ERC-7828 & ERC-7930).

Approach

There are two equally safe ways the DAO can register l2.eth, both already used for routine ENS maintenance:

  1. Use the DAO’s existing Controller wallet: This wallet already has permission to register .eth names, so it can claim l2.eth in a single transaction and hand it over to the multisig.
  2. Temporarily give the Owner wallet controller rights: The Owner wallet briefly grants itself permission, registers l2.eth, transfers the name to the multisig, and then removes its own permission. This keeps the long-standing Controller wallet untouched but adds one extra step.

Regardless of which path we choose, the end-state is identical:

  • A multisig chosen by the DAO becomes the sole owner of l2.eth.
  • The multisig can later “wrap” the name for fine-grained permissions, set a wildcard resolver, and manage sub-names.

For this temperature check, we focused on plan to submit a proposal that mints l2.eth and transfers it to a new multisig. The resolver design, record format and first batch of chains will come back as a separate executable proposal once the name is safely in DAO hands.

Benefits

Taking ownership of l2.eth does three very concrete things for ENS and for every wallet that relies on its service.

First, it lets the two pending standards for Interoperable Addresses move from “nice idea” to “live feature.” ERC-7930 already defines how to pack (chain, address) into bytes, and ERC-7828 defines how to turn that into text. What they both lack is a guaranteed place to resolve the chain part. l2.eth is that place.

Second, it replaces the current off-chain (GitHub) JSON list of chain names with an on-chain registry that lives at l2.eth and is controlled by the DAO. Right now, Optimism’s chain ID 10, Arbitrum One’s 42161, Base’s 8453, and hundreds of others sit in a GitHub repo that no contract can trust without manual vetting. Once optimism.l2.eth, arbitrum.l2.eth, and zksync.l2.eth are recorded under a resolver the DAO governs, any smart contract or dApp can fetch that data directly from ENS
Third, the wildcard resolver planned for *.l2.eth keeps scaling costs tiny. The DAO registers the parent once; after that, adding a new roll-up means the multisig writes a single storage slot with the chain ID.

Next Steps

If this proposal reaches rough consensus, we will:

  1. Set up the multisig: Gather DAO feedback on signer selection and threshold (details to be finalized before the executable vote).
  2. Executable proposal: Specify the exact on-chain calls for the chosen registration path and list the multisig signers.
  3. Execution: Register l2.eth, then confirm that the multisig holds the name.
  4. Resolver & records (future): The Working Group will submit a follow-up proposal that defines the wildcard resolver and seeds it with the first set of chain entries.
6 Likes
2

Overall very cool idea.

It’s past 3am where I am so will just share a quick, non-technical, but nevertheless important feedback:

“l2” is a technical term that’s not “normie” friendly. Normal people don’t care what a l2 is and shouldn’t ever need to learn.

Quick alternate suggestions that are less technical / more mainstream:

  • id.eth
  • me.eth
  • my.eth
  • go.eth

These proposed ERC-7828 identifiers are already exceptionally long which is concerning for UX. I would put priority in being normie friendly over shortness of the .eth 2ld.

Therefore, I also have some suggestions that are 3 characters long (just 1 extra character and no need for special DAO action), including a really nice one that’s soon to expire and much more friendly for normies. I’ll send you a DM on the forum to help optimize your chances of snagging it if you think it would be a nice fit.

2 Likes
3

This is a no-brainer! l2.eth is the logical next step to enhance interoperability and decentralization around chain-specific addresses. It lays a solid foundation for future decentralized registries and helps shift infrastructure away from centralized repositories.

Just a few questions regarding the implementation path and governance model to help clarify:

  • Will the signer selection process for the DAO-controlled multisig be transparent?
  • Is there a rotation policy or contingency plan in place in case a signer is compromised or loses access (basic sec ops)?
  • Will there be a formal process for how individual chains can claim their namespace under l2.eth ? (Thinking ahead on potential name collisions.)
  • Will any ongoing maintenance be required for the l2.eth infrastructure—such as managing the wildcard resolver, metadata updates, or adding new chain identifiers?

Looking forward to this proposal going up for a vote!

4 Likes
4

I’ve been following ERC-7930 and ERC-7828 closely, and excited to see this moving from a “nice idea” to “live feature.”

I think it’s very important that we replace an off-chain GitHub with an onchain registry on ENS. This is absolutely a better way to scale chain IDs for wallets and dapps. I also think that it enshrines .eth as as a symbolic root for L2s that rely on the Ethereum Mainnet for decentralization and security. Purely from a brand perspective, seeing that base is .base.eth and zkSync is .zksyc.eth further ties these projects to the broader Ethereum ecosystem.

While I understand the benefits for intents/message passing frameworks between chains that wallets and dapps will rely on, I’m a little more confused about the assumptions of who the “customer” is for 7828 as stated in the RFC: “Wallets, explorers, dapps, and any other actor whose UX consists of communicating a (chain, address) pair to a human. Any application interacting directly with end-users.”

I think this would help with an example of what it would mean for, “addresses of all chains are displayed uniformly across major explorers, wallets & dapps”

Wouldn’t wallet product and design teams still want to simplify something like alice.eth@rollupname.l2.eth#ABCD1234 or abstract it in the UI? Do you have any mock-up designs of what the desired end-state would look like in a wallet or a dapp?

1 Like
5

I support using *.l2.eth as the primary source for named chains. Seems like a great way to insert ENS into the essential stack.

7 Likes
6

Glad to see momentum on interop addresses & l2.eth feels like the right neutral namespace for that.

2 Likes
7

Also posted on Nick’s thread here: Allowing the DAO to manually issue .eth 2LDs, including 1- and 2- character ones - #11 by clowes.eth

To be clear, you want l2.eth to be owned through a multisig? I think the proposed signers on that multisig would be an important consideration as part of this temp check… Once owned, setting the resolver etc would not need to come back to the DAO as a separate executable - it would be the responsibility of the signers on that multisig…

That said, there’s an argument for the DAO wallet owning the name itself IMO.
Setting the resolver would require an executable, but realistically that shouldn’t need to be changed often. We also have the ENS Security Council providing an additional level of security coverage. Why go to the effort of establishing a new multisig?

This isn’t providing a short name to a private company with a trademark, but rather provisioning a name for utilisation as a chain data discovery mechanism. In my opinion this should be considered separately to Nick’s more generalised Temp Check. An ownership structure like that may be more palatable to delegates…

I think this is a first of its kind proposal for utilising this power for a name registration.

I’m not sure I follow your second suggestion.

This is a discoverability mechanism. Realistically it’s going to be technical implementors that use it not normies.

It is however quite a constrained term. What about Layer 3 chains? Something more generic may be more appropriate.

It would be .base.l2.eth and .zksync.l2.eth but your point still stands.

My understanding is that the intention is to standardize how the data is stored on chain such that wallet providers can fetch it and know how to read it. Then they can display it how they choose, which hopefully is user friendly…

The actual address format, I agree, is a little burdensome. But I guess that’s separate to this proposal and part of the 7828 conversation. I’m not sure that I have a suggestion for a better format.

TL;DR
I think this is a great idea. Is l2.eth the correct name?

1 Like
8

This is well said and highlights a crucial distinction.

Supporting obvious infrastructure projects like this through verifiable discoverability should be something the DAO leans into. It harnesses the power of the protocol for the good of the ecosystem.

This should be done with l2.eth, but 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). In my opinion, this is exactly the type of responsibility that should be at the core of the ENS DAO’s mission.

Note - This is a very different scenario than the thread Nick began about the DAO allowing 1 and 2 character names for other purposes. With both of these threads unfolding in parallel here in the forum, it might be easy to evaluate them in the same mental space, but I don’t believe we should.

The general thread of Allowing the DAO to manually issue .eth 2LDs, including 1- and 2- character ones should be considered separately from this proposal.

3 Likes
9

That’s a great use case we should support!

+1 @5pence.eth Also agree that the best structure would be the DAO as owner of the domain (to intervene in edge cases for such an exceptional case and important public good) and a multisig as manager (can create subdomains and change records).

As mentioned by others, the multisig composition becomes critical - ideally technical experts from L2s, wallet providers, and ENS contributors.

+1 @lightwalker.eth and @clowes.eth : Also agree “l2.eth” is too narrow. Something more generic would future-proof against L3s, sidechains, and other scaling solutions.

One detail is that wrapped domains (ERC-1155) don’t have a manager, right? Maybe that can be figured out at the resolver level (where the multisig has some type of admin role). Or this domain can be issued as a legacy domain (ERC-712).

10

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

11

As one of the original authors of ERC-7828, I’m very supportive of this. This would enshrine ENS as being core infrastructure of Ethereum and connecting all L2s. The list of chain names should not live on github, but should be onchain and ENS is the perfect usecase for housing that.

8 Likes
12

Yes, I assumed, but that other thread is becoming a conversation about the pricing strategy, ownership rights, and selection processes - all good topics for names that are issued to external parties with full ownership rights, but not relevant to this case if the DAO retains ownership.

Another concern is that the other thread contains a lot of discussion around a referer field:

I don’t know that this is uncontroversial as yet, but it’s certainly a separate subject. This has come up several times in the last few years, and it’s never had enough support to move forward.

My comment was trying to separate this clean scenario of registering l2.eth from those more nebulous discussions which still have unanswered questions.

13

We’ll share a list of proposed signers so the ENS community can give feedback.

The DAO could retain ultimate control via a Safe module, giving it override rights if needed.

The process will follow something similar to how gh chainlist works today.

l2.eth will have its own custom resolver. We’re working on the spec and will share more once it’s defined.

Will provide more details on how we envision this on the next spec

1 Like
14

Format like alice.eth@rollupname.l2.eth#ABCD1234 will resolve as alice.eth@rollup.

15

Format like alice.eth@rollupname.l2.eth#ABCD1234 will resolve as alice.eth@rollup

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.

For L3s, each resolver could either live within its corresponding L2, or follow a pattern like l3name.l2.eth. That said, we’re open to reconsidering if this format feels too confusing, open to thoughts or alternatives here

1 Like
16

I like that.

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

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?

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 :grimacing:

17

Frontrunning @0xtiti to surface the below:

The most recent commits pertain to this discussion. Worth a look.

For what its worth @0xtiti, @jrudolf and others involved in the interop effort are doing a great job pushing this forward.

2 Likes