UI question for users who auctioned but finailsed


@rliebert90 @nickjohnson @jefflau

So we have another edge condition when a user auctioned and won the name but haven’t finalised yet hence the owner field says “Not owned yet”.

The winner of the name can still migrate but the UI has no indication (apart from the migrate button) about the current situation so they may find it confusing. Should we have any information such as (Not owned yet ( but name was auctioned off by 0x123...)?


Ideally the UI needs to show the ‘registration owner’ separate from the ‘name owner’, in cases where this distinction exists (eg, .eth).

1 Like

That’s sounds quite confusing, even to myself. We’ll have to explain that the registration owner has more ‘power’ than the name owner.


I’m open to other terminology! The distinction is that that the owner of the ENS record only has the ability to update how it resolves.

1 Like

I believe in the long run this is super important for operations that delegate management authority for enterprise assets away from the original owner. In my case, I am the owner/register but in the future will delegate management of the domains/subdomains and their associated sub “smart contracts” to designating parties that manage the content available at these portals (somethinghere.mydomain.eth).

1 Like

An alternate suggestion for terminology: Refer to the owner of the registration as the “Registrant” and the owner of the name in ENS as the “Owner”. The registrant can always recover name ownership.


Did we decide what to do with this?

We definitely need a bit more explanation. The person who registered (left bottom) at least see the migration button, but for the majority of people (bottom right) it says not owned yet cannot register which looks broken.



Is this the deed owner? Why not just call it deed owner? Or

Highest Bidder (Legacy):

IIRC if the auction was never finalized, the deed owner is the “owner” (or is the only address who could become the owner, rather.)

The biggest thing isn’t the names/labels but the fact that there is no way for the potential owner of the name to know that they are the potential owner of the name.

Example, normal:

  • I think I may remember trying to get the name taylor.eth last year
  • I search taylor.eth
  • I see that the owner address is my address
  • I dig out that private key and migrate the name.

Example, unfinalised

  • I think I may remember trying to get the name taylor.eth last year
  • I search taylor.eth
  • I see “no owner”
  • 🤷I guess I didn’t buy it


  • I think I may remember trying to get the name taylor.eth last year
  • I search taylor.eth
  • I see “Owner: Pending”
  • I see “Deed Owner: 0x75b6…2342”
  • I figure I can try unlocking the deed owner address to migrate.

Of, if you want to avoid label decisions altogether, put an informative message below Owner: Pending. “{{ 0x75b6…2342 / You }} can become the owner of this name by migrating it to the new ENS registry.”

Keep in mind, you would only show the deed owner or a message for this edge case (the state is owned but the owner is 0x0?). Especially because I think the deed owner has some edge cases of it’s own that makes that info irrelevant more often than not?


Hi @tayvano . Thank you for your input. I like your “Owner : Pending” idea.

With regards to adding “Deed Owner”, there is a separate issue raised so I will leave it there. For the time being, I will just append “(You have not finalised)” with migration button so that the person can migrate and get ETH back.


It would be nice to sort out the “owner” problem. From what I can see we have two owners that have separate abilities:

  • the owner as per the registry, who can change records on the domain
  • the owner as per the registrar, who can reset the registry owner

Given this, does it make sense to rename the registry owner the administrator and leave the registrar owner the owner? That seems to better fit their roles.

I know it’s too late to change the information in the contract, but we could update the UIs and docs to reflect the reality of the roles.


In our new manager UI, we call this as “controller”.


Isn’t “controller” already used in the registrar contract for a different purpose though?


Yes I noticed that. I think it’s okay because the registrar controller is a smart contract and the terminology never bubble up to the end user. I personally think administrator is a good wording, too. What’s your thought @jefflau @nickjohnson ?


We’ve gone back and forward on terminology. The problem with “registration owner”, “deed owner”, “name owner” etc is that it doesn’t clearly convey a hierarchy of permissions. “Administrator” and “Owner” does, but I don’t think “Administrator” reflects the role.

Personally my favored terminology are “Registrant” and “Controller”, but for now we’ve been using “Registrant” and “Owner”.

This is the reverse of what would make sense to me. An “administrator” generally has the highest level of permissions, not subordinate ones to the owner.


Not from what I’ve seen in the world of computing (nor indeed according to the dictionary definition).

Administrator = entity that manages an asset
Owner = entity that owns an asset

I’m not a fan of using “owner” for anything other than the address that has ultimate control over the ability to transfer the domain. Otherwise there will be cases where users are defrauded by being sold “ownership” of domains.


In another service I develop with Jeff (aka Kickback), we use the term “operator”,very simar to the controller but can avoid naming conflict if that is what we want to avoid.


The “administrator” of a computer system, though, is the one with ultimate control over it.

Good point. Another reason to use ‘controller’ for this - or ‘operator’ as @makoto suggests.


Until the owner sells it :grin:

Anyway, let’s not go back and forth too much on this. What matters most is consistency, so please could you carry out an executive decision as to what to name:

  • the owner as per the registry (I don’t much care; administrator/controller/operator/whatever)
  • the owner as per the registrar (would prefer this to be owner for the reasons outlined previously)

and I’ll update my APIs accordingly. Thanks.


I’m going to go with my previous inclinations, then:

  • The owner in the registrar is the ‘registrant’.
  • The owner in the registry is the ‘controller’.

In terms of operations:

  • Changing ownership at the current level (registrant changing the registrant address, or controller changing the controller address) is a ‘transfer’.
  • The registrant changing the controller address is a ‘set’.

@jefflau Can we update the app accordingly?


Added as a task to github

1 Like