Ability to Specify Custom Registrant and Controller at Time of ENS Name Registration

First and foremost, GM²⁷ to all!

Temp Check on how the community feels about implementing the ability for to specify custom Registrant and Controller wallets at time point of purchase / ENS Name registration from the registrar.


  1. User decides to register fauci.eth for his friend, finds that it is available, and pays the gas for the first step.

  2. Upon reaching step 2 the user is presented with an option for “default / express setup” or “gift registration or expert setup”

When toggled to default / express setup: User is shown a screen print example of his wallet as the Registrant and Controller to make it clear of the results of the default / express registration.

If user selects gift registration or expert setup: User can paste a custom wallet address or enter the .eth for both the Registrant and Controller for the name being registered.

This is marketing and adoption gold in terms of the gifting aspect, but also increases usability for expert users on a number of levels.

Heartfelt wishes of peace and love to all of our frENS!


Hi @ensrus This is a great idea and I was literally just thinking about this a few days ago. I gifted someone their .ETH name. We had to do 4 transactions to get things set up right.

  1. I registered the name and paid initial gas.
  2. I then paid gas to transfer the Registrant to their wallet address.
  3. Upon changing the Registrant, I noticed the controller was still linked to my wallet AND their initial ETH address in the records was still my own. (which if someone sent assets to friendsname.eth, those would have gone to me without any additional changes.)
  4. The receiver of the gifted name then had to change the Controller record and pay gas.
  5. Once controller was set, they could change their ETH record to their own wallet address, and pay gas fee #4.

I was not sure if I was registering the “long way” for them. But 4 total gas transactions seems like a waste if somehow the changes could be batched. Also, your proposal is great idea for gifting because this person was new to ENS. Securing the name for them was one thing/cost. However that alone wasn’t enough because the default ETH payment was set to the original registrant wallet address. So I had to explain, “Hey got you a gift. But make sure you don’t take payments yet because it will come to my own address until you pay gas to change those records. Oh and you need to pay gas first for changing controller, to be able to then pay gas to change your eth payment address to your own.”

Good share. Definitely all for changing some of this process.


That is actual a perfect case of how this proposal could streamline gifting.

Another added benefit of implementing the functionality of custom Registrant / Controller to the registrar contract:

There will soon be web2 onboarding-interfaces who will allow web2 customers to purchase ENS with traditional payment methods (Credit / Debit Cards) and these providers will be enticed with further ENS contract functionality which they can integrate with to enhance their customer experience.

There is reason to believe this concept could also decrease abandonment at point of sale…


I’m thinking something like a “transfer” button that uses an emoji of something like a giftbox. This way it’s easily understood people can pick up names for others and easily (and completely) transfer it to them. As of right now, just registering the name for someone is only the first step. And transferring registrant is only second step. When I first gifted a name to someone some months ago, I didn’t really know all of what the differences were in controller. We just noticed that the ETH payments would have gone to me and not the person who it was bought/gifted to. Which, if they weren’t a friend of mine they maybe would of thought I was scamming them since my ETH address remained in the records address even post transferring them registrant/ownership.

So yeah, I like this post and proposal.


This definitely seems like it would be useful. It seems like plenty of people would want the ability to gift others ENS names, as I’ve answered that topic many times in the Discord server.

Instead of pasting the same thing here I’ll just link to the comment I made in your other thread: ENS Name Gift Link - #3 by serenae


The underlying registrar contract already supports some of this - you can specify the Registrant+Controller address, the resolver to use, and the address the name should resolve to. Neither has to be the address of the account sending the transaction, and the resolver and resolving address can be omitted.

We don’t have support for this in the UI at the moment, but hope to add it in the redesign.

Allowing the registrant and controller to be different is much more difficult, as the underlying Registrar contract is immutable, and only allows two options: Setting both to the same address, or setting the registrant but not the controller (in which case the registrant then needs to call ‘reclaim’ to set the controller address).

We could provide for setting registrant and controller separately using this functionality in a new version of the contracts, but that would impose additional gas overhead on every contract that doesn’t need them set differently.


Thank you for the thoughtful response - we will take some more time to consider this concept.


Agree strongly that in addition to streamlining the UX of ‘gifting’, this could help web2 better connect to web3.

In my day job, I see the start of a lot of tradfi companies working with providers to create ‘web3 sleeves’ i.e provider takes care of the interfacing of tradfi customers who are web3 users with the tradfi co’s central clearing wallet.

I think of this as analogous to what BaaS providers do for banks. Is there a way to facilitate the above who would pay more; to then subsidize us individual users?


I understand a bit more, thank you for that explanation.


I think this is a great idea! I’m all for it


Transactions will happen more freely if the transaction costs regress towards zero or counterparts risk is insured. Very agile.