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!
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.
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.
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 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.
Thanks so much for your engagement here! Iâve discussed with the front-end team and we as a team have decided we donât want to integrate this directly into the app in its current form. Please know this is not a bad idea though! A few reasons for this are:
There are too many caveats in the flow:
WETH instead of ETH or USD
Needing the funds up front to commit, especially in a single wallet
The significant gas increase on multiple fronts
The unpredictability of costs
Simply doesnât work how a user would expect it to
The target audience is a bit confused. Itâs pitched towards new users but actually, given the caveats above, this would apply more usefully to power users (large balance, understanding of weth, etc).
This solution is heavily dependent on a robust notification system, however the notification system would solve the majority of the problems already.
It would not be simply adding a button to the app. We would need to integrate it tightly with existing renewal functionality to prevent confusion, which is a significant level of work.
Apologies for any confusion @dbmikus but the manager app is a product built and managed by ENS Labs. We do subcontract every now and again so I would connect with @jefflau.eth if interested. If you have an idea for a protocol/contract-level upgrade, then a DAO proposal would be the appropriate avenue.
This would absolutely be a protocol upgrade. As far as I am aware the DAO can propose anything involving a change of ENS for ENS is a protocol in its base state without the bells and whistles. The front-end part of a website is not part of the protocol. It exists as a controller or interface to remove the complicated task of communicating with Ethereum via code. The protocol exists and functions on the Ethereum Network by use of contracts that communicate with other contracts using the EVM and confirming that data amongst our peersâ nodes without a user interface or front-end.
To add a feature in which a ENS name were to auto renew, new contracts would have to be deployed to control and govern those renewals. Wrap all that up and then those contracts would have to interact with the users account and the other contracts like the registry etc etc.This is outlined in the first article of the ENS DAO constitution
ENS governance may enact a change affecting the registration or extension costs of all names based on transparent criteria such as length, as long as it pursues a goal outlined in this constitution.`
Correct me if I am wrong but the the front-end team at ENS Labs is not the decision maker on what features do and do not get integrated with the ENS protocol. Otherwise that would just make ENS DAO only a financial team of people that vote on the mechanisms of how it distributes funds how ever it chooses. I think that the front-end team at ENS Labs is here to support the decisions that the DAO decides for the protocol and facilitate the changes that the DAO has subsequently voted on.
The funding should be outlined in the Proposal or the RFP + Proposal but never only outlined in the RFP alone. At any stage stewards should be active and advising the RFP submitter and or the proposal proposer as to where the appropriate funding should stem from.
Hi thanks for the quick feedback, @khori.eth! I wanted to clarify a few things, and figure out under what conditions ENS Labs would integrate auto-renewals into app.domains.
Summary
My three main points, which maybe werenât clear in the proposal:
Users need the best tools to keep their ENS names. Users can lose track of notifications, and itâs best to simplify the renewal process for users. Auto-renewals allow users to have the option to do nothing and keep their names (caveats below for if gas is too high or the user has no funds for renewal)
The ENS auto-renewal behaves just like a web2 subscription with a debit card. Configure the subscription, and as long as you have enough WETH the auto-renewal will occur every time your name is about to expire. No up-front funds required.
In my opinion, WETH and USDC (we could use either) are pretty simple. They are used frequently in some of the most consumer-focused crypto apps, such as Opensea.
Iâd love to know the conditions for which ENS would integrate an auto-renewal system. I donât think we can eliminate all of the points you mentioned (such as some increased additional gas cost), but here are some parameters to determine:
What is an acceptable % increase in the gas cost of auto renewals, over manual renewals? Right now it costs 0.0045 ETH to manually extend a name for 1 year.
Is a spend limit on an auto-renewal desirable? ie only allowed to spend up to 0.01 ETH on a renewal
How can we reduce effort required for ENS Labs to integrate auto-renewals? Possibly sub-contracting, as you mentioned.
Clarification of product details
Users can configure the maximum ETH they are will to spend on an auto-renewal. During the renewal period, we wait until gas prices are within range. If the auto-renewal cannot occur, we have a buffer period before the actual name expiry and will send the user an email notification so they can take manual action.
I think there is a misunderstanding here, because we designed the system to function very similarly to how a web2 subscription would use a debit card. The steps:
User configures an auto-renewal rule via the UI, and user approves the auto-renewal system to spend WETH.
When a name is about to expire, the auto-renewal system spends their WETH and renews the name.
The auto-renew rule continues in perpetuity until the user cancels it.
Was your interpretation something else? Sorry if we didnât make this clear.
We intend the audience to be âeveryone that uses ENSâ. I know power users that lost their ENS names that want auto-renewal features. Users donât need a large balance to use this, they just need the minimal balance that renewal costs.
Losing an ENS name has major consequences for users, businesses, and those that interact with them. Notifications are great, but auto-renewals are even better:
I donât need to do anything to renew (no risk of forgetting or losing a notification)
All traditional DNS registrars support auto-renewal, and ENS should seek parity with them by giving users more purchase options
Nothing here would require changing existing contracts or privileged access for new contracts; it can all be done by any third-party, with or without DAO approval. Itâs not a protocol upgrade.