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 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?
Weâre only talking about .eth names here. Subdomains can have whatever rules the parent owner decides. They will be much cheaper and can be used for more disposable usecases such as ec2 instance.
Do we have a list of affected users and names? Actual real users who found a name they wanted and couldnât get it? Or is this just a hypothetical concern?
I would like to see a lot stronger justification for restricting protocol usage. Weâre talking about the protocol returning an error for people who are paying to use it how they want. A lot of them.
Prior to the increase of the premium cost name traders sniped virtually every expiring ENS name directly interacting with the contracts giving regular users no chance at all of getting the ENS names they wanted (even when they were willing to pay the then maximum premium)
Itâs the same with registration periods, âHelp I just bought a name and itâs expiredâ is now a common question. If it wasnât for the support tickets I receive from users falling prey to these abnormal practices of name traders I wouldnât care much about this.
So yes, this affects real users.
Makotoâs recent dashboard reveals this as well, showing that the more names a wallet holds, the shorter their registration duration is.
The goal EP5 was to fix the auction parameters to allow for a provably fairer auction. I donât see a fairness violation here. I donât really see how the concepts translate to this discussion.
A name can transfer owners at any point in its renewal period, so this problem is not solved by lengthening a registration period. UIs will need to improve.
Users can renew their name if it expires. I guess Iâm not really understanding how thatâs a specific concern. The name will be cheaper for them to buy if it is soon to expire, and then they have full control over registration period as well.
A user not seeing a piece of data which is stored on the blockchain because the UI doesnât show it to them is not a problem that should be fixed at the smart contract level. There are many ENS UIs already that show expiration times. Itâs a basic piece of information you would know when making a purchase, especially if the asset costs more than $1/day like a 3-letter name. We know this info when making every other subscription purchase online, so ENS isnât different. I wouldnât want to be locked into a one-year Netflix subscription because transfer ownership near expiration requires extending the subscription longer.
Also in your picture, the average registration period is 20 months in your metrics. I would really encourage drilling into the data much deeper to justify this. A 20 month average is not justification just because the trend matches market incentives (it costs money).
This is not hypothetical, but what my friends and I really feel.
In addition, some people have recently been registering domain names in large numbers and for short periods, but when the registration boom passes, there may be a large number of expired names, I think this is not what we want.
Itâs not a threat, but it is counter-intuitive to users when they buy an ENS name which expires days after they do so. The users Iâve supported that has are unaware that itâs even possible to register for less than a year because the UI doesnât make this apparent.
Likewise, it also isnât a threat for someone to register for less than a year. My motivations for a minimum cap is the same for both practices.
Of course it does make it more likely to happen. While a user might occassionally buy an ENS name thatâs close to the expiration date, the odds of it being within days of expiring isnât as high with a minimum cap of 1 year on both registrations and renewals as it is when we allow name traders to habitually only renew for days at a time.
If you look at makotoâs recent dashboard youâll see that trend reflected:
A secondary bonus of not allowing short renewals is that itâd likely lead to fewer ENS names hoarded, because the cost and risk of holding onto a large amount of names youâre not using becomes higher.
Iâve had several support tickets from name traders who bulk* renewed for so few days that their ENS names didnât leave the grace period and were confused by it. Those tickets are logged in #ticket-logs if you want to go spelunking
Most of these use cases can utilitise the SLD, there is no need to waste TLDs for such purpose as burner wallets. TLDs are limited resources. And using short-lived domains wonât exactly benefit projects such as âdonations/charitiesâ - risks the domain being acquired by scammers after expiry and exposing users to a now scam domain. Thereâs more upside for these use-cases to have a long-lived domain than a short-lived domain.
Bulk registration for 1 month and domains going to grace-period for 3 months on towards the premium stage of 21 days before finally expiring have been observed.
How many actual businesses could have used these domains as their abbreviated domain names? If not rectified, this will continue to happen, and can prevent acquisition of the domain by genuine would-be registrants in the future.
Looking at the prices of these domains, itâs evident that nobody is interested in buying the names in secondary markets. What did this achieve ultimately - Itâs blocked (and will continue to block) others from acquiring the names.
âWasteâ is an opinion. Anyone can purchase and use a domain. ENS has significantly more use cases than just translating payment addresses. Anyone with your example concerns can register for longer if thatâs worth it to them.
Another way to look at the data is that ENS has been deployed for 1,892 days, and these domains are off the market for 90 days + ~10-15 days of premium. So ~95% of the time they are available for register. The other 5% of the time anyone can make an offer and someone not using the domain is incentived to accept any nonzero offer above gas costs.
Again, I donât see any actual real businesses affected here. Itâs important to deal with tangible examples and not just theorycrafting.
I think you might have missed the point that there is a huge possibility that those domains can and will be registered again for 1 month duration at a fraction of the cost most likely in bulk by scalpers right after the premium ends. A perpetual cycle. Although a genuine buyer could well indeed pay the premium instead - that could happen to 1 out of 10 domains but what will happen to the rest?
