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)
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.
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.
The main goal is to enable automated ENS renewals. This requires a system that can:
- let users configure automatic renewals for their names
- track the expiration time of names that enabled automated renewals
- 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:
- Users can easily set up automated renewals of their ENS names through a web UI
- 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
- 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).
- 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:
- protocol treasury (earned by registration fees)
- → renewal fees (paid to re-register an ENS name)
- →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:
- ENS DAO covers the full cost of a sponsorship and will directly interact with the ENS registry contracts
- 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
- What are the next steps to determine interest and commitment from ENS DAO and/or Labs for auto-renewal?
- Does ENS want a decentralized Renewal Rewards Protocol that is censorship resistant? This does come with some extra development time and cost.
- 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?
- Does ENS DAO want to cover or discount rewards for active name holders?
- How might grant proposal or contract costs be paid by the ENS DAO or Labs?
- 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
xtransactions 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.
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:
- 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.
- 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.