We Need Permanent Registrations - Solution Included

The primary use case for smart contracts is the ability to have updatable pointers in contracts that can be modified. The only argument that has been waged against this is that you can just pay for a longer period of time. While it is true you can pay $500 and have a domain that last your full life, this ignores the fact that some contracts will need hundreds or thousands of different domains, and that such a policy makes it hard for those in developing nations to be part of the decentralization we need them for. The consequences of a domain expiring and being hijacked in a contract are so great that even if it is the fault of the user, it is the fault of the ENS to allow such a thing to occur.

Our proposed solution would be to allow free registration of domains that are someone’s address. So instead of 0x0000…0000, they can use 0x0000…0000.eth permanently for free. It solves another problem as well, people squatting addresses for nefarious purposes of another user.

The only problem here is that there will be some addresses already registered. Every address that is already registered will need to be a special case and fall under the old rules, because you can’t know what that person is using it for. In the cases where the address that registered the domain is equal, then you could just add the permanent registration to that domain.

We need as developers a domain system that is useful for contracts. Having renewals is a terrible system for this because we just don’t know when gas can spike to 1000 for months, or account for people dying and not being able to figure things out in only 3 months.


You can do a subdomain on a domain that has very long expiration. It can even be free and it is likely, someone will do that soon. I have plans to do this.

How long do you think is long enough?

That’s not something to trust for contracts, even if you put it in a wrapper contract where it couldn’t be extracted, that’s an extra layer of complexity.

A domain being reserved for free for an address as itself is a great solution for v3 ENS.

Can you describe me a scenario in which owning 0x0000…0000.eth would be useful when you couldn’t use the address name directly? I don’t understand this.

Namewrapper allows different fuses that would make subdomain wrapping permanent. Also, since anyone can extend a registration, so if some users pool together they can easily extend a name past the 100 years mark.

I think if its a 5 character name, 100 years is realistically fine.

What purpose would it serve to own the ENS name of your address?

1 Like

It stops impersonation for one. It allows for a compromised name to update the owner, be locked in a multisig contract for estate planning, and makes proxy contracting now rock solid safe since it would be permanent.

Finally, look how many people have regged their own address. People are already doing it.

I’m sorry, I don’t see how any of those situations would be useful. To update the owner of a compromised name you need to get to it before the attacker - and even if you do, you’ll now be telling people to send it to 0xcompromisedaddress.eth; if they leave off the .eth it will end up in the compromised account. It all sounds hideously confusing and entirely pointless.

To update the owner of a compromised name you need to get to it before the attacker

You’re assuming a lot here. IWRC, you didn’t get why people would use digits either when there are words, despite digits domains being a lingua franca among Chinese and between Asian nations. This is the same sort of thing. There is a huge market for things Web 2.0 can’t do, not a lust for decentralized versions of things that Web 2.0 already does well.

Secondly, you are diverting the argument to a problem you have the capability to solve with compromised names. This is just a footnote in what is being offered here as a solution to very real problems. We can digress and address compromised names though…The solution is to have a timeout and whitelist function so you can whitelist a multisig for changes, versus dumping your domain in a wrapper contract to extend functionality that should be default.

Back to the permanent registration. There doesn’t seem to be an argument against default binding of an address to its equivalent in .eth. The impersonation risk alone is worth doing it, but for developers of contracts, having domains that can’t expire makes things safer and easier to engineer. We can’t expect people are wealthy and can afford a hundred of years of registration. We need to be inclusive as a community of the poor, because ultimately that’s why this all will work and make people’s lives better.

So far people are not using the ENS for business. They are using it for identity and want to incorporate it in contracts to offer a better UX to existing processes. This is the speculation and experimental phase. We are at the same crossroads of Angelfire and Geocities.

Finally, for names that are identity, should they really ever expire? Soul binding and disabling permanently certain functions seems wise. Many people want their legacy to live on after they die. There should be permanence that is possible in the ENS. You and your friends can afford 1000 years of registration, but can a teacher with wisdom in Yakutsk?

I don’t think so. The digit movement is based on the assumption of scarcity by sub categorizing the near infinite ENS namespace. Your solution has no speculation aspect because it is address bound (and also I assume it’s non transferrable).

Even though we didn’t foresee the popularity of the digit movement we also didn’t have to build anything for it. The community discovered the new usage within the current rule and built tools around it.

BTW, your solution already sorts of exist as reverse registrar which is like [hashof your eth address].addr.reverse. The name is usually to set primary name (0x123.reverse.addr to matoken.eth) using setName, you may be able to call setAddr as the reverse resolver is part of default resolver. Obviously, there is no easy-to-use UI to edit records on reverse resolver, but you could build one to see if people find it useful.

The digit movement is based on the assumption of scarcity by sub categorizing the near infinite ENS namespace.

This is not correct. There were 10s of thousands of digits registered in the old registrar. It was not based on NFT people sub-categorizing. The clubs revolve around the dynamics established from Chinese people and norms based in Chinese culture. The newcomers iterated and made it a collectivist idea of identity, but with pseudo-anonymity. That and some NFT scammers finding a new niche, but that’s a different topic.

The people who didn’t foresee digits are lost in just speaking English. Digits have been a workaround since the 90s in .com space. To be honest, ENS doesn’t solve any problems in the English speaking world right now. We don’t need it. I think this is a huge problem in the governance. It should be in Russian, Hindi, Farsi, or Chinese. Everyone is trying not to adapt here, which is bloody strange for something that’s intended to push the envelope and innovate something new.

BTW, your solution already sorts of exist as reverse registrar which is like [hashof your eth address].addr.reverse.

Yes, another wrapper and attack surface. The issue here is permanence not functionality. Functionality doesn’t matter if the building blocks are insecure. Lack of permanence is a security issue (although it’s a bigger UX issue primarily) and blocks functionality. I have no idea why there is dissent to extending the ENS in useful ways, but here we are.

Going to give this forum a break. I think this discussion is counterproductive. We contributed a lot of resources and time to the ENS, much more than most of the stewards here. Good luck to everyone wondering where it goes wrong when Twitter, VKontake, and Telegram deploy their decentralized domain services. The ENS is a drop in the bucket comparatively.