[Temp Check] Adding ENS name auto-renewal functionality

[dbmikus]

ENS name auto-renewals: never lose your ENS name

Hi everyone, I wanted to share a plan to enable automated ENS name renewals so that users never forget to renew their ENS names and lose them to name snipers. I presented the rough idea on a community call this past week and had some helpful collaboration and feedback from a few folks there and from a builder group I’m part of (DEF).

I’d like to share it here to get feedback on the parts of the solution and figure out the next steps for working the with ENS DAO, ENS Labs, and the community. The “Questions” section has some specific questions for how to proceed.

Also tagging some folks that were recommended for me to ask feedback from: @jefflau.eth and @Leon

Thanks for previous feedback @slobo.eth, @gregskril, and @anisha.eth (and DEF members)

Problem

Users must manually renew their ENS names. ENS has an email notification system, but it’s still easy to forget to renew. Users and organizations end up losing their names to name snipers and are forced to buy back the names at a premium, or in some cases they cannot reacquire the names at all.

Solution

A system that allows users to renew their ENS names automatically. This system would:

• Eliminate risk of users forgetting to renew their ENS names
• Improve UX and bring the ENS renewal system up to the standards set by traditional DNS name registrars
• Protect users from sniping attacks
• Increase the ENS treasury — more renewals when users configure automated renewals, leads to more revenue.

System Goals

The main goal is to enable automated ENS renewals. This requires a system that can:

1. let users configure automatic renewals for their names
2. track the expiration time of names that enabled automated renewals
3. automatically create a transaction to renew those expiring names

On top of that, there are a few additional goals that I think are valuable to the ENS protocol and to its users:

1. Users can easily set up automated renewals of their ENS names through a web UI
2. Name renewal is decentralized and censorship resistant via a decentralized protocol where users can configure renewal rules and anyone can execute the renewal rule to claim a reward
3. Help those using ENS as their primary on-chain identifier keep their names with sponsored renewals (ie ENS DAO partially covers the costs of their renewals).
   1. Credit to Devon Dolan on coming up with sponsored renewals

How it works

Core renewal functionality

I’ll illustrate with an example. The user goes to the https://ens.domains/ website, and navigates to one of their names. They can click on a “Renewal” button and then configure the renewal rules for the name: when a name is about to expire, do you want to automatically renew it? And if so, for how long?

The app then prompts the user to approve a WETH balance that will cover the cost of the renewal fees and gas.

A transaction relayer system stores the renewal rules, and then continually scans the blockchain for soon-to-be-expiring ENS names. When it finds an expiring name that should be renewed automatically, the relayer creates a transaction to renew the name using the user’s pre-approved WETH balance.

I’m a co-founder of Supercool, which is a relayer service that provides this exact functionality, so we can help power this part of the system.

That’s how the core works. Besides the core, there are two valuable features that we can add: an ENS Renewal Rewards Protocol and sponsored (covered) ENS name renewals.

ENS Renewal Rewards Protocol

The first is a decentralized and censorship-resistant mechanism for renewals. ENS is a foundational blockchain protocol, and it deserves unstoppable renewal infra so that renewals can continue even if all centralized systems go offline. We call this the ENS Renewal Rewards Protocol.

An ENS name holder specifies a renewal rule in the protocol:

• name to renew
• how long to renew for
• a reward to the account/wallet/bot that renews the name

The user commits WETH with their renewal rule to cover the cost of renewal and gas fees along with the reward. When a name is expiring, anyone can execute a renewal through the ENS Renewal Rewards Protocol and receive the reward for renewing the name.

With the decentralized renewal incentive, it’s still necessary to involve the relayer system. This is because you need to define an order in which users can attempt a decentralized renewal. Otherwise you will end up with a lot of simultaneous renewal attempts and wasted gas spent. So for any pending renewal, the Rewards Protocol first allows the relayer to attempt the renewal before falling back to the completely permissionless renewal as a safety measure.

This gets the best of both worlds: renewals are executed without wasted gas, and if any centralized system goes offline or tries to censor renewals then the decentralized system kicks in.

Sponsored name renewals for active names

In order to incentivize the core utility of ENS domains and increase the participation among ENS domain owners, ENS might wish to cover part or the full amount of renewal cost for active accounts in the Ethereum ecosystem. This keeps the ENS namespace healthy: ENS owners are incentivized to set their primary ENS names (see the active user section), active users get to keep their names instead of losing them to snipers, and inactive or squatted names are still freed up. The majority of the fees spent go back into the ENS treasury (minus gas costs), creating a recyclable evergreen system.

The cycle of funds goes:

1. protocol treasury (earned by registration fees)
2. → renewal fees (paid to re-register an ENS name)
3. →protocol treasury (re-registration fees go back into protocol treasury)

The ENS DAO will only sponsor or discount renewal for “active ENS names”. Whether a name is “active” is based on whether it is an account’s primary ENS name, and whether that account is actively participating on chain (more on what qualifies “active” below). This requires a system to monitor name-holder activity continually.

Two options for how to sponsor name renewals:

1. ENS DAO covers the full cost of a sponsorship and will directly interact with the ENS registry contracts
2. ENS DAO partially covers renewal costs. This can be done if the name owner puts the partial cost of a name renewal in the Renewal Rewards Protocol and then ENS covers the remaining cost, performing renewals through the Renewal Rewards Protocol

It is up to the ENS DAO whether they want to fully pay for renewal of active ENS names or provide a partial discount.

Deliverables and budget

Before getting hyper-specific on budget and timeline, I wanted to see what parts of the system the ENS ecosystem is interested in. But here is the rough outline of deliverables and how to cover the cost of development and operations.

• Transaction relayer to monitor expiring names and execute automated renewals
  • Cost: monthly subscription to Supercool for automatic renewal of ENS names. Could be a subscription contract for 1 year or some other interval.
• UI work to add the automated renewal button and renewal configuration to the ENS website
  • Cost: one-time frontend development cost, or done in-house by ENS Labs
  • An alternative is that users configure automated renewals on a new website, but ENS can deliver the value of automated renewals to many more users if the feature is on the main ENS site
• Smart contract and protocol work for the decentralized ENS Renewal Rewards Protocol
  • Cost: one time development cost for the protocol
• Covered/discounted ENS name renewals requires a continually running service to determine if a user is active
  • Cost: either a subscription fee to develop and continually run this system or a flat fee to build the system and then hand over to ENS DAO or Labs to run it

Questions

1. What are the next steps to determine interest and commitment from ENS DAO and/or Labs for auto-renewal?
2. Does ENS want a decentralized Renewal Rewards Protocol that is censorship resistant? This does come with some extra development time and cost.
3. Quickest way to enable renewals is without the a fully decentralized and permissionless renewal system. Is that an acceptable starting point to get enable automated renewals for users?
4. Does ENS DAO want to cover or discount rewards for active name holders?
5. How might grant proposal or contract costs be paid by the ENS DAO or Labs?
   1. I understand that ENS DAO working groups can provide grants and that larger grants go to DAO-wide votes. Curious how ENS Labs factors into this, especially if adding automated renewals to the ens.domains website.

Defining an active user for covered ENS renewal fees

If we implement covered or discounted ENS name renewals for active users, we need a strict definition of what determines an “active” user. Similar to how protocols determine airdrop rewards, we want a fair system that cannot be gamed.

First, to be eligible for sponsored renewals, an ENS name MUST be set as the primary name of an account. That account SHOULD ideally be an EOA or a smart contract wallet. The account SHOULD be actively using the blockchain either on mainnet or L2s. Defining activity is more nuanced. Some levers to play with:

• How many transactions have they made
• How much they hold in token balances
• Gas spent (I don’t like this as incentivizing gas spend seems non-productive)
• What is the time period over which we look at this data? For example, does a user need x transactions in a month, quarter, year, or some other time period?

If ENS wants sponsored renewals, we need to figure out the concrete rules for determining if a user is active.

FAQ

I’m predicting some questions folks might have and pre-answering them.

Q: When a user approves the WETH balance, what prevents the relayer from using that balance for something else or taking the WETH funds from the user?

A: The user approves WETH to a smart contract that can only execute renewals for their chosen ENS names. It cannot use the WETH in any other way.

Q: What is the benefit of an open market for renewal rewards?

A: Anyone can renew, so the system is economically sustaining without relying on any infra provider.

Q: If anyone can renew, why use a relayer for automated renewals?

A: Two reasons:

1. The renewal system will certainly be scripted by bots at some point, and it deserves to be. Requiring someone to press a button manually to review is inefficient. Let’s cut to the chase and provide a relayer that can perform renewals automatically.
2. There is a problem of concurrent renewal attempts causing wasted gas. To preserve gas, we can prefer a canonical relayer as the first preferred renewer before opening the name up to anyone to renew (see next question).

Q: What about concurrent attempts to renew an ENS name, which will result in wasted gas?

A: We need a way to order the users that are allowed to renew a name. The relayer has first dibs for half of the renewal window. No one else can renew during that time. After the renewal window, anyone can renew.

[jefflau.eth]

Hi @dbmikus,

Thanks for proposing this and getting involved with ENS. Here are my initial thoughts:

• The contracts takes ETH, so WETH requires wrapping and unwrapping your ETH. (more gas)
• If you have the WETH/ETH available, then why not just renew at the time? If you don’t renew immediately, there’s no guarantee you’ll actually have enough WETH in there in X years given that the price fluctuates.
• Maybe it’s more useful to have the amount in USDC and have the contract convert to ETH since this gives a higher guarantee that the amount will be covered. Again, it begs the questions, if want reliability and are leaving USDC available why are you not renewing immediately? It would
• If you incentivise relayers to renew, they will renew immediately to take the bounty. Again, this means you would be renewing immediately but losing the amount spent on paying the relayer.

Essentially I can’t see a way this doesn’t costing the user more money or having less certainty of how long their name will be renewed for. I think any solution would need to resolve that before starting a separate conversation about DAO sponsored renewals, which would exaggerate any issues in the renewal relayer system.

[dbmikus]

Thanks for the feedback! Going to respond to each point.

The contracts takes ETH, so WETH requires wrapping and unwrapping your ETH. (more gas)

Yes, the system would have to unwrap the WETH. The reason the relayer uses WETH instead of ETH is so one can grant approval for the relayer to spend the WETH on behalf of the end-user. With current gas prices, unwrapping WETH costs about $3.19 USD.

If you have the WETH/ETH available, then why not just renew at the time?

I can speak anecdotally, but I would imagine I am not unique in this regard. I intend to hold onto dbmikus.eth indefinitely, but I purchased it for only a few years. Reasons being: (1) I don’t want to pay a big lump sum at once, (2) I have an emotional preference to buy a name for 2-5 years instead of 20 years at a time. I think part of this value prop is similar to the reason people use buy-now-pay-later solutions or use monthly subscriptions instead of yearly. Many users don’t like to make big payment commitments all at once.

It’s highly likely that I will always have WETH/ETH in my wallet. Just like I never let my personal savings account empty, I always have some WETH and ETH in my wallet.

With this auto-renewal system, I can avoid paying a big lump sum at once, and I can keep my name as long as I maintain WETH balance in my wallet. I think this is less mental burden for users than keeping track of when their names expire. It also benefits the DAO and the Lab, as automation will increase the number of renewals and thus increase revenue.

Maybe it’s more useful to have the amount in USDC

I like this suggestion.

If you incentivise relayers to renew, they will renew immediately to take the bounty.

I forgot this detail in the renewal incentive: you can only trigger a renewal x blocks or t seconds before the domain expiration. So bots must wait until expiration is close.

[jefflau.eth]

@dbmikus

Yes, the system would have to unwrap the WETH. The reason the relayer uses WETH instead of ETH is so one can grant approval for the relayer to spend the WETH on behalf of the end-user. With current gas prices, unwrapping WETH costs about $3.19 USD.

Yep, understood why WETH technically needs to be used. $3.19 USD would be over 7 months.

@dbmikus

I like this suggestion.

Yeah i think technically USDC sounds good, although it would end up being $3.19 + swap costs.

@dbmikus

It’s highly likely that I will always have WETH/ETH in my wallet. Just like I never let my personal savings account empty, I always have some WETH and ETH in my wallet.

I could see an issue where a user decides for security, private key hygiene to switch their wallets and empty that wallet.

@dbmikus

With this auto-renewal system, I can avoid paying a big lump sum at once, and I can keep my name as long as I maintain WETH balance in my wallet. I think this is less mental burden for users than keeping track of when their names expire. It also benefits the DAO and the Lab, as automation will increase the number of renewals and thus increase revenue.

I think this is a key problem. If renewal is important to you and you have something automatically renewing, then this solution may be problematic since you may not have WETH in that wallet at that point in time. How would you plan to deal with this? It seems like it still needs to be coupled with a notification of sorts similar to how a subscription notifies you when a credit card transaction doesn’t go through.

@dbmikus

I forgot this detail in the renewal incentive: you can only trigger a renewal x blocks or t seconds before the domain expiration. So bots must wait until expiration is close.

Does the gas costs get paid by the renewal incentive? So a bot would have to wait til renewal incentive > gas fee?

[accessor.eth]

@nick.eth Do you think that auto-renewal will foster more name squatting?

[nick.eth]

I think that auto-renew makes sense if the funds are coming from a frequently-used and thus topped-up account. But I think notifying a user of a low balance needs to be an integral part of a solution like this.

[dbmikus]

Outlining the questions and concerns so far:

1. Notification system to make sure a user has funds to auto-renew. (@jefflau.eth, @nick.eth)
2. Instead of auto-renewal, should users just rent a name for a very long period of time? (@jefflau.eth)
3. Tradeoffs in helping active users keep their names versus helping name squatters. (@accessor.eth)
4. How are gas costs paid for automated renewal? (@jefflau.eth)

Please let me know if my responses to these concerns make sense. After I get through all concerns, if there’s appetite for it I’d like to move to next steps to make auto-renewal a reality.

Ensuring a user can pay for their renewal

I agree with others that a user should be notified if they do not have enough funds for auto-renewal. We can configure when this alert gets sent, such as 10 days before name expiration (configurable by the user).

We actually built monitoring and email notifications, which could be used here. It can also automatically add funds to a wallet from a treasury source (not sure if relevant here).

I know that ENS has notifications for name expiration, but I think users will have a higher renewal success rate when we combine automated renewals with token balance notifications. If you have just ENS expiration notifications, a user must always take action, but if they have auto-renewal configured they only need a notification and an action if their wallet balance is too low.

Auto-renewal versus up-front long duration rentals

I shared above, but I think auto-renewals every year or two is more user friendly than an up-front commitment to rent a name for 10+ years. Reasons:

1. I don’t want to pay a big lump sum at once
2. I don’t know how long I might want a name for at the time of initial rental
3. The longer I rent a name for, the more likely I am to forget about manual name renewal when the time comes to renew (email notifications help here, but no solution is perfect)

Traditional DNS registrars all settled on automated renewals as the best way to ensure you keep your domain name.

Name squatters vs. active users

Auto-renewals also help squatters, but I think the benefits to active users outweighs the negative effect caused by name squatters. Three points:

1. The harm from one active user losing their name is greater than the harm from a name being perpetually unavailable. Losing a name is like having your identity stolen and harms multiple users. I might accidentally send funds to the sniper that took dbmikus.eth instead of to the real Dylan!
2. Name squatters are more likely to have their own bot solutions that address this problem. Individuals are less likely to be able to solve it on their own.
3. Name squatters are still paying renewal costs and thus have a limit on what they can squat.

Who pays gas costs?

The user that configures the auto-renewal pays the gas cost. That user is different than the account that executes the renewal, so the renewal transaction will track the gas spent as during the renewal and deduct that from the user’s balance. If you’re familiar with ERC-4337, this is how gasless transactions work.

[accessor.eth]

@dbmikus

Tradeoffs in helping active users keep their names versus helping name squatters. (@accessor.eth)

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.

[dbmikus]

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.

[dbmikus]

@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.

[nick.eth]

@dbmikus

I know that ENS has notifications for name expiration, but I think users will have a higher renewal success rate when we combine automated renewals with token balance notifications. If you have just ENS expiration notifications, a user must always take action, but if they have auto-renewal configured they only need a notification and an action if their wallet balance is too low.

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.

@dbmikus

Name squatters vs. active users

Auto-renewals also help squatters, but I think the benefits to active users outweighs the negative effect caused by name squatters. Three points:

1. The harm from one active user losing their name is greater than the harm from a name being perpetually unavailable. Losing a name is like having your identity stolen and harms multiple users. I might accidentally send funds to the sniper that took dbmikus.eth instead of to the real Dylan!
2. Name squatters are more likely to have their own bot solutions that address this problem. Individuals are less likely to be able to solve it on their own.
3. Name squatters are still paying renewal costs and thus have a limit on what they can squat.

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.

@dbmikus

@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.

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.

[accessor.eth]

@nick.eth

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.

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.

Self-Repaying ENS

[domico.eth]

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.

[dbmikus]

Permament notification system

@nick.eth

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.

We do not intend to pivot or go out of business 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?

[dbmikus]

@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.

[dbmikus]

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!

@domico.eth

My concern here is more around the actual flow.

…

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?”

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?

@domico.eth

By charging the gas to the user this solution solves neither the predictability or the substantial gas costs.

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!

[accessor.eth]

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.

@dbmikus

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

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

[dbmikus]

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

@dbmikus

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.

@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 Nicely laid out.

[accessor.eth]

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.

[dbmikus]

@accessor.eth

… just wrap all this into this and format for an official RFP in a new topic…

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

@accessor.eth

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

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?