A suggestion for future MIN_REGISTRATION_DURATION and GRACE_PERIOD

Recently, ENS registration ushered in the crazy growth, but there are many friends found that many names are only registered for about a month, especially those 3-character names. Let’s take a look at what happens if these temporary registrations expire:

  1. Go through a short normal period, say 28 days
  2. There will be a 90-day grace period first
  3. Then there is a 21-day premium period

That means they will be affected for at least 28 + 90 + 21 = 139 days before returning to normal. This is very unfriendly to users who want to use ENS normally.

With EP9, the premium period mechanism has been well addressed. Since MIN_REGISTRATION_DURATION and GRACE_PERIOD have been written into the ETHRegistrarController and BaseRegistrar contracts as constants. So, we know that it is very difficult to change this situation.

However, if these two contracts need to be replaced in the future, we feel that the values of MIN_REGISTRATION_DURATION and GRACE_PERIOD should be improved. Such as:

  1. Set MIN_REGISTRATION_DURATION to at least one year.
  2. Let GRACE_PERIOD vary within a certain range according to the length of the registration period, so that users who have used the same name for a long time can use it more confidently.

The above are just some simple ideas, thanks to the following two friends for bringing them up in our chat.

top.eth
重力加速度.eth

6 Likes

I am in favor of raising the the minimum registration period for this reason.

This might be calculation heavy, but I would support this as long as the max grace period caps out at 90d for one year. A linear relationship would be sufficient.

Linear Grace Period

Years Registered Length of Grace Period
2 years 90d
1 year 90d
6 months 45d
3 Likes

We’re working on a suite of contract upgrades that includes a new version of the controller, so we could certainly integrate this change. The grace period is baked into the registrar, though, and can’t be changed.

4 Likes

Yes, that is probably what we mean. :handshake:

Looks like there will be some new features in the new controller, I look forward to it.

1 Like

I’d like to continue this conversation, at least for increasing the minimum registration period in the registrar controller (to 1 year).

I’m not sure this needs to go through the full proposal process because it can just be rolled into the upcoming proposals that @nick.eth and the core team will make for contract upgrades.

But I’d still like to get a temp check on this just in case:


What should the minimum registration duration be for the ETH Registrar Controller?

  • 28 days (the current minimum, no changes)
  • 1 year
  • Other (specify in replies)

0 voters


To clarify, this will only affect .eth name registrations. This will not affect renewals/extensions, as those can be for any duration. You can renew/extend a name for 1 month, 1 day, 1 second even.

3 Likes

I think one of the benefits of .eth domains is that they are more flexible than DNS, including that they can be registered for fractional years.

A few reasons why renewing for less than a year is useful include: if a domain expires and then the owner wants to give it to someone, they can renew for only a month, and then gift it to someone who can then register for a longer period of time; it makes it cheaper to register domains to give to people to onboard them to .eth, if they don’t like the domain, it can just expire; .eth domains could be used for temporary user names for a conferences or events, for example, wherein .eth name registration could be built into the registration process and if the name is no longer needed after the conference the name can just expire.

I think the better way to incentivize longer registrations is to possibly give a discount for longer durations.

5 Likes

Good points.

Although, I want to remind you that this would not affect renewals. Only registrations. You would still be able to renew/extend for any duration you want!

4 Likes

i would suggest 6 months/180 days minimum.

I would provide a counter to this in that, if someone is gifting an ENS domain to somebody, chances are it is 5 characters or longer, and the renewal fee for a year is very low, almost to the point of being negligible.

And if someone is willing to gift a 3 or 4 character domain, chances are the person they are gifting it to is someone who would understand that they are receiving a potentially sought after domain, and some kind of discussions between the two parties would have taken place before the gifting.

3 Likes

Makes sense, please stop the one month registrations, has completely ruined the 10k Chinese digit club, and may have been done on purpose to pump the 999 and 10K Arabic/Western digit club!

I think it should as renewals for very short periods poses the exact same problems as registrations for very short periods, coupled with the fact that there are very few, if any, use-cases for it apart from name trading extensions

I agree.
Imposing a minimum of 365 day registration + 90 days of grace period should be implemented into in the registration contract.

I don’t see a functional use case for a registration period any less than that. These ‘number clubs’ are not clubs and have become a shill fest from twitter accounts with large followings. All I see on the OpenSea secondary sales are emojis+numbers and a yellow exclamation triangle that sticks out like a sore thumb. I don’t think that is a good look when attempting adoption on a larger scale for usable ENS Domains. It’s really giving off a bad vibe. (from my perspective) I just think about a new user exploring ENS whether it is a corporation or individual and seeing this ad being something that turns them away.

Although this is generating income from registration fees, that is a good thing.

ENS names are not some recyclable NFT to mint and rug the next buyer.

1 Like

I would be in favour of increasing the minimum registration duration.

3 Likes

If someone wants to gift an extension to someone else, currently they are free to do so for any amount/duration. However if we imposed such a minimum in renewals, now they would be locked into extending for at least 1 year or longer. Not an issue for 5+ character names, but it would be an issue for 3/4 character names.

Another example/use-case is with the NameWrapper. If you own a subdomain where the appropriate fuses have been burned by the parent owner, then you can be sure that they cannot replace/delete your subdomain. However, the one thing you still might need to worry about is whether the parent domain expires. Maybe the owner goes AWOL or something. The fact that anybody can extend any domain means that the community of subdomain owners can come together and collectively ensure that the parent domain never expires in that case. Of course, if the parent domain is 3-characters, and there was a minimum duration on renewals, then it would be prohibitively expensive for the average person to do that. I would imagine that subdomains under 3/4 character names would be the most popular as well, just a thought.

I think the UX that liuben mentions of people buying short domains for short periods to flip, of which many expire and then end up in a ‘limbo’ state of grace period + premium period is worth it for the reduced UX of gifting short domains. As you said for 5+ character domains this wouldn’t be an issue, which is most names.

I don’t think we need for there to be a minimum duration on renewals. It means you’ve already paid for a year and you have earned the right to renew for shorter periods if you so choose.

3 Likes

Yeah, I didn’t think of buying already-registered short domains, that’s a good point.

This is easily solved by simply sending some ETH to the wallet address instead.

The community could easily pool together to raise the worst case scenario of $640 for a year’s renewal (or more likely, $160 or $5) - a separate contract could even be deployed with a pool functionality.

What these renewals are used for in my experience, is name trading and which causes issues for users when the names are traded, I don’t think either of the reasons above are substantial enough to allow that, especially given that there are incredibly easy workarounds for those scenarios.

II want to caution overfitting the minimum registration period to current market behavior.

What we are really discussing is reducing the set of use cases for the API.

There are going to be a trillion devices on the Internet. Do they all need to commit to a name for a full year? I doubt it. Let’s not force a 12x cost increase on a potential trillion users.

As a thought experiment, engineers, how often have you used a reserved EC2 instance for 1+ year versus just spin up/down a instance? Short-term wins 99% of the time. How confident are you that names are different? For a trillion devices. I’m not very confident.

We are building a fundamental primitive on the Internet. Let’s not constrain use cases capriciously.

If the issue is that the name is caught up in a long grace period, then I first would like to understand what variables we can use to define slightly more complex policies? If a name was registered for less than, say, 90 days, I don’t think it needs a grace period at all, for instance (though I’m reading it’s hard-coded?).

I probably need to read some code or ask a dev some questions to form a strong opinion here.

1 Like

1 year is the norm for every other registrar I’m aware of. If the circumstances change in the future, the minimum registration period can be reduced again.

A better comparison is: how often have you registered a domain name other than .eth for less than one year?