Scaling the Ethereum Name Service (ENS) to a billion users and beyond is the vision that’s been driving me to build on top of this protocol for over two years. As a Service Provider, DAO member, delegate, and ENS advocate, I wanted to share some thoughts on scaling ENS. This article is a culmination of my knowledge, my experience as a builder, and my personal insights.

Earlier this year, I organized the ENS x Chainlink side event during ETH Belgrade. At that event, I gave a talk titled “Scaling ENS to 1 Billion Users: Strategies for Mass Adoption of ENS.” Ever since then, I’ve wanted to put this into an article and share it with the world. This article does just that.

Not gonna spend too much time here as I expect people to know the basics already but — ENS is a decentralized, permissionless, and open naming protocol built on Ethereum. Soon, however, it will be on its own L2 chain called Namechain which will address some of the scaling issues and unlock a lot more opportunities for builders.

If you’re interested in learning more about ENSv2, here’s an ENSv2 development proposal where you can keep up with the latest discussions on this topic. If you’re interested in Namechain, you can watch frENSday presentation and read this thread.

Machine-readable → Human-readable

ENS can be used as a naming system for every digital resource, turning machine-readable hexadecimal strings into a human-readable format, making usability and user experience much better.

Censorship Resistance

ENS domains are self-custodial NFTs secured by your wallet’s private key. Therefore, building a website with a .eth domain and a content hash record protects you against censorship.

Security and scams

Address-related scams: address poisoning, address spoofing/mimicking, clipboard hijacking, identity impersonation, potentially even identity theft, and fraud if the .eth name gets stolen. ENS fixes all of these.

Web3 Identity Cold Start Problem

Every Dapp in Web3 requires a new profile setup which is time-consuming and can be fixed by having an ENS name/subname which requires one setup and is readable, visible, and accessible everywhere.

Siloed usernames

Currently, any Dapp usernames are stored on databases offchain and serve no purpose outside of their local environment, and can’t communicate with other Dapps’ usernames.

Web3 UX sucks 🍋

“ENS humanizes wallet addresses” is probably the coolest sentence that Crypto Twitter has ever said about ENS! It improves the Web3 user experience by turning hex addresses into human-readable (.eth) names or subnames. This makes the overall crypto experience more user-friendly, intuitive, and less scary and overwhelming for new users.

Map all crypto addresses to human-readable .eth names/subnames. 🥂

Before we get to the ‘how’ we scale ENS, we should talk about ‘why’ it’s important to scale it.

ENS has been called many names so far:

• a domain name, wallet name, digital identity, web3 username, universal profile, multichain passport, DID, NFT collection, but also a DAO, public good, open-source protocol, naming standard… and rightfully so. ENS is a multi-purpose naming protocol and spans across many industries.

Some of the notable industries (with use cases) where ENS is used include:

• wallets (wallet names), wallet-as-a-service providers (natively integrated as a service offering), blockchain tools and service providers (either natively integrated or enabled through their extension/plugin/add-on marketplace), gaming (in-game assets naming for players or land), DAOs (member/payroll management), communities (unified and cohesive group identity), registrars (domain/subdomain registrations), marketplaces (speculating and trading), social and knowledge graph protocols (a ‘name’ as a core identity piece), social networks (usernames/identity), communication protocols (natively added to the tech-stack), email clients (as digital identifiers), privacy-preserving dapps, and many others.

But probably most notably, ENS has entered the “Web3 Identity” industry that is currently going under the radar and hasn’t gotten as much attention as it deserves!

https://x.com/TheCapHimself/status/1813261099216540149

Identity starts with a name. For the most part. That makes ENS a Web3 identity primitive, a core building block for onchain identity, closely related to attestations, reputation, social graphs, and other identity primitives, that collectively participate in building systems that create our digital identities.

Because of its early launch, and popularity, along with public, open-source, modular infrastructure, thoughtful protocol design, good reputation, Ethereum-aligned values, detailed technical documentation, and vibrant ecosystem of partners, integrations, builders, developers, supporters, traders, and community members, (phew) ENS is now a general-purpose naming service for the entire Web3 world, or as we like to, half-jokingly, say ENS stands for Everything Naming Service.

ENS has evolved into so much more than a simple name service for decentralized websites as it initially started. Generally speaking, this is a good thing, but we have to acknowledge that ENS is trying to catch up with its growth and demand from everyone who uses it for different purposes, in different industries, and in different contexts. Thus, we need to scale it.

The best way to fix a problem, or to turn something good into something great, is to understand the root cause of a problem or the opportunity waiting to be seized. So, let’s start with the high-level issue, or as I like to call it, the Umbrella Problem.

The main problem we’re addressing is this: 0x addresses are simply not good enough for crypto mass adoption! If we want to onboard the next billion people into crypto, we need to present these addresses in a human-readable format, immediately.

We can’t expect parents, grandparents, and people from all walks of life—with varying backgrounds, knowledge, tech-savviness, and IQ points—to understand private keys, seed phrases, and cryptic public addresses. Relying on them to correctly copy and paste these complex strings every time they want to make a payment? That’s a recipe for disaster. Even experienced crypto users regularly fall victim to address-related scams and mistakes. If we don’t simplify this aspect, we’re setting up newcomers for failure, and mass adoption will remain a distant dream.

https://x.com/TheCapHimself/status/1828387001449546124

Quick side-track story because, well, ADHD brain: I recently read about a Hungarian doctor named Ignaz Semmelweis, who was ridiculed in his time for advocating that doctors, surgeons, and midwives regularly wash their hands before childbirth. In the 19th century, mortality rates were high among women who had just given birth due to something they called “childbed fever,” and the cause was unknown. Semmelweis observed that most deaths occurred when doctors and medical students attended births, compared to when midwives did. He noticed that doctors and students often went directly from performing surgeries and autopsies to examining patients in the maternity ward—without washing their hands in between. Deciding to test his hypothesis that handwashing would significantly reduce the mortality rate, he introduced a strict protocol using a chlorine solution before examinations. The results were immediate and dramatic. The mortality rate from “childbed fever” in the maternity ward dropped from around 18% to less than 2% almost overnight.

I’m not entirely sure why this story about Semmelweis reminded me of ENS. But much like Semmelweis’s theses, rooted in mere observation, I believe that having a human-readable name is an absolute necessity for mass crypto adoption. I firmly believe that integrating ENS would accelerate adoption by making the onboarding process easier and more intuitive for newcomers, especially in wallets, and save lots of funds in the future.

Anyway, back to our main story. We’ve identified our first and biggest problem: hexadecimal 0x addresses are not good enough for mass adoption and need to be suited up with human-readable .eth names. Great, so we agree we can do better. But what do we do about it, and where do we go from here? The technology already exists, it’s called ENS, and yet not everyone uses it or sees the immediate value it provides.

Well, let’s dissect that one. On to the next problem.

As an ENS Service Provider, I had an opportunity to integrate ENS with other projects, build custom solutions for others, build dapps on ENS, making subname registrations easy for non-tech users, easy to implement in dapps for developers, and much more! As my dear friend Marcus would say, I pretty much consider myself an ENS lifer now. But most notably, I worked on a lot of ENS-related partnerships and integrations for different industries and different contexts.

Everyone’s eyes light up when I talk about ENS! It’s irrefutable at this point that everyone loves ENS protocol and it has no equal by far. Anytime I would propose any type of integration, I would get an immediate yes! However, after we’d defined the scope of the integration, the enthusiasm would fade out.

I’ve realized that among builders, ENS is perceived as a vitamin, not a painkiller. It is perceived as something that doesn’t necessarily solve a problem and takes the pain away, but improves something and makes it a bit better.

Apart from this problem gradually being solved itself, as ENS keeps onboarding new projects and protocols and has more partnerships and integrations, this is a problem that gets solved by ongoing education, new users coming to crypto and hopefully preferring ‘names’ instead of ‘0x addresses’. We also solve this having measurable impact ENS integration on the user/customer satisfaction levels among projects ENS was integrated with.

I’ve recently advocated for more research-oriented reports for existing ENS implementations (such as cb.id) and turned them into a beautifully designed, insightful, and a joy to read Case Study of the entire integration. It could include: implementation details, technologies users, the results it brought, how it improved the wallet and its onboarding experience, increase in user count, user satisfaction level, promotional benefits through cross-collaborative marketing campaigns, etc. Which could later be used as an educational piece to educate and onboard new wallets.

Besides the ongoing challenges actively being addressed such as raising awareness for ENS (and crypto for that matter), educating the masses on what it does, what problems it solves, why you need it, how and where to get yourself this web3 username, etc. ENS faces something I call the “Vertical Growth Bottleneck” problem.

This highlights that the vast majority of ENS registrations (~70% of them) have come from a single source — the ENS app. This limits registration capacity to only one front end. I.e. You have to already know about ENS to get an ENS name or a subname which is the problem in itself and certainly a bottleneck for growth.

There are a few exceptions, such as Vision which offers bulk registrations besides regular ones, Space ID which is the aggregate of all web3 naming service providers, Rainbow wallet which supports in-wallet name registrations, Coinbase wallet which offers cb.id subnames when creating a Coinbase wallet, Uniswap wallet with uni.eth subnames, and a few others maybe and even though this is an early sign of ENS getting getting the attention it deserves, it’s not nearly enough. We only getting started. Or as Jesse from Base would say—it’s still day one!

Ok, what should we do? How do we fix this?

Think about what account abstraction did for wallets. It didn’t just enable smart account creation, batched transactions, and social recovery. Next to technical advancements, it allowed wallet creation to happen outside traditional wallet providers. Now, when you jump into some crypto game, it asks you to create an account (e.g. login with Google) and voilà! That’s your smart (wallet) account associated with the game. It’s not a prerequisite to have a wallet anymore to participate in the gaming industry and enjoy playing crypto games. This applies not only to games but all blockchain apps.

Now, think about ENS and its registration front ends. ENS names are mainly registered through the official ENS app (app.ens.domains) and some other domain registrars offering registration services. But when you add subname registrations into the mix, something wonderful happens. Subname registrations can occur outside the ENS app or third-party registrars, they can be implemented in every single Web3 app, across various contexts, and for countless purposes.

Just like account abstraction did for wallets—allowing anyone to essentially become a wallet provider by removing the complexities of requiring a wallet to use a blockchain dapp—the same principle can be applied to subname registrations. Every single blockchain dapp in Web3 can become an ENS subname registrar and start issuing (selling) names or subnames to their users, thus spreading the human-readable format as the official industry standard.

Just like you don’t need to know you’re creating a wallet when you go use some dapp or play some game, you don’t need to know you’re creating an ENS-powered username in those dapps or games.

And just like Account abstraction allowed anyone to become wallet providers, ENS—with its easy subname registration implementation—can allow anyone to become a web3 identity provider! And we at Namespace focus exactly on that!

To address the Vertical Growth Bottleneck and enable horizontal scaling, we need to diversify and increase the number of name and subname registration front ends and providers. To get there, we have to make ENS name and subname registrations easy to implement and accessible to all developers—in all development environments, among all major tooling services, and across all public and private dev libraries and blockchain tools and service providers.

So far, for the most part, ENS has been thought of as a read-heavy app. Because of that, most used libraries like WAGMI, Etheres.js, Viem, and others, support basic ENS read() operations, allowing you to get() all data associated with a name or address and resolve the name and all the records. None of them allow developers to implement ENS name or subname registrations for example which are becoming more and more important and present in major web3 apps. Not only that, but they are also necessary if we are to undergo this shift from machine-readable to human-readable wallet formats. Therefore, it’s time to shift the thinking from ‘read’ to ‘write’, and allow registrations, subnames, and record management from all of these places.

Then, and only then, can developers start integrating ENS into their products intuitively. This includes all decentralized apps, wallets, centralized exchanges (CEXes), Layer 2 chains, protocols, blockchain tools and service providers, games, communities, companies, institutions, DAOs, blogs, banks, social networks, you name it. The best way to do this right now, in my totally unbiased opinion, is to use Namespace SDK, which allows anyone to easily set up subname registrations either on our platform and their own websites or dapps.

Horizontal scaling doesn’t rely solely on developers alone. I believe the ENS community will also play a big role in becoming subname registration providers through their own projects: personal websites, linktrees, blogs, or custom pages built to sell subnames, whether for fun, for a cause, fundraising, bootstrapping, community access, token-gated benefits, or simply for flexing and the sheer profit of having a cool subname.

When it comes to ENS community I believe a great power lies within them. However, something that I see missing, and will be actively looking to address this gap, is incentives alignment.

However, building the right tools and apps for these two groups is easier said than done.

As I said before, to unlock horizontal scaling and enable seamless ENS integration and Subname registrations EvErYwHeRe. And we need to build the tools that make this possible.

There are two groups of people that could become front-end ENS name/subname registration providers and bring more name and subname registrations:

1. Blockchain devs – building cool dapps that would facilitate registrations

2. Non-tech users – ENS community selling them, trading them for fun or profit, and onboarding people to ENS and crypto

And we must focus on fixing all of the problems they might have, and build necessary tools, for adding ENS into their apps or allowing regular people to get a subname, by making the process simpler, smoother, and risk-free.

Great, what are some of the problems?

Most of these are not so much “problems” as much as they are verticles that I believe we can do better and help ENS improve. These are all that I believe would positively contribute to the growth of ENS in users and registered names/subnames.

For teams and devs

• ENS is present on L1 only which means high gas fees (for transacting, updating, extending, and building on top of ENS) which limits the usability and creative experimentation which usually creates new use cases. (it will be fixed with Namechain but in the meantime, ENS must work on all, or at least, major L2s)

• Meet developers where they already are - in familiar environments they use to build and deploy their dapps (blockchain tools and service providers)

• ENS is built to be modular and composable, so that it fits everyone’s needs through custom-built solutions, which makes case-specific implementation a challenge (not a priority) for less funded teams (I.e. games, wallets, communities, etc. all have specific custom requests).

• No out-of-the-box solutions for specific use cases to streamline ENS integration and adoption such as subname registrations for different industries.

• Building and running your own Offchain subname infrastructure requires time and domain expertise (CCIP-read, EVM gateway, custom resolvers, etc.) and custom solutions require dev resources, and time to hack it together, maintain, run, and upgrade it if necessary.

• Difficult implementation of minting and managing subnames and their records on different L2s.

• Lack of dev tooling services for ENS name/subname registration implementation. (we are fixing this).

• ENS ‘write’ operations need to be added to all public and private dev libraries and blockhain service providers that currently support just ENS ‘read’ operations, mainly resolution. Continously upgrade them (ethers.js, VIEM, ENSjs, web3js, WAGMI, and others) to support L2 subnames (minting + record management and resolution).

• Due to its evolving nature, it’s hard for public, most used web3 libraries, to keep up with constant changes and upgrades and ENSIPs.

• No clear or measurable value of customer satisfaction during the onboarding process with ENS subnames integrated.

• Not enough education on the importance of ENS and its benefits.

For non-tech users

• High TX fees on L1 for minting names, updating records, and renewing.

• No user-friendly platform for Subname selling, renting, management, and other features for nurturing the ENS non-tech community. (besides Namespace)

• No platforms other than Namespace offer customizing subname minting process on L1 and other L2 chains, custom prices, whitelisting, token-gating, etc.

• Lack of monetization opportunities - make ENS into dynamic assets that could generate revenue and be used for good.

• No ability for non-tech users to easily implement Subname registrations on their websites (working on ENS Widget 2.0 to fix this).

• Lack of education around entrepreneurial opportunities with ENS names, other than trading them. The only way to make money with an ENS names (right now) is to sell them, while you can sell subnames in many different use cases or rent them and make passive income.

• Making a platform that facilitates minting Subnames to be a fun, profitable, degen-friendly, and enjoyable process.

The way I observed it, scaling ENS happens on 3 different levels:

1. Infra level: protocol level stuff, NameWrapper upgrade, ENSv2 protocol upgrade, Namechain (L2 launch), ENSIPs, and other protocol improvements that often require a DAO vote.

2. Tooling level: different APIs, SDKs, and public libraries like WAGMI, ethers.js, ENSjs, Web3js, VIEM, etc. that allow probably 99% of developers to use ENS in their products.

3. App level: consumer-facing apps like marketplaces for trading, apps for subname issuance and management, dapps finding creative use cases for ENS and spreading adoption, or dapps using ENS as their core piece of infrastructure.

Each of these is evolving at its own pace, influenced by the new industry standards, innovations, and market needs and demands. They are actively nurtured by various parties associated with ENS, most notably Service Providers, and others:

• Infra: ENS Labs (Namechain, ENSv2, NameWrapper, etc.), Unruggable (L2 trustless gateways), Blockful ENSIP-16 improvements + ENSIP: Wildcard Writing, and others.

• Dev tooling: Namespace and Namestone on L2 subnames + Offchain subnames, ENS Labs on ENSjs, and others. Integrations with dev libraries and expanding their offering falls under this category as well.

• App level: Vision for trading and registrations, Namespace for Subname minting, ENSpro and Nameful for managing Offchain subnames, 3DNS and NameFi for tokenizing domains, ENS Fairy for gifting domains, FluidKey for private transitions via ENS subnames, Unicorn wallet for simplified onboarding experience using ENS names, etc.

  • Furthermore, all ENS partners, integrations, wallets, games, chains, etc. that use ENS for different purposes fall under this category.

There are others in the ENS Ecosystem associated with ENS. These are just some examples to demonstrate the difference between the 3 levels on which scaling occurs.

For ENS to stay on this dominant trajectory of being de facto naming system for Web3, it needs to continuously work on 4 things:

1. Technical improvements of the protocol

2. Increase in developer tooling and developer experience

3. Apps for ENS or that use ENS as a core

4. Integrations and Partnerships

These are very important for the growth of ENS and maintaining its #1 spot in the market. We should place an equal value on each of these and simultaneously work on them. Especially since we are moving into the ‘identity’ era and I’m expecting ENS to be used as a general-purpose naming service for everything web3.

This article has an additional 50 pages that I decided not to publish at the moment. I will schedule and publish them in the upcoming weeks to make it easier to read and less overwhelming.

Next, I will be focusing on what worked, still works, and will work in the future for ENS and where should we put our efforts to effectively scale ENS and solidify its position as an Everything Naming Service in Web3 forever.

The next articles will cover a more detailed analysis for scaling ENS with a specific focus on certain industries, verticals, opportunities, roles, user groups, Service Providers and their work so far, suggestions, predictions, etc.

As a sneak peek, here’s the summary of topics I will talk about. Even as a simple list like this and without me explaining anything about them further, they can guide your direction of thinking when it comes to ENS growth. But I look forward to talking more about them in the upcoming weeks and months:

1. L2 Subnames

   1. Rollup-as-a-Service + App chains

2. Integrations

   1. More dev tools

   2. Public web3 libraries

   3. Blockchain tools and service companies

   4. Projects, Dapps, Companies

   5. Institutions

3. Partnerships

   1. Wallets

   2. Wallet-as-a-Service providers (AA service: smart accounts)

   3. Social networks

   4. Games

   5. CEXes (mention trends here that they are launching their own wallets)

   6. Crypto payments

   7. Identity-related products

   8. Web3 browsers

   9. Brands

   10. Website builders

   11. Other consumer apps

4. Service Providers

5. Offchain Subnames

6. Registrars - registration providers (revenue sharing fee)

7. Strategy:

   1. GTM + biz dev + growth hacks + marketing + PR

8. ENS Labs

Cheers 🥂

Follow me on the journey (with my work with Namespace) of growing ENS to 1 billion users by subscribing here and following me on social media. 🫡

Cap X: @thecaphimself

• Cap Warpcast: thecap.eth

• Namespace X: @namespace_eth

• Namespace Warpcast: @namespace

Scaling the Ethereum Name Service (ENS) to a billion users and beyond is the vision that’s been driving me to build on top of this protocol for over two years. As a Service Provider, DAO member, delegate, and ENS advocate, I wanted to share some thoughts on scaling ENS. This article is a culmination of my knowledge, my experience as a builder, and my personal insights.

Earlier this year, I organized the ENS x Chainlink side event during ETH Belgrade. At that event, I gave a talk titled “Scaling ENS to 1 Billion Users: Strategies for Mass Adoption of ENS.” Ever since then, I’ve wanted to put this into an article and share it with the world. This article does just that.

Not gonna spend too much time here as I expect people to know the basics already but — ENS is a decentralized, permissionless, and open naming protocol built on Ethereum. Soon, however, it will be on its own L2 chain called Namechain which will address some of the scaling issues and unlock a lot more opportunities for builders.

If you’re interested in learning more about ENSv2, here’s an ENSv2 development proposal where you can keep up with the latest discussions on this topic. If you’re interested in Namechain, you can watch frENSday presentation and read this thread.

Machine-readable → Human-readable

ENS can be used as a naming system for every digital resource, turning machine-readable hexadecimal strings into a human-readable format, making usability and user experience much better.

Censorship Resistance

ENS domains are self-custodial NFTs secured by your wallet’s private key. Therefore, building a website with a .eth domain and a content hash record protects you against censorship.

Security and scams

Address-related scams: address poisoning, address spoofing/mimicking, clipboard hijacking, identity impersonation, potentially even identity theft, and fraud if the .eth name gets stolen. ENS fixes all of these.

Web3 Identity Cold Start Problem

Every Dapp in Web3 requires a new profile setup which is time-consuming and can be fixed by having an ENS name/subname which requires one setup and is readable, visible, and accessible everywhere.

Siloed usernames

Currently, any Dapp usernames are stored on databases offchain and serve no purpose outside of their local environment, and can’t communicate with other Dapps’ usernames.

Web3 UX sucks 🍋

“ENS humanizes wallet addresses” is probably the coolest sentence that Crypto Twitter has ever said about ENS! It improves the Web3 user experience by turning hex addresses into human-readable (.eth) names or subnames. This makes the overall crypto experience more user-friendly, intuitive, and less scary and overwhelming for new users.

Map all crypto addresses to human-readable .eth names/subnames. 🥂

Before we get to the ‘how’ we scale ENS, we should talk about ‘why’ it’s important to scale it.

ENS has been called many names so far:

• a domain name, wallet name, digital identity, web3 username, universal profile, multichain passport, DID, NFT collection, but also a DAO, public good, open-source protocol, naming standard… and rightfully so. ENS is a multi-purpose naming protocol and spans across many industries.

Some of the notable industries (with use cases) where ENS is used include:

• wallets (wallet names), wallet-as-a-service providers (natively integrated as a service offering), blockchain tools and service providers (either natively integrated or enabled through their extension/plugin/add-on marketplace), gaming (in-game assets naming for players or land), DAOs (member/payroll management), communities (unified and cohesive group identity), registrars (domain/subdomain registrations), marketplaces (speculating and trading), social and knowledge graph protocols (a ‘name’ as a core identity piece), social networks (usernames/identity), communication protocols (natively added to the tech-stack), email clients (as digital identifiers), privacy-preserving dapps, and many others.

But probably most notably, ENS has entered the “Web3 Identity” industry that is currently going under the radar and hasn’t gotten as much attention as it deserves!

https://x.com/TheCapHimself/status/1813261099216540149

Identity starts with a name. For the most part. That makes ENS a Web3 identity primitive, a core building block for onchain identity, closely related to attestations, reputation, social graphs, and other identity primitives, that collectively participate in building systems that create our digital identities.

Because of its early launch, and popularity, along with public, open-source, modular infrastructure, thoughtful protocol design, good reputation, Ethereum-aligned values, detailed technical documentation, and vibrant ecosystem of partners, integrations, builders, developers, supporters, traders, and community members, (phew) ENS is now a general-purpose naming service for the entire Web3 world, or as we like to, half-jokingly, say ENS stands for Everything Naming Service.

ENS has evolved into so much more than a simple name service for decentralized websites as it initially started. Generally speaking, this is a good thing, but we have to acknowledge that ENS is trying to catch up with its growth and demand from everyone who uses it for different purposes, in different industries, and in different contexts. Thus, we need to scale it.

The best way to fix a problem, or to turn something good into something great, is to understand the root cause of a problem or the opportunity waiting to be seized. So, let’s start with the high-level issue, or as I like to call it, the Umbrella Problem.

The main problem we’re addressing is this: 0x addresses are simply not good enough for crypto mass adoption! If we want to onboard the next billion people into crypto, we need to present these addresses in a human-readable format, immediately.

We can’t expect parents, grandparents, and people from all walks of life—with varying backgrounds, knowledge, tech-savviness, and IQ points—to understand private keys, seed phrases, and cryptic public addresses. Relying on them to correctly copy and paste these complex strings every time they want to make a payment? That’s a recipe for disaster. Even experienced crypto users regularly fall victim to address-related scams and mistakes. If we don’t simplify this aspect, we’re setting up newcomers for failure, and mass adoption will remain a distant dream.

https://x.com/TheCapHimself/status/1828387001449546124

Quick side-track story because, well, ADHD brain: I recently read about a Hungarian doctor named Ignaz Semmelweis, who was ridiculed in his time for advocating that doctors, surgeons, and midwives regularly wash their hands before childbirth. In the 19th century, mortality rates were high among women who had just given birth due to something they called “childbed fever,” and the cause was unknown. Semmelweis observed that most deaths occurred when doctors and medical students attended births, compared to when midwives did. He noticed that doctors and students often went directly from performing surgeries and autopsies to examining patients in the maternity ward—without washing their hands in between. Deciding to test his hypothesis that handwashing would significantly reduce the mortality rate, he introduced a strict protocol using a chlorine solution before examinations. The results were immediate and dramatic. The mortality rate from “childbed fever” in the maternity ward dropped from around 18% to less than 2% almost overnight.

I’m not entirely sure why this story about Semmelweis reminded me of ENS. But much like Semmelweis’s theses, rooted in mere observation, I believe that having a human-readable name is an absolute necessity for mass crypto adoption. I firmly believe that integrating ENS would accelerate adoption by making the onboarding process easier and more intuitive for newcomers, especially in wallets, and save lots of funds in the future.

Anyway, back to our main story. We’ve identified our first and biggest problem: hexadecimal 0x addresses are not good enough for mass adoption and need to be suited up with human-readable .eth names. Great, so we agree we can do better. But what do we do about it, and where do we go from here? The technology already exists, it’s called ENS, and yet not everyone uses it or sees the immediate value it provides.

Well, let’s dissect that one. On to the next problem.

As an ENS Service Provider, I had an opportunity to integrate ENS with other projects, build custom solutions for others, build dapps on ENS, making subname registrations easy for non-tech users, easy to implement in dapps for developers, and much more! As my dear friend Marcus would say, I pretty much consider myself an ENS lifer now. But most notably, I worked on a lot of ENS-related partnerships and integrations for different industries and different contexts.

Everyone’s eyes light up when I talk about ENS! It’s irrefutable at this point that everyone loves ENS protocol and it has no equal by far. Anytime I would propose any type of integration, I would get an immediate yes! However, after we’d defined the scope of the integration, the enthusiasm would fade out.

I’ve realized that among builders, ENS is perceived as a vitamin, not a painkiller. It is perceived as something that doesn’t necessarily solve a problem and takes the pain away, but improves something and makes it a bit better.

Apart from this problem gradually being solved itself, as ENS keeps onboarding new projects and protocols and has more partnerships and integrations, this is a problem that gets solved by ongoing education, new users coming to crypto and hopefully preferring ‘names’ instead of ‘0x addresses’. We also solve this having measurable impact ENS integration on the user/customer satisfaction levels among projects ENS was integrated with.

I’ve recently advocated for more research-oriented reports for existing ENS implementations (such as cb.id) and turned them into a beautifully designed, insightful, and a joy to read Case Study of the entire integration. It could include: implementation details, technologies users, the results it brought, how it improved the wallet and its onboarding experience, increase in user count, user satisfaction level, promotional benefits through cross-collaborative marketing campaigns, etc. Which could later be used as an educational piece to educate and onboard new wallets.

Besides the ongoing challenges actively being addressed such as raising awareness for ENS (and crypto for that matter), educating the masses on what it does, what problems it solves, why you need it, how and where to get yourself this web3 username, etc. ENS faces something I call the “Vertical Growth Bottleneck” problem.

This highlights that the vast majority of ENS registrations (~70% of them) have come from a single source — the ENS app. This limits registration capacity to only one front end. I.e. You have to already know about ENS to get an ENS name or a subname which is the problem in itself and certainly a bottleneck for growth.

There are a few exceptions, such as Vision which offers bulk registrations besides regular ones, Space ID which is the aggregate of all web3 naming service providers, Rainbow wallet which supports in-wallet name registrations, Coinbase wallet which offers cb.id subnames when creating a Coinbase wallet, Uniswap wallet with uni.eth subnames, and a few others maybe and even though this is an early sign of ENS getting getting the attention it deserves, it’s not nearly enough. We only getting started. Or as Jesse from Base would say—it’s still day one!

Ok, what should we do? How do we fix this?

Think about what account abstraction did for wallets. It didn’t just enable smart account creation, batched transactions, and social recovery. Next to technical advancements, it allowed wallet creation to happen outside traditional wallet providers. Now, when you jump into some crypto game, it asks you to create an account (e.g. login with Google) and voilà! That’s your smart (wallet) account associated with the game. It’s not a prerequisite to have a wallet anymore to participate in the gaming industry and enjoy playing crypto games. This applies not only to games but all blockchain apps.

Now, think about ENS and its registration front ends. ENS names are mainly registered through the official ENS app (app.ens.domains) and some other domain registrars offering registration services. But when you add subname registrations into the mix, something wonderful happens. Subname registrations can occur outside the ENS app or third-party registrars, they can be implemented in every single Web3 app, across various contexts, and for countless purposes.

Just like account abstraction did for wallets—allowing anyone to essentially become a wallet provider by removing the complexities of requiring a wallet to use a blockchain dapp—the same principle can be applied to subname registrations. Every single blockchain dapp in Web3 can become an ENS subname registrar and start issuing (selling) names or subnames to their users, thus spreading the human-readable format as the official industry standard.

Just like you don’t need to know you’re creating a wallet when you go use some dapp or play some game, you don’t need to know you’re creating an ENS-powered username in those dapps or games.

And just like Account abstraction allowed anyone to become wallet providers, ENS—with its easy subname registration implementation—can allow anyone to become a web3 identity provider! And we at Namespace focus exactly on that!

To address the Vertical Growth Bottleneck and enable horizontal scaling, we need to diversify and increase the number of name and subname registration front ends and providers. To get there, we have to make ENS name and subname registrations easy to implement and accessible to all developers—in all development environments, among all major tooling services, and across all public and private dev libraries and blockchain tools and service providers.

So far, for the most part, ENS has been thought of as a read-heavy app. Because of that, most used libraries like WAGMI, Etheres.js, Viem, and others, support basic ENS read() operations, allowing you to get() all data associated with a name or address and resolve the name and all the records. None of them allow developers to implement ENS name or subname registrations for example which are becoming more and more important and present in major web3 apps. Not only that, but they are also necessary if we are to undergo this shift from machine-readable to human-readable wallet formats. Therefore, it’s time to shift the thinking from ‘read’ to ‘write’, and allow registrations, subnames, and record management from all of these places.

Then, and only then, can developers start integrating ENS into their products intuitively. This includes all decentralized apps, wallets, centralized exchanges (CEXes), Layer 2 chains, protocols, blockchain tools and service providers, games, communities, companies, institutions, DAOs, blogs, banks, social networks, you name it. The best way to do this right now, in my totally unbiased opinion, is to use Namespace SDK, which allows anyone to easily set up subname registrations either on our platform and their own websites or dapps.

Horizontal scaling doesn’t rely solely on developers alone. I believe the ENS community will also play a big role in becoming subname registration providers through their own projects: personal websites, linktrees, blogs, or custom pages built to sell subnames, whether for fun, for a cause, fundraising, bootstrapping, community access, token-gated benefits, or simply for flexing and the sheer profit of having a cool subname.

When it comes to ENS community I believe a great power lies within them. However, something that I see missing, and will be actively looking to address this gap, is incentives alignment.

However, building the right tools and apps for these two groups is easier said than done.

As I said before, to unlock horizontal scaling and enable seamless ENS integration and Subname registrations EvErYwHeRe. And we need to build the tools that make this possible.

There are two groups of people that could become front-end ENS name/subname registration providers and bring more name and subname registrations:

1. Blockchain devs – building cool dapps that would facilitate registrations

2. Non-tech users – ENS community selling them, trading them for fun or profit, and onboarding people to ENS and crypto

And we must focus on fixing all of the problems they might have, and build necessary tools, for adding ENS into their apps or allowing regular people to get a subname, by making the process simpler, smoother, and risk-free.

Great, what are some of the problems?

Most of these are not so much “problems” as much as they are verticles that I believe we can do better and help ENS improve. These are all that I believe would positively contribute to the growth of ENS in users and registered names/subnames.

For teams and devs

• ENS is present on L1 only which means high gas fees (for transacting, updating, extending, and building on top of ENS) which limits the usability and creative experimentation which usually creates new use cases. (it will be fixed with Namechain but in the meantime, ENS must work on all, or at least, major L2s)

• Meet developers where they already are - in familiar environments they use to build and deploy their dapps (blockchain tools and service providers)

• ENS is built to be modular and composable, so that it fits everyone’s needs through custom-built solutions, which makes case-specific implementation a challenge (not a priority) for less funded teams (I.e. games, wallets, communities, etc. all have specific custom requests).

• No out-of-the-box solutions for specific use cases to streamline ENS integration and adoption such as subname registrations for different industries.

• Building and running your own Offchain subname infrastructure requires time and domain expertise (CCIP-read, EVM gateway, custom resolvers, etc.) and custom solutions require dev resources, and time to hack it together, maintain, run, and upgrade it if necessary.

• Difficult implementation of minting and managing subnames and their records on different L2s.

• Lack of dev tooling services for ENS name/subname registration implementation. (we are fixing this).

• ENS ‘write’ operations need to be added to all public and private dev libraries and blockhain service providers that currently support just ENS ‘read’ operations, mainly resolution. Continously upgrade them (ethers.js, VIEM, ENSjs, web3js, WAGMI, and others) to support L2 subnames (minting + record management and resolution).

• Due to its evolving nature, it’s hard for public, most used web3 libraries, to keep up with constant changes and upgrades and ENSIPs.

• No clear or measurable value of customer satisfaction during the onboarding process with ENS subnames integrated.

• Not enough education on the importance of ENS and its benefits.

For non-tech users

• High TX fees on L1 for minting names, updating records, and renewing.

• No user-friendly platform for Subname selling, renting, management, and other features for nurturing the ENS non-tech community. (besides Namespace)

• No platforms other than Namespace offer customizing subname minting process on L1 and other L2 chains, custom prices, whitelisting, token-gating, etc.

• Lack of monetization opportunities - make ENS into dynamic assets that could generate revenue and be used for good.

• No ability for non-tech users to easily implement Subname registrations on their websites (working on ENS Widget 2.0 to fix this).

• Lack of education around entrepreneurial opportunities with ENS names, other than trading them. The only way to make money with an ENS names (right now) is to sell them, while you can sell subnames in many different use cases or rent them and make passive income.

• Making a platform that facilitates minting Subnames to be a fun, profitable, degen-friendly, and enjoyable process.

The way I observed it, scaling ENS happens on 3 different levels:

1. Infra level: protocol level stuff, NameWrapper upgrade, ENSv2 protocol upgrade, Namechain (L2 launch), ENSIPs, and other protocol improvements that often require a DAO vote.

2. Tooling level: different APIs, SDKs, and public libraries like WAGMI, ethers.js, ENSjs, Web3js, VIEM, etc. that allow probably 99% of developers to use ENS in their products.

3. App level: consumer-facing apps like marketplaces for trading, apps for subname issuance and management, dapps finding creative use cases for ENS and spreading adoption, or dapps using ENS as their core piece of infrastructure.

Each of these is evolving at its own pace, influenced by the new industry standards, innovations, and market needs and demands. They are actively nurtured by various parties associated with ENS, most notably Service Providers, and others:

• Infra: ENS Labs (Namechain, ENSv2, NameWrapper, etc.), Unruggable (L2 trustless gateways), Blockful ENSIP-16 improvements + ENSIP: Wildcard Writing, and others.

• Dev tooling: Namespace and Namestone on L2 subnames + Offchain subnames, ENS Labs on ENSjs, and others. Integrations with dev libraries and expanding their offering falls under this category as well.

• App level: Vision for trading and registrations, Namespace for Subname minting, ENSpro and Nameful for managing Offchain subnames, 3DNS and NameFi for tokenizing domains, ENS Fairy for gifting domains, FluidKey for private transitions via ENS subnames, Unicorn wallet for simplified onboarding experience using ENS names, etc.

  • Furthermore, all ENS partners, integrations, wallets, games, chains, etc. that use ENS for different purposes fall under this category.

There are others in the ENS Ecosystem associated with ENS. These are just some examples to demonstrate the difference between the 3 levels on which scaling occurs.

For ENS to stay on this dominant trajectory of being de facto naming system for Web3, it needs to continuously work on 4 things:

1. Technical improvements of the protocol

2. Increase in developer tooling and developer experience

3. Apps for ENS or that use ENS as a core

4. Integrations and Partnerships

These are very important for the growth of ENS and maintaining its #1 spot in the market. We should place an equal value on each of these and simultaneously work on them. Especially since we are moving into the ‘identity’ era and I’m expecting ENS to be used as a general-purpose naming service for everything web3.

This article has an additional 50 pages that I decided not to publish at the moment. I will schedule and publish them in the upcoming weeks to make it easier to read and less overwhelming.

Next, I will be focusing on what worked, still works, and will work in the future for ENS and where should we put our efforts to effectively scale ENS and solidify its position as an Everything Naming Service in Web3 forever.

The next articles will cover a more detailed analysis for scaling ENS with a specific focus on certain industries, verticals, opportunities, roles, user groups, Service Providers and their work so far, suggestions, predictions, etc.

As a sneak peek, here’s the summary of topics I will talk about. Even as a simple list like this and without me explaining anything about them further, they can guide your direction of thinking when it comes to ENS growth. But I look forward to talking more about them in the upcoming weeks and months:

1. L2 Subnames

   1. Rollup-as-a-Service + App chains

2. Integrations

   1. More dev tools

   2. Public web3 libraries

   3. Blockchain tools and service companies

   4. Projects, Dapps, Companies

   5. Institutions

3. Partnerships

   1. Wallets

   2. Wallet-as-a-Service providers (AA service: smart accounts)

   3. Social networks

   4. Games

   5. CEXes (mention trends here that they are launching their own wallets)

   6. Crypto payments

   7. Identity-related products

   8. Web3 browsers

   9. Brands

   10. Website builders

   11. Other consumer apps

4. Service Providers

5. Offchain Subnames

6. Registrars - registration providers (revenue sharing fee)

7. Strategy:

   1. GTM + biz dev + growth hacks + marketing + PR

8. ENS Labs

Cheers 🥂

Follow me on the journey (with my work with Namespace) of growing ENS to 1 billion users by subscribing here and following me on social media. 🫡

Cap X: @thecaphimself

• Cap Warpcast: thecap.eth

• Namespace X: @namespace_eth

• Namespace Warpcast: @namespace