Two ways teams do usernames today
Almost every product that ships usernames picks one of two approaches. Both leave the user stuck at the same place. Plain usernames: usually displayed like@alice or alice. Fast to build, and inside your app they work exactly as intended. But the name only exists in your database. Send @alice to someone in another wallet or app, and it simply won’t work. Users are back to copying and pasting an address.
A custom TLD: something like alice.wallet or alice.pay, whatever reads well next to your brand name. This looks like the better option but it’s not. Your TLD isn’t in DNS and isn’t in ENS, so no wallet outside your product has any way to look it up. Making it work means asking every wallet, explorer, and app to integrate your naming system one at a time. Also, collisions are the other half of the problem: multiple projects have built competing versions of the same TLD, so alice.wallet can resolve to two different people depending on which app you ask.
A better way with ENS
Every username you’ve already issued gets a matching ENS name. One rule, applied across your whole user base:This does not turn
.brand into a new ENS top-level domain. Each user gets an ENS name for the identity they already have.ENS isn’t limited to .eth or Ethereum
Two (wrong) assumptions people usually make. You don’t need a.eth name.
happy.brand.eth and happy.brand.id resolve identically. The first means registering brand.eth. The second means taking a domain you already own, turning on DNSSEC, and importing it into ENS. Same result, so pick on branding.
ENS isn’t only for Ethereum.
One name holds a separate address record for every chain, and they don’t have to be EVM chains. Bitcoin, Solana, Base, Arbitrum, and Ethereum sit side by side on the same name, along with profile fields like display name and avatar. Your user has one name and it works everywhere they hold funds.
Follow one lookup
The diagram is a single name being looked up, start to finish. Its two toggles are the decisions above: the parent name, and where records are read from. Neither changes the path. It loops on its own. Hover to pause, or use the dots to step through it. Nothing there asked you to move your users, usernames, or records. The wallet asked a question, your system answered, the wallet showed the result.Your records stay where they are
Records can live in the database you run today, on an L2, or on another chain. No second registry on Ethereum, nothing to keep in sync. Whatever answers the question inside your product answers it here too.Decide before you build
- The naming rule. A parent name and a predictable pattern, such as
happy.brandbecominghappy.brand.eth. Nobody should have to learn a second identity. - Where the answer comes from. Your database, a contract in your existing registry, or a proof Ethereum can verify.
- Who runs it. Someone holds the parent name, keeps the lookup path online, and fixes it when it breaks.
What this does not do
- Your existing TLD does not become part of ENS. Users gain an ENS name;
.brandstays yours. - Support varies. Most major wallets resolve these names, but not every app does, so test the ones your users actually use.
- Anything served this way is public. Addresses, avatars, and profile fields are readable by anyone who asks.
Next steps
Learn about subnames
Compare offchain and onchain names before you pick how to issue them.
Issue gasless subnames
Create names and manage their records with the Offchain Manager SDK.
Talk to us
Bring your existing naming service and we will map it onto ENS with you.