Allowing the DAO to manually issue .eth 2LDs, including 1- and 2- character ones

DAO-Wide Temp Check
1

We (Labs) are currently working on a new revision of the ENSv1 .eth Registrar Controller contract. This is required in order to support the new cross-chain reverse resolution functionality, so that users can optionally set a default reverse record when they register a name, and the plan is to roll it out for DAO approval soon, well ahead of ENS v2.

While we’re modifying the registrar controller, we’re taking the opportunity to add an optional referer field as well; this is a very low impact change and opens the possibility of building offchain referral programs using the data it can collect. I believe this will be an uncontroversial change.

I’d also like to moot another change we’re planning to propose to the DAO, however, and get some feedback on how people feel about it. We’d like to add a function that allows the DAO to register a name directly (via an executable proposal). Registrations in this manner would not require payment, and would also bypass the minimum length check. There are a few reasons I believe this is a valuable improvement:

  1. It would allow the DAO to register special-purpose names for arbitrary time periods, where they’re useful for, eg, naming critical infrastructure. For example, ens.eth could be renewed out to 1000 years or more to ensure there’s no risk of it ever expiring.
  2. The DAO could more easily reclaim names from premium that are useful for DAO infrastructure or otherwise important to ENS. For example, eth.eth is currently owned by Virgil Griffith, who has no access to the wallet it is owned by. It will soon expire and the DAO could use this functionality to register it and reserve it for ENS operations.
  3. Individual proposals for 1- and 2- character .eth 2LDs could be entertained by the DAO. For example, l2.eth has been suggested as a potential namespace that could be used for naming L2s in an interoperable fashion, and zk.eth may be of use to the ZKEmail team for defining a namespace for their ‘email wallet’ functionality.

Aside from the obvious benefits of this functionality, there’s two reasons I believe this should be uncontroversial:

  1. Because revenue from registrations and renewals go directly to the DAO, the DAO can already register or renew names for arbitrary periods at zero cost to it. A few days after eth.eth goes into the premum period, the DAO could register it at a nominal cost of $10M, far exceeding any other potential buyers, simply by passing an executable proposal that buys it with funds that then go straight back into the treasury. This mechanism removes the accounting headache of the DAO paying itself large sums of money.
  2. Any registrations and renewals (including 1- and 2- character names) would have to be individually approved as part of an executable vote, so controversial proposals can be decided on a case-by-case basis.

For now I’m not proposing to build in any way of delegating the ability to create 1- and 2- character 2LDs to a sub-group of the DAO, though this could be considered for ENSv2 or future revisions of the contract depending on the success of this change.

Thoughts?

11 Likes
2

ENSv1 Referral Programs

Love the prospect of a new .eth Registrar Controller that would include an optional referrer field :rocket:

We’ve previously implemented contracts that wrap the existing .eth Registrar Controllers. Based on that testing, the incremental gas costs for implementing referral functionality in this way on mainnet were too high. It didn’t help that the cost of gas was much higher on average at that time. However, I appreciate that this strategy being proposed is different as it would implement directly within a new .eth Registrar Controller rather than a wrapper contract. Approximately what incremental gas cost do you anticipate? Best to avoid a situation where, for example, a registrant who is being referred pays incremental gas costs of more than $1 to provide a $1 referral reward. That wouldn’t make economic sense.

Additionally, is it correct to assume:

  1. The optional referrer field will take as input the address of the referrer wishing to be credited and will be permissionless.
  2. If the registration is successful and a referrer is defined, an event will be emitted enabling indexers to attribute the referral.
  3. It will be possible to track referrers for both registrations and renewals.
  4. The average incremental gas fees paid by a registrant (or account making a renewal) to give attribution to a referrer are expected to be trivial (ex: below $0.10).
  5. That the new .eth Registrar Controller will make no consideration of any financial referral program rewards. Instead any financial reward scheme would be left to a separate exercise.

As part of our SPP2 proposal, NameHash Labs has committed to $50,000 in reward funding for ENSv2 Referral Programs. The plan there has assumed we would need to wait for ENSv2 to go live first, but if the there’s a good opportunity for this to go live within ENSv1 (such as where the 5 assumptions above are true) that would be fantastic :star:

1- and 2- character .eth 2LDs

I also love this prospect, but have some alternative suggestions:

  1. DAO revenues need more attention. For example, please see the latest quarterly financial report from Limes. This reflects an ENS DAO revenue from from Q1 2024 to Q1 2025 dropping from $8.1m to $4.9m. This drop is highly concerning and we should use opportunities like this to support stabilizing DAO revenues.
    1. A quick suggestion might be: $10,000 / year for a 2-character name and $100,000 / year for a 1-character name. These short names are luxuries in short supply. I expect there’s a market of people who want to make a social flex with these names. For example, consider the phenomena with digits, etc.
    2. Consideration might also be given to requiring a minimum 1+ year registration period on any 1 or 2 character name. This would scare away most squatters.
    3. As you explained, if the DAO wishes to reserve any 1 or 2 character name for special purposes (x.eth, fb.eth, l2.eth, zk.eth, etc…), the DAO can register and pay for that themselves with a net 0 financial impact excluding trivial gas costs. For the accounting question, will leave that to the experts on that subject.
    4. I’m fully aware the DAO does not have the objective to maximize revenues. This suggestion doesn’t have a goal of maximizing revenues, but rather stabilizing revenues that have been collapsing such that the mission of ENS retains a healthy runway.

The DAO might potentially earn several million a year (and restore revenues back to Q1 2024 levels) under this scheme. If we’re lucky, maybe it could completely or substantially finance the Service Provider Program that funds so many enhancements to the ENS protocol and ecosystem.

4 Likes
3

Thanks for sharing this, Nick. I think enabling the DAO to directly register .eth names—especially for key infrastructure and rare 1- or 2-character domains—could be a powerful tool when used responsibly. It makes sense for cases like reclaiming eth.eth or securing ens.eth for long-term stability.

That said, I think we should be mindful of governance risks. Without clear guidelines or a framework for evaluating these registrations, we could see 1. proposal spam, 2. perceived favoritism, or 3. name hoarding over time. I could expand upon all of these. I suggest we pair this change with a transparent policy or lightweight review process, so we preserve community trust and avoid misuse.

Overall, I support the direction—especially as a way to future-proof ENS—but I’d like to see some checks in place to keep things fair, accountable, and ecosystem-focused (for everyone that will potentially leverage or currently uses ENS).

PS: In terms of the potential “referrer system”, this is very exciting…I have long said an ENS/.eth referrer system is very important for ENS protocol, and a critical component for neutral, sovereign, and decentralized marketing.

2 Likes
4

This is not a good idea, why does ENS need special privileges? This is akin to a centralized authority giving itself special privileges. Are you at some point going to change the contracts to bar/take away names already owned/registered by others? This is a slippery slope. I don’t think this should be placed in the code as proposed. I say this respectfully!

5

I don’t have hard numbers, but given all it does is take an extra 32-byte referer field in calldata, and then log it in an event, it should be on the order of 256 gas for the extra calldata and 256 gas for the log data, for a total of ~512 gas, plus some overhead for expanding memory and passing it around. I would expect it to be less than 768 gas total. At current prices that’s about $0.02 by my math.

The referer is simply a bytes32 that isn’t interpreted by the controller contract, merely logged unmodified. It’ll be up to referral programs to define semantics for the field and for frontends to implement it. Both registrations and renewals are supported.

We’re not attempting to implement any general-purpose issuance of 1- and 2- character 2LDs with this change - this change would only allow manual issuance of these domains directly by the DAO on a one-off basis. This doesn’t preclude implementing a general purpose pricing scheme for them as well, but doing so is likely to be complex and is well outside the scope of this current change.

I also think there’s a compelling argument for the DAO to support individual 2-character TLDs such as the examples of ‘l2.eth’ and ‘zk.eth’ on a non-financial basis, and don’t think we should put those on hold while deciding on a general-purpose program for short 2LDs.

This is impossible by design.

4 Likes
6

Quickly adding my 2c: i’m in favor of this change, thanks Nick for writing this up! Though ofc there are legitimate concerns/edge cases we should think through, I believe there is significant value in unlocking this. For example, as part of the EF’s work on L2 interop and chain-specific addresses, it would be extremely valuable for us to leverage address formats such as “alice.eth@your-favorite-chain.l2.eth”. I’ve created a 2nd temp check here: [Temp Check] l2.eth to Enable Chain-Specific Addresses

1 Like
7

Excellent :white_check_mark: This would resolve concerns on the economics.

Also sounds great :white_check_mark: Nice design.

If the DAO manually issues 1- or 2- character .eth 2LDs:

  1. Would the DAO be delegating full ownership of these names to independent owners? Perhaps the DAO should retain ownership but the manager role might be delegated under terms that the DAO retains the right to fully reclaim all use of the name at any time or under a set of conditions.
  2. If full ownership is delegated outside the DAO, do you see the issuance of these names being an eternal ownership delegation, indefinite, or for a predefined finite term? I understand the proposal is that only the DAO could issue these names, but who would have the power to renew them, and if so, at what pricing?

If this moves ahead, suggest conservatism on how expectations are set for the delegated ownership of any 1 or 2 character .eth 2LDs. Ex: none issued by the DAO for a duration greater than 1-year, and (if a general purpose pricing scheme for these names is to be handled separately) to also retain the sole ability to renew these names within the DAO. In other words, if the DAO doesn’t proactively decide to renew these specially issued names within another year, then it seems fair to assume the way they are being used isn’t creating sufficient value and it’s best to see if there’s another higher value use for those names.

A name that’s creating strategic value for ENS can be extended, but if special names fall into disuse indefinitely by an owner outside of the DAO, hopefully expiration comes soon after.

I’m worried about the DAO getting into a situation where we “bless” a subname project such as l2.eth (just a theoretical example, not picking on anyone specifically here!) under this program, and then get indefinitely tied into supporting it across time to avoid some number of end-users from being impacted due to the DAO not indefinitely extending a special / free issuance of the name.

Agreed that a general purpose pricing scheme is a distinct topic. At the same time, genuinely curious where you see the key complexities in a general purpose pricing scheme?

Stabilizing DAO finances is a crucial need and I’m confident a nice execution on this would contribute millions in incremental revenue for the ENS DAO per year. Across time, this quickly adds up!

Our team has a packed roadmap of milestones to ship under SPP2 and under time pressure with recruitment. The work already committed there needs to take priority, and want to be cautious about overextending ourselves, but if we could find the bandwidth, I would be eager for NameHash Labs to help coordinate general purpose availability of 1- and 2- character .eth 2LDs to help boost DAO revenues. Love the ROI potential for ENS :rocket:

1 Like
8

This could be decided on a case-by-case basis.

Only the DAO would be able to renew the names, too. I think the expectation would be that it’d be granted for a reasonable period of time and the DAO would vote to renew it if necessary.

I think this depends enormously on the use-case. For ‘l2.eth’, for example, it is likely only useful if it’s a durable identifier (eg, registered effectively indefinitely). The outlook would be quite different for a company proposing to pay the DAO for a 2LD they would then use on a for-profit basis.

My own opinion is that we should avoid using this new power for general-purpose short subnames, and reserve it only for infrastructure projects such as l2.eth and zk.eth, at least in the short term.

Simply that such short names are in very limited supply, so pricing them correctly is difficult. A blanket pricing strategy based on length is unlikely to be successful, and some kind of auction mechanism is likely to be desirable for initial issuance as well.

2 Likes
9

That’s disgusting.
If you concern about the l2.eth, then why you didn’t grab the web3.eth and layer2.eth for this kind of purposes?
And if you really care about the project zk so you want to make reservation of zk.eth to zk, then you should also grab polygon.eth, scroll.eth, unichain.eth, stark.eth, starknet.eth and all other layer2 chains.

You just want to control all valuable IDs, that’s all.

It’s sick, we should go to the .box and ud.me.

10

Supportive.

Would this remain possible post namechain launch? Any second order affects we should consider as it relates to namechain and migration?

11

Is this because v2 is a long way off, or because v1 support will always be necessary, and these are important changes?

What would this look like? msg.sender = specific address = no cost, can pass in arbitrary registration length, done?

My immediate gut reaction to this was no. The eth.eth situation is suboptimal, but there is a lot of subjectivity to this. The DAO in principle can do this already with an accounting exercise, but the optics are really important here IMO. I don’t think a smart contract method should allow any group to have preferential access to expiring names.

Yes but.

First thing that came to mind was gTLD Sunrise periods. I think your zk.eth example highlights the obvious concern here. Why should ZK Email get zk.eth over ZK Sync (as an example)? There needs to be a process here. I don’t think you were suggesting that there would not be a process, but it does need further serious discussion/consideration IMO.

But adds an optics headache IMO.

Hmm. Are you thinking, using zk.eth as an example, that potential applicants express interest/submit a proposal and then delegates vote to choose who gets it?

I guess this crosses over to the various legal conversations going on but I imagine that if the DAO allocates a name to an entity, and another entity has an abundance of trademarks on that acronym there could be legal surface area because delegates have actively assigned a name rather than leaving it to the system.

This is an example where IMO the DAO needs to define what it wants/needs - clearly Namehash resource has been inefficiently used (through no fault of their own) here because of a lack of clarity on if we want a referral program and who is going to do it.

And this of course. I’m averse to these changes going to proposal until it is clarified who is doing the referral programs. We’ve just given Namehash lots of money to do this…?? :man_shrugging:

TBH I am more aligned with this approach because it is rules based rather than opinionated.

But also most corporate boards XD.

Agreed but we need to take the time to answer the high level questions. If we assign l2.eth to the interop effort they need the confidence that there are no take backs. We also need the clarity that nothing is going to cause us to want to take it back, e.g. legal surface area.

This definitely needs clarity because @jrudolf would probably be annoyed if the DAO broke interop by changing its mind :expressionless:

Same issue.

This is both the pro and the con, and exactly the reason we need to do this right or not at all.

Don’t spread yourselves too thin.

Yes. Given this, I think these two scenarios should be considered separately.

Yes ! x100

Now that the DAO is better resourced we could research ways of appropriately auctioning names learning from the experiences of the 2017 Vickrey auctions…

1 Like
12

If this goes ahead, we’d definitely enable the same functionality in v2.

We’re proposing the new controller now in order to enable setting primary names for chains other than Ethereum, a feature that is ready to launch. These other features are easy to roll into an update as they’re only a few lines of code; the main overhead is deploying a new controller at all.

Pretty much! You can see the PR here, which also includes the changes to facilitate primary name setting: feat: new controller by TateB · Pull Request #438 · ensdomains/ens-contracts · GitHub

This is available as a side-effect of allowing zero-cost renewals and registrations for the DAO. We could deliberately block it, by requiring the DAO pay itself, or by prohibiting it from being used on names in the premium period, but it honestly seems pointless, since the DAO can still do those things by paying itself anyway.

Right now this proposal makes it technically possible for the DAO to issue shorter names; it doesn’t require the DAO to adopt any particular practice on issuing them (or to issue any at all). It’s entirely possible for the DAO to agree in principle that it wants the capability, and then decline to do anything with it.

Personally, in the case of zk.eth and l2.eth, I think it’s acceptable that we entertain a proposal from the parties concerned, with a reasonable notice period for objections or competing proposals, and then decide collectively whether to issue it or not. But as I outlined above, approving the ability to issue short 2LDs is separate from any decision on how or even whether to do it.

1 Like
13

:+1:

I think that can is the crucial word here - the DAO can, but hasn’t. The longer that is the case the more confidence it instills that we wont.

That said, having reviewed the constitution doing this wouldn’t violate any defined expectations. I guess it gets complicated if we decide company X deserves a name that is in premium so buy it for them for $1M (actually $0) but Company Y were ready and waiting to pay $900k real dollars for it.

But I guess thats the point of a Temp Check - to highlight the tradeoffs and discern if delegates are OK with them. I am, as long as there is process.

Yeh, it’s just a classic economic allocation issue. Namely, if we allocate zk.eth now we can’t easily reallocate it (whilst maintaining the assumed immutability of ownership) down the line if another entity that would use it subjectively better appeared once ENS is more mainstream.

But this is not a new problem. It’s the same issue the original Vickrey auctions sought to avoid. Sadly, I don’t have a solution either :confused:

2 Likes
14

This all makes a lot of sense. The referrer field seems like a great idea.

On the DAO registration function—totally support the idea. As a registry operator, I can say it’s standard to have some kind of “back door” to reserve names. ICANN allows us to reserve up to 100 names for operational use, and something like that might make sense here too.

Only real concern would be making sure it’s not used in a way that lets individuals profit. The fact that everything would require an executable vote is a solid check.

15

When this has come up in the past, the concerns were around preserving personal privacy in blockchain tech, because these types of trails can’t ever be erased, modified, or hidden.

If ENS serves as foundational identity infrastructure for Web3, prioritizing the user’s privacy into the future could be really important.

I’m sure there are ways we could do this safely if it needs to be done, but since it would happen without the user’s consent we should be really thoughtful.

1 Like
16

Having thought about this further, I feel as though registerWithoutPayment should be implemented within a separate controller authorised on the BaseRegistrarImplementation.

This would maintain a clear separation of concerns whilst making registrations through this alternative path more easily auditable.

It also means that if the DAO changes its positioning down the line this functionality can be removed more easily.

Ping: @nick.eth @taytems

17

We discussed this internally, and you’re right, that would be a simpler design. But we can go one step further and simply enable the DAO as a controller directly. And that can wait until the first proposal that needs it, too.

1 Like
18

Good point.

Only downside is that directly interfacing with the BaseRegistrarImplementation from the DAO Wallet directly would only emit NameRegistered events with the token ID.

event NameRegistered(
    uint256 indexed id,
    address indexed owner,
    uint256 expires
);

A separate controller would allow us to surface more information in events and would make it more transparent to external observers when/how the DAO is using its new power.

19


pol.eth

gm frens,

This is my first time posting on the forum despite being an active ens community member on ct since 2021. So please be nice :smile:

Why did I decide to post on this matter?

I think this is a very important topic that the ens community has been looking forward to for years.

If this passes without the ENS community having talked about it on twitter, this will have very bad consequences on ENS DAO reputation. The ens community is mostly on twitter. The percentage of the community active on the forum is epsilon.

The ENS DAO should not interfere with name ownership. Name ownership shall not be infringed can also be, and should be, interpreted as: “The ENS DAO won’t register names and won’t privilege a person or organization at the detriment of others”.

I agree with clowes.eth on this. Just because the DAO can already register names for free doesn’t mean it’s fine and that it should do it. This would be perceived so badly by the community.

zk.eth and l2.eth are top 10 .eth names that can bring a lot of revenue for the dao treasury AND bring a lot of eyes and new users to ens (major dns domains sales make the headlines and it won’t be different for ens)

I can see zk.eth and l2.eth selling for millions of united states dollarinos. The DAO and Labs team should not underestimate the impact of huge sales on adoption. Tech alone doesn’t win, human emotions play a considerable role. And money has been always charged, over human history, with a lot of human emotions.

Why would the DAO need eth.eth? This is a collector item that should belong to the collector who wants it the most and is ready to pay the most for it.

The community waited years for this. Let’s not ruin it by suggesting that it would be normal for the DAO to register the best names.

No one deserves to own zk.eth more than the person willing to pay the most for it. And if you want it but can’t afford it you can use zkm.eth, zk.xyz, zk.us or zk.ens.eth.

As for ens.eth, the DAO should just renew it with treasury fund and keep the accounting headache for the accountants :smile:

20

At this point our intention is to not include any functionality specific to registering names without payment, or registering short names, in the upcoming update.

That is not at all what that clause of the constitution means. Nobody’s ownership is being infringed if the DAO registers a 2-character name that’s not available to anyone else.

The current owner of eth.eth wants to transfer it to the DAO, he doesn’t want to sell it to a collector. Unfortunately he is not presently in control of his credentials.

Since this recently got extended by someone, it’s academic in any case.

1 Like