Replies: 3 comments
-
After discussion internally, Option A seems like the right path forward. Many of the reasons that originally argued for Option B are no longer relevant as the contract design has evolved and the pros are minor relative to the cons. |
Beta Was this translation helpful? Give feedback.
-
Year-long registrations were implemented here: #125, which raises another question of when renewals should be allowed. There are a couple of options: Option A: Allow renewals for X months after expirationOnce a name expires, there is a "grace period" where the user can renew the name before it goes up for auction. This is the system as currently implemented. The system is currently implemented this way, mostly as an artifact of the "year-end" renewal system. Option B: Allow renewals for X months before expirationBefore the name expires, the user is able to renew the name for another year, but no sooner X months before, where X is a number between 1 and 12. This option is typically better on all fronts, because users who want names that are no longer being used can get them 1 month sooner and the revenue that derives from this accrues to the protocol also arrives faster. Option B seems superior all round better, but there is another question of how long X should be. A very short X would lead to people forgetting to renew, whereas a very long X is equivalent to allowing people to register for two years at a time which is undesirable since it leads to squatting. A 3-month X seems like a reasonable balance between giving users a long window to renew, but preventing squatting. |
Beta Was this translation helpful? Give feedback.
-
Finally, there is the question of how long registrations should be. Our priors on this have been that registrations should only last a year at a time but that we might change it later. Since we are now pursing options that might make upgrades more difficult or expensive we should consider this as a more "long-term" decision and one that ideally does not change. Option A: 1 Year RegistrationsUsers can only register for a year at a time by paying the fee, and renew exactly 3 months before their expiration window is up. Pros:
Cons:
Option B: 3 Year "Flat" RegistrationsUsers can register for up to 3 years at a time by paying 3x the fee, and renew exactly 3 months before their expiration window is up. Pros:
Cons:
Option C: 3 Year "Logarithmic" registrationsUsers can register for up to 3 years at a time and renew exactly 3 months before their expiration window is up. The cost for the first year is 1x the fee, the cost for two years is 3x the fee (2+1) and the cost for three years is 7x the fee (4 + 2 + 1). Pros:
Cons:
|
Beta Was this translation helpful? Give feedback.
-
When an fname is registered it is valid for some amount of time, after which the owner has some time to renew it before it is put up for a public auction. For now, it's desirable that the registration duration is low (<= 1 year) so that people aren't squatting the namespace. However, there are two ways in which the registration duration can be implemented, which comes with its own tradeoffs:
Option A: One-Year Subscriptions
A typical subscription model where the user registers the name for exactly one year from the time of registration. If you get the name at 11:00:00 on Feb 1st 2024, it expires 10:59:59 on Feb 1st 2025. Will require some fancy math to calculate leap-years on-chain
Pros:
register
andbid
will consume ~ 1k less gasOption B: Year-End Subscriptions
An unorthodox subscription model where the registration is only valid until the end of the calendar year and the fees are prorated accordingly. If you buy the name on 11:00:00 July 1st 2024, you pay ~50% of the year's fee and the name expires on 23:59:59 on Dec 31st 2024.
Pros:
Beta Was this translation helpful? Give feedback.
All reactions