ENS UI and consequences of faulty logic in ENS processes and smart contracts

Subject: ENS UI and consequences of faulty logic in ENS processes and smart contracts that disallows fair solutions that can be adaptive to multiple use cases

I am not able to open a temp check as i just registered but i will try to put here some details I find useful of processes or logic that needs to be fixed to my opinion

Due to a recent mistake in the UI of the ENS I revoked rights of mine over a newly registered domain that I bought at a temporary premium. I reported it and the UI got fixed overnight. Long story short the domain was wrapped. The UI was indicating the parent (eth) had permissions over my domain and I could go on and revoke. The wording was wrong, it was actually the owner who was losing the permissions. Now the domain is locked. It will only reset permission after expiry. But not during grace period. After grace period when owner loses his domain and it goes to public hunting.

  1. to start from the basics, i find it wrong to wrap newly registered domains by default. this advanced functionality should be enabled by experienced users if they needed the functionality of a wrapped domain NFT. not the reverse going from wrapped to unwrap.
  2. locking a domain should have a different logic. i understand the use cases that need a lock to be immutable. say subdomains are sold to be perpetually owned and they need guarantee the owner won’t resell the domain nor reset the subdomain so they need locked wrapped domain with burned fuses. all good. But see, mistakes like mine happen by accident or even worse by other’s mistake like a wrong UI of an app you use. The logic in the smart contract should be different, performing a few checks and allowing to unlock a locked domain, if those checks pass. Check if the domain has any subdomain with different ownership. If subdomains are all owned by the very same owner as the top domain there is no reason for locking as you take ownership rights from the unique single person that owns the domain and that’s by definition is unacceptable as the very essence of web3 is perpetual uncensored ownership. if someone wants to lose access they can send to burn address rather than being locked out.
  3. i will take it one step further. actually allow for unlocking even when all owners agree to. so check top domain and subdomains and let owners vote for unlocking. these would save situations where unlocking is critical to allow the domain to keep working for decades to come due to changes that we may not be able to think of today.
  4. i don’t know how fast and how possible it is to allow existing locked domains to get the above fixes, they are surely to consider for future wraps, but one fix for those unfairly or accidentally locked out already and need permissions reset, I would suggest the MINIMUM following fix:
  • a. allow locked domain owners, with no other owners/managers involved at any level (top or subdomains), to restrict extension function of their domain by others. this would disallow others to extend the problematic domain perpetuating the situation and allowing ONLY the owner to extend keeping the extension under control.
  • b. finally allow locked domain owners 10 days after grace period ends, to renew the domain they just lost access to without the domain going to public through temporary premium, but at least they have had the permissions reset so they regain access to fuses etc. This would apply to ALL locked domain owners even if they have subdomain owners that are different and so extension is allowed by anyone. The logic is that if nobody has interest to extend the locked domain then it is fair to ALWAYS propose it first to its owner in a reset state, before it goes to public hunting for a premium.

The above fixes I believe would make the ENS properties more reliable.

I don’t have ENS voting power, I wonder if anyone can help me with the above and I am open to hear suggestions about these ideas.

As a programmer myself these are changes I would have implemented beforehand but hopefully we can have a solution even now after the messy situation :frowning:

1 Like

It is not easy to do this within the smart contract, since names are saved in a mapping.

This is an interesting idea. There are many good reasons to allow anyone to renew a name, but sometimes this feature can be abused as well, for example in the case of rilxxlir.eth.

This is interesting, but adds complexity, and people would need to be educated about it, etc.

If the problem was with the V3 app and it caused you to lose the name, I would request a refund/bounty.

The UI in the permissions section was using the word parent instead of owner. I attach pic. I can still edit entries at top level but i have lost access to add subdomains, unwrap and edit resolver or transfer the domain. basically in long run the domain becomes useless if we don’t agree on a solution

thanks for considering this idea. what part you think it adds complexity? how are renewals transitioning from the grace period to the temporary premium? i would think it would need a method to postpone temporary premium for 10 days after grace period ended, so updating the smart contract that adds the temporary premium. then during those 10 days only allow renewal if address of buyer matches previous owner. that would allow locked domains that haven’t been extended by any interested party to be cleared and useful again to the owner who may have mistakenly locked them like in my case.


i expect a solution no to be easy technically and need a lot of planning but is worth work on it because we talk about properties that in a near future may have extreme value like many .com domain has today. it is worth protecting but also giving the right adaptability to various use cases.

a refund of $250 won’t help me really. i hope people with sufficient technical skills and voting power can help me pass a technical proposal that will protect me (and others like me who happen to have similar issue) when the domain expires not to go to public hands after it resets, but it gives 10 days after grace period when it resets, so i can obtain it back with all its fuses. however a protection of extension has also to be implemented so i can disallow extension from others. these 2 things combined would be really useful and let me sleep calm, as i consider this domain of extreme value for my future projects and i really couldn’t sleep in the recent nights due to this depressing situation.

The Labs team is closely watching the new canny board at ens.canny.io, so that might be a great place to articulate your suggestions.

If you do add them to the board, please link those requests here so folk can go up/down vote with additional comments.

1 Like

I agree

so you see the kind of error on this topic… it would be great to update ENS processes and smart contracts to be compatible with disaster recovery mentality always respecting immutability and values of perpetual property.