I think this provides a fairly good guarantee usersâ names will continue to be renewed as long as they have funds to cover them - but it doesnât provide firm guarantees theyâll be notified at renewal time.
Unrelated: One advantage you have is that the renewal system can wait for low gas prices; perhaps by having the maximum reward for renewing gradually go up as the renewal date approaches?
What about having a renewal pool contract that âcollectsâ name in queue that is waiting to be renewed?
A renewal pool of let us say 1,000 names set to execute when name slots are no longer available or by a set time.
At what point would this cause network congestion or meet a gas threshold that exceeds block limits?
Is it possible to reserve a future block and dedicate a whole block towards a renewal pool transaction?
A spin on this general idea would be a holding contract that incentivizes extensions by offering a subdomain as reward.
You transfer ownership of a name to this contract, it gives you controller, and then periodically has an auction where it sets an initial price and slowly decreases it until some executes a transaction which issues a subdomain and extends the basename (above some minimum price + minimum extension period). The payer can choose what % of their funds go towards extension vs reward.
Half-baked ideas:
Most of the excess funds could be withdrawn by original owner. The remainder of the excess funds can be shared amongst all owners in the contract to incentivize use.
The original owner during wrapping can set when their name can be unwrapped (any time, beyond last extension, etc.)
The original owner could set the ownership address to a different address (eg. cold) for extra security.
Contract is entirely trustless.
I thought about this more, and there are meaningful tradeoffs for notifications. We either require that:
I know Push Protocol is doing work on option (2), but Iâm not sure what the adoption is of client-side dapps that monitor the Push contracts for events. A further complication of option (2) is that we want to send notifications about upcoming transactions, so there are no on-chain events for those notifications. Creating transactions just to send a notification seems a bit expensive and complicated.
For these reasons, option (1) seems more pragmatic to me at this stage. I would personally prefer to receive a notification via email. Assuming that path, itâs just a question of what level of support or redundancy ENS wants. In ascending levels of how firmly we can guarantee email delivery:
A. We run a notification system for ENS and send emails. This reliance on a central provider works well for many high stakes systems outside of web3.
B. The code for the notification system is open sourced. Then anyone can run it and just needs to hook it into one of many email senders.
C. Multiple operators run the notification system and end-users can subscribe to multiple notification systems for redundancy.
I think option A or B is most pragmatic. If the notification system was open source, a very renewal conscious user could choose to run the open source notifier themselves.
With other solutions, I think the implementation becomes more costly and I donât want perfect to be the enemy of good, in terms of getting auto-renewals live in a reasonable timeframe with reasonable cost.
I like this idea. When a user sets their renewal reward, theyâd set a starting price and a max price theyâd be willing to pay. Could probably also just set a max price and have the contract calculate the starting price.
I think the benefit here is shaving off some gas cost because we have 1 transaction created instead of multiple. There is not a way to reserve future blocks, though, besides just paying the highest priority fee.
Very cool idea! Works well when someone wants to license out subnames. I would not use this for my names, but definitely see a place for it.
I think the real issue is orthogonal to this one: how easy is it for a new provider to take over if the current one discontinues service? Even a centralised provider may be acceptable if thereâs a migration path, but itâs not okay if the provider discontinuing service leads to lost notifications.
This either means that peoplesâ contact details and notification preferences need to be public, or that theyâre private but shared between the provider and a trusted entity (say, ENS Labs or the ENS Foundation) who can transmit them to a new provider if the current one is no longer under contract.
The former is appealing for simplicity, but also has issues; users may want those details to be private, and even if they donât mind having them published, it opens up a phishing opportunity, since would-be phishers will know the user is expecting a notification at that time.
Makes sense, this does seem like the core question regarding notifications.
I personally would not like my ENS name + email address published, even though it would be easy for someone to guess one knowing the other. Iâm in favor of, in descending order of preference:
So, the first option is fully provisioned by the renewal provider. If the provider shuts down, I think itâs sufficient to have a âshutdown clauseâ that they will export all data and notification code to ENS Labs/Foundation to take over and provide x days of hands-on consulting to stand up the new provider. Iâm personally fine with this traditional approach to migration.
The second option, the data already resides in a DB controlled by ENS and they just take over operations.
Also, I understand there is a new notification system on ens.domains, so perhaps this could integrate into that notification system somehow? Or be redundant with that system.
Hey all, thanks everyone for the great feedback! We split out a new forum thread with just the proposal for how we could enable ENS name auto-renewals.