ENS Subdomains [Renewal Rugability], Pricing Methods (Rental Pricing Options)

🌱 ENS Ecosystem Ecosystem Discussion
1

Q: How is the “subdomain renting” going to work in the subdomain wrapper?
(People are excited with different ideas on how they will rent their subdomains.)

Will rentals be differentiable by:

  1. Name length (like ENS does), and/or
  2. will users be able to define certain “lists of words/library”,
    …which they can then “rent at a higher cost”?

Everyone is speculating about the renting structure,
and I just want to make sure users expectations are matching.
Otherwise, there may be some chaos in features & benefits,
…verses the expectations from the ENS Community & dWeb Marketplace?

As public goods,
ENS names are rented, not owned. That is how I see it.
When someone pays a renewal fee, then we see that as renting.

For ENS Subdomains,
few users will use the wrapper if renting options do not exist :confused:

People will demand control of subdomain-pricing,
…and there are several different ways users will want to price rentals.

  • Price based on character length
  • Price based on specific word list/library
  • Price based on credits or batches of credits

Otherwise, without subdomain pricing,
the “Official ENS Subdomain-Wrapper” will be Temp-DOA (until those features exist),
because of the many creative-entrepreneurial use cases, which users are imagining in their plans.

NOTE: If need be, we can pull/draw hard data for this hypothesis via the community.

If someone owns a good name, ie: newyorkcity.eth
And they want to sell subdomains, ie:

  • gary.newyorkcity.eth
  • nick.newyorkcity.eth
  • hotels.newyorkcity.eth

The domain owner may want to [in most cases] issue pricing based on a “renewal system”,
similarly, (but different in many cases), to how “ENS domains” are rented/renewed.

Just like how we believe ENS Names should have renewal fees
(as most have indicated in the ENS Constitution),

We carry this belief to ENS-Subdomains,
where we also believe ENS-Subdomains should have renewals, in the same/similar ways.

I can report here, IMO–based on conversations I am hearing and my personal views,
Many user, including myself, will not use the Wrapper if we can not issue rentals, for most ENS names.

I can not get information from Devs or Team, about the Wrapper (as they are focused).
There is no indication, yet, that the Wrapper will/willnot have renewal-pricing features.

This is why we are asking this now, and seeking clarity before the Contract is complete.

If there is a question to market demand, that should be discovered BEFORE the contract is complete,
(and not after we announce it is complete), or then the market may be disappointed, unfortunately,
…especially at this critical stage of ENS subdomain-development.

I encourage more discussion & research.

9 Likes
2

Why should renting be part of the wrapper contract?

Keep it simple and separate the responsibilities of contracts. Use the ENS NameWrapper contract for its intended purpose, to wrap names into ERC-1155 NFTs.

Then you can use an existing NFT lending protocol/contract to lend it out. Right? Why bring that complexity into the name wrapper?

2 Likes
3

Technically,
the pricing-rules aren’t directly part of the same wrapper-contract,
but, the registrar is an important piece of the subdomain-system, upon launch.

4 Likes
4

I think that makes more sense, so the overall set of contracts that comprise the “subdomain system” could certainly include the ability to also lend out subdomains after you’ve created them. Do you think ENS should roll its own contract on that, or use something existing? What lending protocols/contracts for NFTs have you used in the past?

8 Likes
5

I’m following this closely, as I intend to market subdomains. My pricing will be set, and as I sell them, I will also extend the tld registration by one year.

1 Like
6

Trying to understand the new official wrapper-contract code;
Seems like we may not have “sovereign renewals” for sub-domains,
…which would be sad, foreseeable, and a negative factor for the wrapper. TBD.

7

Yeah, the name wrapper is not a subdomain registrar. It will merely enable such registrars to be more easily created.

In your own subdomain registrar, you will be able to configure registration/renewal with whatever rules you want.

8

Just wait until users discover:
"any/all renewals" will be ruggable :sweat_smile:
This sets the official ENS name-wrapper up for failure, imo.

9

I don’t know what you mean by that. Can you explain?

The fuse system will be able to ensure that the parent owner will not be able to delete/replace subdomain, until the expiry of the fuse.

What exactly is “ruggable” here

=====

Edit: Are you talking about how people can renew their own .eth 2LDs at any time? And you want to see that same thing for subdomains?

If so, that will still be possible I believe, but that logic would reside in the subdomain registrar, not this wrapper contract.

Your subdomain registrar can be setup with a renew function callable by the owner of the subdomain (or anyone, if you wish). The same way that the ETHRegistrarController has a renew function callable by the owner of a .eth name (or anyone else).

It’s up to the parent owner to decide whether they want to allow that or not.

It’s also worth reminding everyone that the NameWrapper is the first important step here, but it’s not everything. Subdomain registrars are separate, and I imagine there will be a variety of different such registrar contracts to choose from, each with their own parameters and levels of sovereignty, etc.

10

After release,
when someone uses the official ENS name wrapper,
and they sell/rent a subdomain (for one year), of their 2LD,
…even with “all of the right” fuses of the 2LD are burnt…
then:
Q: will it be possible for the “renew function”
(of the subdomain) to be removed by the 2LD owner?

The “sovereign subdomains” will exist,
…but “sovereign renewals” may-or-may not?

How will end users know if the “renewal option” can be hidden/removed or not?

11

That will depend entirely on the subdomain registrar contract(s) that you have setup for your own domain.

As an example, the ETHRegistrarController determines how registrations and renewals happen for .eth 2LDs. The ENS DAO can vote to change parameters for registrations/renewals, like the fee structure, etc.

Case in point, there’s a discussion here about changing the minimum registration duration (and possibly also the minimum renewal duration): https://discuss.ens.domains/t/a-suggestion-for-future-min-registration-duration-and-grace-period/12396/6

The same will apply to your own subdomain registrar/controller. You could set it up so that everything is completely locked and cannot be changed by anyone in the world. You could delegate that power to a multisig account with several trusted parties in the ENS domainer community. You could even create a whole DAO around it, if you wanted to.

12

While you are correct,
this is NOT what people are expecting.

  • Expectations = Reality.
  • Perception = 9/10th of Reality.

Congrats to us?
We are about to create a vacuum,
which is going to cause chaos & confusion.

Being this far into the process, & not caring about market expectations, is bad business development; and it is bad for users, too, (whom will be confused, frustrated, and will make decisions because they don’t have all the needed info.).

IMO, This is a dis-service for the official wrapper, and the community,
which will result in an increased rate of forking from the official contracts,
in addition to users being hurt by an absence of info from technical builders.

More information is needed BEFORE we are
this far into releasing a major process & infrastructure.

13

I see a lot of words there, but I’m having trouble understanding what your issue is.

What “disservice” are you talking about? The Name Wrapper is an excellent and much needed first step.

I know you want features A, B, C, D, E to all be here yesterday. Today A is shipping. B and the rest will come.

1 Like
14

lol, yes, I want the very subtle feature of,
“users not getting scammed by the official ENS wrapper contract”, via negative-unintended usage.

If this contract allows users to rent-subdomains,
and also allows the 2LD owner to remove the renewal-option,
then this is not a simple “feature” request–This is a Critical Alert.

The Core team has not shared any of this info with the community.
…We are just told that the wrapper is to be done soon :tm:

  • There is no community discussion I see of the “subdomain registrar contract”,
    which will be needed-and-required to setup for the users’ own domains, properly.

  • There is zero communication that users will be buying ruggable rented-subdomains,
    which will be ruggable (when renewable is not-possible) right out-of-the-box,
    (…if those users are not identifying the right “subdomain registrar contract”).

Questions:

  1. When will there be communication to the ENS-Community
    that we need to start building “subdomain registrar contracts”?

  2. When will there be communication to the ENS-Community
    [that they if they don’t use the right “subdomain registrar contracts”, then]
    …it will be possible for the ENS Subdomains to be “taken away” from them,
    (via the 2LD-owner possible “removing their ability to renew the subdomains”?

15

Nothing is “ruggable” here.

A customer purchases a subdomain for X amount of time. When the subdomain is registered and wrapped, that expiry (and appropriate fuses) is set. During that agreed-upon time between the customer and parent owner, that subdomain will not be able to be “rugged” whatsoever.

If the parent owner wishes to, they could also allow customers to extend that expiry date at any time.

Or, if you’d like people to be able to register a subdomain basically forever, I believe you’d just set the expiry to the maximum value, something like 580 billion years in the future. Edit: Actually that’s wrong I think, the expiry can’t be later than the 2LD expiry. So for “forever” you’d set the expiry to 0, I think?

It’s all up to the owner of the parent domain and what they want or don’t want to do with their name. There are a great many people in the ENS community, and I would wager that not all of them want to be bound to the same registration/renewal rules that you personally think are important.

There are plenty of use-cases besides reselling/speculation as well. For example, maybe you can use subdomains for your company employee roster or hired contractors. In cases like those, it probably makes sense to not burn all fuses, and leave some control with the owners of the actual company.

Nobody is stopping any 2LD owner from allowing renewals, or not allowing renewals. It’s their name, they have the freedom to set whatever rules they want.

======

With all that said, your questions are definitely good ones.

The core team is working on a canonical subdomain registrar:

That will (I’m guessing) be integrated into the new v3 manager app at some point as well.

However, I don’t know what features / rules that registrar will have. I would guess almost all of it would be able to be tweaked and dialed by the 2LD parent owner though. Perhaps you, @nick.eth, @jefflau.eth and others can get on a twitter space sometime and hash all of this out, ask questions, etc. I think it’d be a good idea for the core team to get feedback on what should go into that canonical subdomain registrar.

2 Likes
16

Being Technically Correct < User Expectations.

I hope being correct is enough, because this is not what the public wants.
Your technical understand is an anthesis of our communities expectations.

Actually, I am a bit shocked at the views.
When a users buys a subdomain, they will be expecting they will be able to renew it forever.
It is shocking to think, that the devs do not think, that this is a major issue for end-users.
Your solutions may be errors-in-thinking about the problems or solutions of end-users.

I’ve not seen collaboration, or cross-communication, or surveying of subdomain users.
This all reinforces that the perception that the devs are not understanding the market.

I predict this will be damaging for the official wrapper, and will accelerate division.
If dev-vs-user ideas live in different worlds, then evolution will diverge greatly.

I do wish the devs would had/will be inclusive of & would listen to actual users.
For the UX, the fact is that subdomain-rentals are ruggable if = not renewable.

Now, there is a lot of education that will be required; and even more to build.

17

Again, they will be able to renew it forever, if the parent domain owner sets it up that way.

1 Like
18

Right, the problem is not for subdomains that are transferred for “forever”.
The problem’s only for “subdomains renewals” that are “less than a lifetime”.

1 Like
19

No, it’s not a problem there either. Again, the parent domain owner will be able to set up their domain such that subdomains will be able to be renewed/extended by the customer (or anyone, if they want).

20

Will it 1. be possible for the 2LD-owner to:
“remove the ability (for the subdomain) to renew”?
…2. is this how the official wrapper contract will work?

1 Like