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