Hey there!
I wanted to reach out and ask about getting a refund for multiple domains I registered that were valid at the moment I registered them and are now invalid.
I know the team was teasing this for months but I couldn’t find any answer. in the forum.
If you could let me know what the process is for getting a refund, that would be awesome.
Thanks so much for your help!
There is no such process yet that I’m aware of. Once ENS Labs has one, I’m sure there will be an announcement here about it though.
Thanks for letting me know. Is there any reason for the delay in implementing a process? Also, will the DAO/TNL/ENS labs offer refunds to those impacted after the domains expire?
Probably because the new normalization library still needs to be rolled out. To your other question I don’t know. I’m sure that will all be made clear in an official announcement here though!
@Borrowmirr @serenae
Read this post @nick made about normalization and refunds. Although I’m not sure if all these will be a guarantee, I hope it gives some clarity.
(visit the separate topic to read in full)
We intend to put forward a proposal for the ENS DAO to offer refunds for names that are affected by the normalization change. To qualify, they’d have to have been valid under the previous normalization function, but either invalid or have a different normalized form under the new normalization function. We’d provide a refund for any registration remaining as of the date when the new function went into effect (eg, when the social proposal to adopt it passes).
You’re probably won’t like this reply…
To be fair, shouldn’t the refund include the acquisition / mint cost of the now invalid name, all renewal fees paid, and all transaction fees paid by the current holder of the now invalid name - all of that money was sunken into a name under the premise that it would be valid forever as long as renewal was paid. What we mention are actual damages. Whether it is a credit, refund or compensation in $ENS - those names were purchased under the same premise as names that don’t fall under the normalization so why shouldn’t the owners receive full compensation for the money put into names that are completely useless now.
After thinking about this for quite some time. Most–if not all people who registered names were likely aware that normalization was approaching. That’s a risk they took. I’m kind feeling like why should the DAO be responsible for inherit risk taken buy the registrants based purely on speculation, shilling and gifting from people with large twitter followings?
I’ve bought plenty of assets that I read about online but talk about reimbursement by any of them from complete loss has never ever even been thought about.
Whats the dent this will put on the treasury?
The name was usable from when it was registered until the point at which the normalization function was changed. I don’t think it makes sense to refund for that period.
We’re sorry to say, but your statements are not applicable and insensitive to at least our situation, and likely many others. There was no talk about normalization when we bought our now invalid names, nor when we renewed them. There was no “inherent risk” to ever losing a name, or throwing good money after bad in terms of losing renewal fees and transaction fees for a name that would become invalid.
The only inherent risk to buying ENS names would be if the system as a while ceased to exist.
We bought a product that was supposed to valid for life if renewed - this was not a speculative product or asset as you speak of in reference to your own personal experiences.
Not to be argumentative - and please understand that we have the utmost respect for you, and the ENS system as a whole.
Respectfully, at the time the name was purchased, it was sold as a forever valid, immutable name - all money put towards the ownership of every ENS name, including registration fee, renewal fees, and all associated transaction fees were paid based on this premise. Since it now turns out the above is not the case, why shouldn’t the buyers be returned the full amount of money put into the name based on the premise of which it was sold.
Furthermore, the names are not prudently-useable until the beginning of normalization, as it wouldn’t be product to give out a name for the purposes of receiving funds, or utilizing for any of the other core functionality of the name, knowing that it would not be valid in the upcoming future for any of this functionality, nor do the names have any resale value or gift value.
Nick, you come from the corporate world and are familiar with real world business and how it works - of course, in the real world any major company would have the onus to refund all monies back to the user of a product if it didn’t adhere to the terms of which it was sold. Nowhere, and at no time, were any potential buyers of ENS names cautioned that they may be sinking money into a name that will have an end-of-life. As far as everyone knew, if the name was registrable, then it would belong to that wallet with all advertised functionality, for the life of the ENS system, as long renewal fees were paid for that name.
If we’re talking about what is fair and would be fair if argued in front of a judge, of course we have a valid argument. If the DAO doesn’t want to address this issue there isn’t much we can do other than take what we are given, fair or not.
The set names that were previously valid but now invalid with my normalization is small (0.7% of registrations).
The last compare report (ens_normalize vs eth-ens-namehash) shows 13657 names that now error and 3382 that normalize different.
Edit: These numbers include names since inception not necessarily actively registered names. My database also includes primary names (which might not be registered as-is).
The breakdown reports also covers this information but includes ALL registered names, not just valid according to eth-ens-namehash.
I will produce another breakdown report using just valid eth-ens-namehash names and another that uses just valid ens-validation names so this can be seen more clearly.
However, I’m not sure how to handle names that were registered via contract and then sold to people unknowingly — however they did have a 
caution icon.
Can you provide some examples of names you believe are incorrectly handled?
Like @raffy mentions
The names that you registered, were they able to be registered in the official ENS app or would you have to do something like manually input certain characters into a contract to register them? or both?
Just curious.
All registered through the ens.domains - they were accepted through the official ENS dApp…
Thank you for the elaborate and thoughtful response. Here are a few examples of names that we own that were registered through the official ens.domains dApp:
â„ždrug.eth (ENS App)
â„ždrugs.eth (ENS App)
latinâ™›.eth (ENS App)
Perhaps we are incorrect and the above names will normalize?
â„ždrug.eth and latinâ™›.eth are valid UTS-46 (EIP-137/ENSIP-1) and with ens-normalize.
They appear to be invalid with the current dapp which uses ens-validation and AFAIK is a stop-gap to prevent the spoofs allowed with the original normalization spec.
For reference, I felt that 211E (℞) prescription take was “common” enough to stay valid, however I disallowed 211F (℟) response. Obviously this type of stuff is subjective. I tried my best to make these decisions rationally and evidence-based, some of which has been outlined in my norm threads.
Makes sense, thank you…how about:
mcdonald’s🍔️.eth (ENS App)
mcdonald’s🍟️.eth (ENS App)
These names with apostrophes were also registered using the official ens.domains dApp interface without any errors or indications of being invalid…
mcdonald’s🍔️.eth and mcdonald’s🍟️.eth were not registered with the official app, unless there was a 3rd library that was used without my knowledge.
These contain FE0F which is stripped by ens-eth-namehash, ens-validation, and ens-normalize.
I guarantee you they were in-fact registered from the official app - at that time, we had no idea how to do it any other way…if you could please look into it that would be greatly appreciated. It was done on a macbook in chrome from app.ens.domains…using just the regular apostrophe on an U.S. English keyboard. It may be a good exercise for you to understand how we were able to do this as there might be some variables here that were previously overlooked…
Just to be clear, when you say mcdonald’s🍔️.eth, which name do you mean:
Oh, that’s you! Then this is just a normalization-thing. ens-validation doesn’t seem to like that apostrophe yet it’s valid. This was a debatable character that we discussed in the norm thread and allowed with some restrictions.
Under ens-normalize, those names are the same name. The one without FE0F is the name that gets hashed but both are equivalent during registration and resolution.
