[Proposal] ENS Name Auto-Renewal - stop snipers from stealing your name

After the feedback in the temperature check forum discussion and after speaking directly with @slobo.eth, @alisha.eth, @domico.eth, and @gregskril, we have incorporated the design changes and feedback from the ENS community and Supercool would like to formally propose a system for auto-renewal of ENS names. We’re confident this system would:

  • Eliminate risk of users forgetting to renew their ENS names
  • Protect users from sniping attacks
  • Improve affordability of ENS names: rather than paying a large sum at once, customers can spread the cost over a longer period
  • Improve UX by increasing registration options for users and bringing the ENS renewal system up to the standards set by traditional DNS name registrars
  • Increase the ENS treasury — increase number of purchases and life-time customer value leads to more revenue for ENS

Please feel free to ask questions or provide comments here, or you can reach me at email at dylan@supercool.xyz or over Telegram @dbmikus. Looking forward to continuing the conversation!

Proposal link


Is there a simple way in which the user can opt in to a clickable URL within the manager app, that launches an “event” inside the personas calendar on their device ?

Further more, what if there was part of the manager app that was “calendar” - from which is just another tab and we are then able to see a yearly or monthly overview of all of our domains?

Then apply a simple colour code if the domain needs renewing or is in grace etc

Further more, perhaps a blue dot on the calendar would indicate that it has more than a year before renewal, Gold dots would mean 10 years + and red dot obviously would mean in grace

The interface could utilise mouse hover and a genie effect and some haptics to bring it all to life.

Thanks for posting.

Given that a good piece of this relies on integration into ens.domains, @khori.eth (Executive Director of ENS Labs) is a good person to take it from here.

As additional context, the Ecosystem Working Group funds projects retroactively and has not historically entered into long-term agreements.

1 Like

Does this mean that all initiatives or integrations for ENS must be approved by ENS Labs? To me it seems like that compromises a decentralized solution for ENS as a product.

ENS Labs has historically paid for dev work related to the manager, since it is funded by the DAO to maintain and develop app.ens.domains. I believe the front-end team is meeting today or tomorrow to discuss this work and will be able to provide more of an update later in the week.


I understand that, but since it affects the protocol itself why would it not go to vote?

Just to clarify, this proposal is an opt-in feature on top of the protocol. For those that don’t use auto-renewals, it will not change anything.

1 Like

I get that but if it is an integrative solution for a product doesn’t it essentially become part of the protocol?
Just as we are able to choose certain registration lengths, which is optional. Ya know? I’m not trying to be complicated I just want everything to properly be ‘set in’ in accordance with everything else so there isn’t complication or debate over what is what in the future.

This isn’t a protocol upgrade. It’s more of a question of where funding for this sort of work should come from. Since ENS Labs is funded for front-end work on the manager, it makes sense to consult with the front-end team in the first instance (which has already happened).

If this is not something the front-end team would fund through ENS Labs, a funding request could be put to either the ecosystem working group, or to a DAO-wide vote.