[Temp Check] Adding ENS name auto-renewal functionality

I generally think auto-payments by a third party which, IMO includes a contract are harmful to peoples finances.Which is a reason why I’m trying to move fully into cryptocurrency an less reliant on the fiat system.

But I suppose if the user experience was designed in a way for a user to have complete control over the renewal process, it would be useful. As long as an end user has complete control over the contract and funds with no third party, then it would become desirable to utilize. I’m not trying to sway any opinions, people make their own choices how they handle their business. I just think it’s an interesting topic to reflect on.

I understand your concerns here. The user does have complete control over the renewal. They have the option for whether or not to configure auto-renewals, and they can disable auto-renewals at any point in time. We could even send them an email notification in advance of the auto-renewal in case they want to change or disable their auto-renewal rule.

I personally would love to be able to set and forget renewals for my ENS names, so I think adding this as an option for users is net-beneficial. Those that want to use it can, and those that do not can skip it.

1 Like

@nick.eth, what do you think of this process for notifying a user to ensure they have enough tokens to renew:

  1. When a user configures their renewal rule, they can specify an email address for “low-balance notifications”.
  2. x days before the renewal occurs, the system checks the user’s token balance and sends them a message if the token balance is too low. The user can configure x if they want.
  3. The renewal itself occurs a few days before the actual expiration date, so if the renewal attempt would fail due to low balance, we can send a notification to the user then as well.

Note that for step 3, the renewal system will not waste gas attempting to renew a name if it knows their is not enough token balance to approve renewals.

I agree. A good solution should also come with a notification ahead of the auto-renewal to let users know it’s going to happen before it does.

Speculators and squatters are also more likely to have their own automated setup for renewals than end-users, or to check their names regularly. Auto-renewals help end-users much more than anyone else.

This seems reasonable, with the above note that it should send an email even if they have enough tokens, to remind them the renewal is coming up.

One thing I should be upfront about: we’ve experimented with several different notification systems for expiring domains in the ENS Labs frontend, and one persistent issue we’ve had is with the companies providing them going out of business, or pivoting and no longer supporting the product.

This is particularly harmful because it means that users who were relying on this will simply never receive the notification, and will likely lose the domain. For me to feel comfortable endorsing a new solution, we’d need to have some pretty solid guarantees of longevity - and preferably the solution would be decentralised so new providers can take over if the old one folds.

What about Push Protocol? Would that be an integration to fit the needs of a viable notification system?

I just came across this, although I have not used it. It appears to be expensive like 3-4x gas costs unless you are staking on their platform, then the costs supposedly balance out.

From a purely UX perspective (not thinking about contracts, gas, tokens, etc) I do think automatic renewals is an idea worth exploring. I agree with @jefflau.eth that we generally encourage people to register for longer up front due to ETH and gas price fluctuations, but I also acknowledge that the outlay can be significantly daunting.

My concern here is more around the actual flow. Correct me if I’m wrong, but the user experience would look something like this;

  • Set up auto renew by picking the number of years (and corresponding WETH)
  • Set and forget
  • If my renewal is coming up and I have insufficient balance, I will be notified to top up my WETH
  • If my number of years is ending I will be notified to set up a new renewal

The benefit of automatic renewals (and why so many companies have moved to SaSS in the last decade) is that there is no end date. The question we currently ask during registration and extensions is “How long will this name be useful to you?”, which is admittedly a hard question to answer most of the time.

Automatic renewals sidestep this by saying “You don’t need to know how long this is useful, you can just stop paying for it when you’re done and otherwise not think about it”. By still asking the buyer to specify a timeframe up front, you’re missing the magic of renewals in my mind.

Another primary benefit of automatic renewals is the price predictability. However, the main reason users are encouraged to register for multiple years is that gas costs of extending yearly can very quickly exceed the cost of the name, in a way that can’t be predicted. By charging the gas to the user this solution solves neither the predictability or the substantial gas costs. I don’t have any suggestions on how you’d overcome these (and I don’t even know if these problems are for this solution to solve), I’m more just opening the discussion. For a user, while the initial outlay is lower, the cost over time is higher and much less predictable.

Permament notification system

We do not intend to pivot or go out of business :grin: but I totally understand the concern! I’m a fan @accessor.eth’s suggestion to integrate with the Push Protocol. I think we can support multiple notification channels.

@nick.eth, I think this combination of things gives you permanent (or as close to as possible) infra you’re asking about:

  • The decentralized renewal rewards contract ensures is a permanent protocol to let users configure renewals.
  • We support email notifications for convenience.
  • We integrate with Push Protocol as well for decentralized notifications.
  • We can extend to support arbitrary other notification protocols as well.
  • Some other options to explore:
    • Managed hosting for this notification system, where ENS owns the system but we can build and operate it.
    • A long-term support contract to guarantee continued operation
    • Something else that you’d propose to ensure longevity of the system?

@nick.eth any thoughts on these options or what other guarantees you’d like?

1 Like

@accessor.eth, thanks for finding and sharing the Alchemix solution! I’ve actually seen it before. It’s a neat solution, but there are some things I don’t like about it:

  1. There is no notification system bundled in with the Alchemix solution.
  2. It requires you to deposit ETH into an alETH position, instead of being able to use the WETH/DAI/USDC you already own.
  3. This proposed solution should be cheaper than the Alchemix renewal, as there is no loan and swap process. But I’d have to run profiling on the actual code to be sure.
  4. Users are constrained to only 1 year renewal intervals. This proposed system lets users configure the length of renewal intervals.

At a meta level, the Alchemix solution is a little “financey”. We really just want end-users to be able to auto-renew without worrying about depositing to a pool, setting up DeFi positions, etc.

Thanks for the feedback, @domico.eth!

Totally understand encouraging people to make long-term renewals up front for price predictability. But I’ve seen first-hand multiple tech-savvy people lose their ENS names by accident, and I think auto-renewals will help them. I think it’s important to meet users where they are in terms of behavior, and many are setting up name leases for shorter periods of time, even though they intend to keep them long term.

In terms of ETH and gas price fluctuation, I’m hoping at some point users can interact with ENS through L2s with stabler pricing, but that’s outside this scope. Inflation comes for us all, no matter where we are!

I think I did not clearly communicate this part. When I set up an auto-renewal that renews for 2 years, the events go like this:

  1. I set up my 2 year auto-renewal rule
  2. Name expiration approaches
  3. Auto-renewal system renews for 2 years
  4. 2 years later, name expiration approaches
  5. Auto-renewal system renews again for 2 years

In summary, I set up a renewal rule, and that rule stays active until I either disable it or run out of funds to pay for renewal. So I can set and forget it. Does that answer your concern there?

In my opinion, an automatic renewal/subscription system is better for customers than upfront payment for two reasons:

  1. Improved affordability: Subscriptions can make ENS names more affordable. Rather than paying a large sum at once, customers can spread the cost over a longer period. With ENS renewals customers can have the best of both worlds: A) they can eliminate the risk of losing their name, and B) they can spread out the cost of having such name over time.

  2. Flexibility: Customers can assess the utility of owning the name over time and can decide to continue or discontinue renewing the name. With the ENS renewal system, customers can make a long-term purchase decision without knowing the utility time-frame of the ENS name beforehand.

Users can still decide to pay upfront if they choose.

I think that price predictability is outside of my control for auto-renewals unless ENS DAO or Labs wants to consider sponsoring gas costs for renewing users. I mentioned this name renewal sponsorship above. Happy to explore that as well!

1 Like

It was more of just a share than anything. I don’t see it being a efficient way to renew. (Ref. Alchemix)

The goal should be to simplify these processes as much as possible for the end-users. Like previously said, If we can develop a system that allows users to auto-renew without having to understand the intricacies of DeFi or pool deposits, we’ll have achieved a significant win in terms of user experience.

Ideally this should be integrated into the main app interface. This would create a comprehensive all in one management system making it incredibly easy to manage all things ENS.

User Registration and Login:
Users register or log in to the platform using their Ethereum wallet.

Dashboard:
The user lands on a dashboard displaying all their ENS domain names, their expiration dates, and their current status (Active/Expired).

Auto-Renewal Setup:
Next to each ENS name, there is a toggle for auto-renewal. By default, this would set to off. (Do not renew)
The user toggles on the auto-renewal for their chosen domain name(s).

Renewal Interval Setting:
Once auto-renewal is activated, the user is prompted to set a renewal intervalThis could range from 1 month to several years, depending on their preference.

Payment Method Selection
The user is then asked to select a payment method for the auto-renewal. This could be ETH, WETH, DAI, USDC, etc. This would most likely require more than enough gas to ensure renewal.

Confirmation
The user reviews the details (ENS name, renewal interval, and payment method), then confirms to activate auto-renewal.

Notification System
Users receive notifications when a renewal is coming up, when a renewal has been successfully processed, or if there’s an issue with the payment method. This could be done via email, SMS, or in-dashboard notifications or even Push Protocol (formerly Ethereum Push Notification Service.

Renewal Execution
When the time for renewal arrives, the platform automatically executes the renewal transaction using the user’s selected payment method.

Monitoring and Adjustment
Users can monitor their auto-renewal status from their dashboard and adjust their settings (renewal interval, payment method) as necessary.

This could get very expensive very fast. But using this sparingly would cause attention to a new built-in feature.

1 Like

Following up to wrap up any questions and then see about next steps.

Decentralization and longevity

@nick.eth, to ensure longevity and decentralization of the renewal system, we have:

  • the decentralized Renewal Rewards Protocol: no central system required to execute a renewal
  • notification system can integrate with Push Protocol as well as email
  • options for ENS to own notification system with managed hosting, or long term support contract

Any other things you think are a requirement for a long-lasting renewal system with ENS?

Set it and forget it auto-renewals

@domico.eth, did this explanation make sense?

Next steps

I need to finalize the list of deliverables that ENS DAO and Labs are interested in, and then settle on pricing that works. Questions:

  1. @domico.eth, are you the right person to talk to about integrating auto-renewals into the ens.domains website? Are you interested in this feature, assuming right functionality and price?
  2. To discuss a list of deliverables and cost, should I either: (a) talk with ENS Labs (owners of ens.domains), (b) write up a proposal for an ENS DAO working group?

Thanks everyone for the feedback so far! And @accessor.eth, your sequence of steps for the UX make sense to me :+1: Nicely laid out.

1 Like

I think that this thread would suffice as an RFP itself.At least, I believe it covers all the points required. Here is a more detailed requirement description on the governance process.. I would say to just wrap all this into this and format for an official RFP in a new topic for the stewards to review and see if we could move this forward to a full on proposal to the DAO.

I will change the title of this topic so that it reads [Temp Check].
When creating the RFP, put ‘[RFP]’ at the beginning of the topic title.

The RFP is more of a justification and reasoning as to why something should or should not be implemented or integrated into the ENS ecosystem.

If it moves to a proposal, then that will be the full on detailed outline of required work to satisfy the request. Any persons or team can submit a proposal based on the RFP.


Are you suggesting that a renewal rewards feature be built in?

What would be the reward? Keep in mind that we would have to provide a reward for all users who renew. That means it would have to be rewarding to any user with at least just 1 renewal.
If the renewal system provided a reward for 1 name renewal, how could we find a cost/benefit reward that still keeps registration on par with gas or better + a reward. Also the same for let’s say 100 renewals were as it may be too rewarding.

2 Likes

Thanks for the info! Very helpful. I will go ahead and look into the RFP and a proposal.

Just want to re-explain to make sure we’re talking about the same thing here. The Renewal Rewards Protocol I mentioned is a decentralized protocol that would let me set a renewal rule and post a reward (in WETH or another ERC-20) for renewal. Then when my name nears expiration, anyone can extend my name’s registration and receive the renewal reward I posted.

Were you talking about that reward, or something else?

1 Like

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?

@nick.eth

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:

  1. notifications send a message off-chain, such as through email or a mobile push notification
  2. users run clients that check for blockchain events and display notifications

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.

1 Like

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:

  1. Renewal + notification provider stores contact privately in a database owned by the provider
  2. ENS Labs or Foundation owns a database and grants the renewal + notification system a role that gives read/write access just to the renewal + contact info necessary for renewals

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.

1 Like