Why there are no resolvers on ENS containing flags? A tx won´t solve it

Not a single one of my ENS containing a flag have an available resolver, even if I set a public one and pay the tx, still the resolver won´t be defined. Why is this happening specifically with all ENS containing flags?

1 Like

There is currently an issue on the ENS manager UI with names that contain emojis and other non-standard Unicode characters. The resolver (and any records) may not load correctly:

Don’t worry, you still own the name, and it still resolves correctly, it’s just a bug on the manager website/app right now.

3 Likes

There is a similar issue when creating an emoji subdomain:

ex.: :alien:.enspunks.eth

In fact the emoji subdomain won’t even appear in the UI, instead it’s just a contract address (see image below). You can test this by creating an emoji subdomain. As you see from the image below I found/discovered a way to make the emoji subdomain appear and replace the contracts addresses which I published to the community for free, but the resolver issue still exists.

As to the resolver issue, if I also discover a “trick” or work around that results in both the resolver and records showing in the domain manager UI for emoji domains/sunrooms would the qualify as a bug bounty? If so how much would it be worth to find a fix to all the emoji domain holder who can’t add/edit records? Any chance you are familiar with such a “trick” or solution currently?

Edit:

I like the OP also wasted funds on numerous tx’s trying to set the public resolver before asking about this in ENS discord, so there are probably a lot of emoji domains owners wasting money trying to set the resolver, is there something the DAO can/should do to maybe put the community on notice of this emoji issue so others don’t also waste money in attempt to set the resolver?

That’s unrelated, you’re just describing https://app.ens.domains/faq#why-are-some-of-my-subdomains-shown-as-a-jumble-of-characters

Doesn’t have anything to do with emojis or not, it’s just the website not knowing the preimage of the labelhash. Go directly to the subdomain details page via URL in your browser and that’ll be fixed

1 Like

But once populated and accessible the emoji subdomains suffers from the same UI bug as a root with an emoji - the resolver/records do not populate.

Maybe it’s just me and OP that spent money trying to set the resolver, but unless everyone else already knows not to do that and how write to the contract directly on etherscan for emoji domains, then a warning might save users/community money and adding a link to the documentation for how to set records through etherscan could help at least some users.

Yep, that same bug applies to any name with emojis. Just wanted to clarify that the subdomain hash display thing is separate and unrelated.

I believe the frontend devs are aware of this bug, just a matter of prioritizing and fixing it

1 Like