How to prevent scams with ENS subdomains?

The new Coinbase NFT site was brought up in a different thread, and I noted that it appears to just use its own private database of usernames (I’m guessing the same system from Coinbase Wallet):

And this is already leading to new scams:

Now there’s an interesting new wrinkle in the story:

If Coinbase is rolling out ENS subdomains, I’m assuming their existing database of Coinbase Wallet / Coinbase NFT usernames will just be converted into *.coinbase.eth subdomains or something like that?

What’s most interesting to me, and I didn’t realize this before about ENS subdomains… is that this doesn’t appear to cut down on impersonation scams, but might even help such scams…

Now you’re just creating another new popular namespace that scammers can squat names in, like that example from above with @yugalabs on Coinbase NFT. Even if that will actually turn into yugalabs.coinbase.eth in the future, I can almost guarantee you that the average user isn’t going to know that (especially if Coinbase’s website still just shows @yugalabs). They’re still just going to think that’s the official account.

Like what if twitter.eth was given to Twitter and they start allowing people to register subdomains, and have some kind of first-class integration for those subdomains on Twitter profiles? Now I can go and squat on vitalik.twitter.eth and trick people into thinking I’m Vitalik!

For the vast majority of subdomain systems I’m sure this won’t be an issue, but it’ll definitely be an issue on those few ultra-popular systems (like perhaps *.coinbase.eth). Unless the owners build some sort of restrictions on which names can be registered.

For example, maybe only the owner of domain.eth can claim domain.coinbase.eth or something. Similar to how claiming DNS domains works on ENS. That way at least the owner of a .eth name wouldn’t need to worry about someone claiming their name in some popular subdomain namespace and scamming others with it.

Such restrictions would not be on the ENS protocol side but rather built into each subdomain registrar obviously. If anyone is working on or is aware of such subdomain registrars, I would definitely hope that they include restrictions like this to prevent scams. Otherwise I fear that ENS subdomains could have a more harmful than helpful effect on the web3 ecosystem…

Thoughts? Am I overthinking it? @zadok7 and I deal with a lot of scam-related support tickets, and I’m just envisioning and dreading the new wave of ENS scams that could arise once L2 subdomains are possible. :sweat_smile:


This was a known threat vector from making subdomains like free birds. Freedom :handshake: scams. Although, I’d imagine that Coinbase is exposing itself to a lot of legal mess if it doesn’t police *.coinbase.eth. Someone scamming as vitalik.coinbase.eth lands coinbase.eth in trouble.


There can be “scams” in .eth too. So it’s not really any different. I think what most people are hoping for is that there is consensus that .eth is the one and only name space that will eventually be traded to the point that all the names are not “scams”.

A custom resolver can be created which simply looks for you .eth and gives you a subdomain using that. I would get premm.coinbase.eth, etc.


I don’t think that would work, it kinda defeats part of the purpose of having a separate subdomain space (I can actually get my own name in's namespace, while Carlos from Forefront already got carlos.eth). It’s not supposed to be a “have universal rights to this name everywhere in every namespace” system.

I don’t think there’s a super strong solution to people just not checking before throwing money at things, unfortunately. Implementing a well-structured verification badge system of some sort is the best thing I can think of, it can certainly be built on-top of ENS (and for NFT collections in particular I’ve said in the past, I think ENS is in the best position to take on the problem of verifying collections and signaling that).

They’re possible today, the core team just hasn’t deployed a canonical L2 resolver yet.


The scams are sad to see. Especially the ones where they say, “I logged into a link someone sent me for X NFT project, all my NFTs were stolen, how do I get back my ENS name?”

The person has spent time telling friends their .eth name, or building an identity with it. Then they sign some phishing contract giving token approvals to their wallet, and bam, their NFTs are gone, including their ENS name. It really sucks.

As you mentioned @serenae there is an attack vector with users or projects having their “handle” registered as a subdomain of some “ultra-popular” systems. But I think this is the way:

For a platform like Coinbase or Twitter to just allow any subdomain to be “minted” I think would not be the right direction. Besides, we’re talking about bridging web2 to blockchain if you think about it in those terms. What we’re really saying is a centralized web2 platform like Twitter, or Coinbase wants to give digital identities to their associated web2 users. By this I mean that a Twitter username, or Coinbase username resides in web2 (it’s in some database somewhere on a server).

So we’re asking, “how do we ensure the web2 identity matches the web3 identity?”

It’s on them in my opinion. But I would love to see some standardized subdomain contract put out that might integrate with some type of API service to bridge web2 usernames with web3 subdomain identities.

This could work @Premm.eth, but going back to the Twitter example with vitalik.twitter.eth
You are saying only vitalik.eth would be allowed to register vitalik.twitter.eth because he is proven to own the top-level .eth name of vitalik.eth?

There’s some issues with this, because sometimes the parent .eth identity might not match the username of the platform. So on Twitter, Vitalik is @VitalikButerin. Would he only be allowed to “mint” vitalik.twitter.eth because that’s the .eth name he has? Someone could therefore hold vitalikbuterin.eth and register the subdomain vitalikbuterin.twitter.eth. It’s a good thing he holds both, but what if he didn’t?

Have to consider the mismatch between the user names on the platform, and the blockchain subdomain ENS identity that is permitted to be issued by the parent .eth.


Thanks all for helping me think through these things.

Very good points. It’ll definitely be up to the owner of that domain to decide how to police their subdomains (or not).

Ah yes, instead of “possible” I meant more like “easy for the average cryptojoe to do”

Yes, it’s not really any different, which I think is kind of the issue…

Why ENS? From the website:

“No more sandboxed usernames.” Well… unless you’re using Coinbase NFT, in which case they may not just let you use your own ENS name, they may only allow you to use their sandboxed usernames (*.coinbase.eth subdomains). This is conjecture on my part, I don’t actually know what Coinbase plans to do.

In web2 we’ve built up so many popular namespaces like Twitter, Instagram, and obviously .com and the rest. Sandboxed social media platforms in particular are rife with impersonation scams because it’s so easy (and free) to do.

I had kinda hoped ENS would be the antidote to that. So anyone can go and register a .eth name, and then bring that name to Twitter/Instagram/etc, sign a message, and it displays your .eth name with a special logo/banner that signals to everyone else that you are the legit owner of that name. Assuming that normalization issues are addressed, then you could almost completely eliminate that problem. On Nftychat I don’t have to worry when I see a username, because I know it only allows the ENS primary name to be displayed (at least right now). If I’m talking to @slobo.eth then I know it’s the real account immediately.

Instead what we may end up getting is each individual platform still using their own sandboxed username system, just with ENS subdomains instead. Pretend I’m grandma and explain to me, what is the advantage of this over the current sandboxed username system of Coinbase Wallet or Twitter?


That’s not the way I see it. In fact, just by implementing an ENS based subdomain space, you are ensuring the names aren’t sandboxed!

I can choose to use my coinbase.eth name anywhere that accepts valid ENS names just by the fact it builds on ENS, that means it’s not sandboxed. I believe that is what that tagline is referring to.

I actually think NftyChat is doing it wrong. is just as valid an ENS name as carlosdp.eth. Any app accepting ENS names should accept both.

Having users understand that carlosdp.coinbase.eth != carlosdp.eth is a UX problem that needs to be solved.


Yes, sure, if you want to. If carlosdp.coinbase.eth is one of your preferred primary web3 profiles that you’d like to display elsewhere. If Coinbase is your first entry into ENS then maybe that’ll be true. But it probably would not be true if you already have your own ENS name that you’ve built up a presence around.

Okay, now imagine Twitter does the same thing. Oops, you can’t bring carlosdp.coinbase.eth to Twitter because they make you create another subdomain carlosdp.twitter.eth! Oops, that’s already taken anyway, because someone saw you created that on Coinbase NFT and snagged it on Twitter already!

As far as I understand they do accept both. Whatever your ENS primary name is gets displayed. Subdomains and DNS domains/subdomains can be set as ENS primary names too.

1 Like

Yea for sure, and I would hope Coinbase shows your primary .eth name in the out-of-beta version of the marketplace. They accept .eth everywhere else, so imagine they would, we’ll see!

Ok cool, I mis-read your comment then! But then NftyChat has the exact same problem as Coinbase NFT, doesn’t it? :thinking:

How so? You do not create a username (or nftychat.eth subdomain) on Nftychat. You just sign in with your Ethereum account, and your ENS primary name is automatically displayed.

Sorry, by “same problem” I mean impersonation subdomain names

True, but then you’ll see the username as vitalik.somedomain.eth, not vitalik.eth, so there’s at least a clear distinction. Any account can sign into Nftychat, so the real vitalik.eth can sign in and everyone can instantly know it’s the real deal. And as you said before, having users understand that distinction is up to good UX.

However on other platforms, will you be able to bring your existing ETH account with you, sign in with it, and display your already existing ENS primary name? Or will they force you into creating a new username/subdomain in their system and you can only use that?

And if they do have their own subdomain/username system, will the platform clearly display vitalik.coinbase.eth? Or will they abstract that away and just show @vitalik like they currently do for the scam @yugalabs account on Coinbase NFT?

I think we’re mostly on the same page, a lot is going to be riding on good UX! Which… crypto is not known for… but anyway… I think it’ll also be important for platforms like Coinbase/Twitter/Instagram/etc to let you bring your own account/ENS and not force people into their own proprietary username/subdomain namespace.

1 Like

It’s a pretty important feature of ENS that subdomains are completely controlled by parent domains, so we should be careful about recommended UI/UX policy. I wouldn’t want blog.royalfork.eth to be marked as “scammy” because it doesn’t have the blessing of blog.eth. We should also be sensitive to coinbase’s potential business requirements; I’d imagine they want complete control of their username namespace, and wouldn’t want to worry about name transfers/expirations/etc. These types of use-cases should be encouraged by ENS.

Perhaps ENS should consider adding a resolver method which allows domain owners to verify “beneficial ownership” of subdomains? Something like existing text records (which currently has keys for com.twitter, or com.github), but with deeper integration with ENS subdomains. That way, vitalik.eth would be able to validate that he uses vbuterin.coinbase.eth, and you’d know that vitalik.coinbase.eth has no relation to vitalik.eth.


This is correct. nfty chat relies 100% on ENS for their usernames.

If is imported into ENS it will show up on nfty chat as, ditto for sub-domains like steward.slobo.eth.


I hope over time web3 companies realize the benefits of having one and only one namespace, which is ENS.

Having @yugalabs is likely going to end up hurting coinbase over the long-term. Time will tell though.


Right, which back to my original point, this is a “how do you give people better trust signals” problem at the end of the day. Because someone can probably get away with using “vitaiik.eth” and scam a bunch of people today, for example.

If they’re smart they will allow any ENS name, in my opinion.

I actually think this is a legit use-case for subdomains though, using them as “premium domain space on our UI” that is still a global ENS name. We’ve considered something like this as a potential feature in our product down the line.

Interesting idea! You’d need to make sure whatever resolves this in frontends doesn’t rely on the owner updating this record if they lose beneficial ownership later, but it’s a start to a good signal perhaps.


In terms of normalization, all names should be a subset of the normalization spec, so they can all be parsed and resolved with one gadget. A subdomain could certainly let you register \u{200D}.domain.eth (solo ZWJ as a label) with their own UX, but no generic resolver application should accept that.

I like this idea. What’s the best implementation? Maybe something like:

  • The vitalik.coinbase.eth resolver could have setTrustedName(node, string) and trustedName(node) -> string, which in this case would return vitalik.eth. Alternatively, this could simply be a specific key of setText/text if the subdomain implemented TextResolver.

  • The trusted name vitalik.eth would be resolved and it’s resolver should implement TrustedResolver which has setTrust(node, external_node, bool) and isTrusted(node, external_node). (You could hack this into setAddr/addr for a proof of concept.)

  1. vitalik.eth would establish setTrust(namehash("vitalik.eth"), namehash("vitalik.coinbase.eth"), true)
  2. trustedName(namehash("vitalik.coinbase.eth"))"vitalik.eth"resolveisTrusted(namehash("vitalik.eth"), namehash("vitalik.coinbase.eth"))true?

I guess it’s kinda like approvals for ENS?


A many:many relationship would probably make more sense here, so you could call isTrusted(root, other) with namehashes.

But, I’m very cautious about adding this sort of complexity; in my experience such things frequently end up being little-used and add overhead to the system for little return


I just got scammed out of my ENS domain from a fake airdrop. My question is, if there is any way to prove this was a fraudulent transfer??

Not if you clicked on it, which you did