Someone on twitter going by @ledegend_eth (ledegened.eth) has discovered quite a serious bus that scammers will start to use very quickly no doubt.
“busy submitting bug reports. managed to successfully register undetectable hidden character domains. this not good”
They have managed to register a domain with hidden characters, successfully impersonating 0000.eth, without any warnings on any website being displayed for it. Opensea even categorises it as being in the 10k club!
{"message":"TokenID of the query does not match with labelhash of 0000.eth"}
So it’s correct on the ENS side, it’s just the marketplace website being slow to delist. The metadata response is a 404 so ideally they should not list the name in the first place.
This is a reversion of the bug reported by lcfr. He reported it again, and we’ve since re-fixed it. We’re putting in place mitigations to make sure it can’t happen again.
I think the problem still exists - I bought domain on opensea and after the purchase non-ascii character appears - I have a message on ens: "Error syncing data. This data may be out of date. Please use caution. "
“This name contains non-ASCII characters. There may be characters that look identical or very similar to other characters, which could be used to deceive readers.”
Can I do something with this domain or not? On the opensea, you couldn’t see that there was any extra mark there.
Hi, could you share the ENS name that’s affected by this?
As for the other two parts of your question:
“This name contains non-ASCII characters”
This is just a warning message to say that the ENS name contains non-ASCII characters. It will show for any name containing unicode symbols for instance and doesn’t indicate that there’s a problem with the name.
“Error syncing data”
Normally this error message is intended to show whenever the subgraph lags, but there’s a bug in the manager that causes this message to be displayed for any name with non-ASCII characters on the first load of the page. I’ve reported this bug to the front-end team, but you can work around it easily by just refreshing the page which should make it go away.
If the issue is that the name was displayed in a certain way that hid invisible characters on OpenSea, but not in the ENS Manager, then this is an issue with OpenSea rather than ENS, but it’d be helpful to know more about it so that we can relay it to OpenSea.
I took a look at the name and I don’t see any invisible characters for £6555.eth. It also displays consistently and correctly across etherscan, opensea and the ENS manager:
Is it possible that you simply confused the pound sign £ for a number due to the font in your browser, or by looking at it quickly? If not, could you show me a screenshot of where it displays incorrectly?
Thank you for your response. I was in no hurry. I compared another domain and I did it very slowly and I was careful because I know in the crypto world there are people who want to scam you.
99,99% I am confident there was no yellow triangle and there was no display “Ł” sign. The first time, I saw this sign in ens.domain window and message about non-ASCII characters.
Now, in opensea I see this message and a warning message in my domain.
In this picture example, I attached everything looked the same, no non-ascii characters. There was no non-ascii character and I choose that kind of offer. I don have a screenshot from buy time.
I don’t blame anyone, I just wanted to know if these are scam practices.
The screenshot you provided shows a name that experiences an OpenSea bug where the name hash shows instead of the ENS name. That’s not a scam practice, it’s just a bug. Refreshing the metadata for the name usually solves it:
Oh, Thats why I didnt see this warning message. Thank you! I didnt know that.
Is there any reasonable reason to set up domains with such characters? You can’t use them as primare after all.
That’s a great idea! I’ll relay it to the front-end team
You should be able to use any name that’s valid in ENS (including £6555.eth) as your Primary name. Due to the pound sign it might not be supported in all third-party services however, but we’re working on fixing that by rolling out our new normalization library
