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?

10 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.