ENSv2 will be deployed exclusively on Ethereum. Ethereum is scaling faster than almost anyone predicted two years ago; we've seen a 99% reduction in ENS registration gas costs over the past year, coinciding with Ethereum's gas limit increases from 30M to 60M in 2025. Users will still benefit from the improved user experience that ENSv2 brings, like single-step registration, purchases with stablecoins from any chain, and a new registry design. By staying on L1, we're aligning ENS with the strongest possible infrastructure guarantees, Ethereum itself.
When we started planning ENSv2 and Namechain two years ago, the decision to build our own L2 felt inevitable. Ethereum L1 was prohibitively expensive for most users, with gas prices regularly spiking to levels that made even basic ENS transactions cost tens of dollars. Huge L1 scalability was not part of the Ethereum roadmap and the message was clear that L2s were the way forward. We needed to meet our users where the ecosystem was heading, and that meant building Namechain.
Today, I'm writing to tell you that we've made the decision to deploy ENSv2 exclusively on Ethereum L1, and cease development of Namechain.
To be clear, deployment of ENSv2 will still happen. Ceasing development of Namechain does not affect or change our roadmap. Users across the ecosystem will be able to resolve names faster by having to only query one chain, not two. Almost all of what we've been working on to improve user experience for the past two years remains relevant and, indeed, essential.
Earlier this week, we announced the ENS App and ENS Explorer public alphas for users to begin testing our simpler registration flow, improved multi-chain support, flexible ownership models, and streamlined name management. The new contracts and apps are the core of ENSv2, and we are excited to continue to refine these products with user feedback in the months to come.
Put simply: Ethereum L1 is scaling, and it's scaling faster than almost anyone predicted two years ago. The recent Fusaka upgrade raised the gas limit to 60 million, a 2x increase from the beginning of 2025. Now Ethereum core developers are targeting 200 million gas limit targets in 2026, a 3x increase from today, and that's before any ZK upgrades land.
We've seen a 99% reduction in ENS registration gas costs over the past year, coinciding with Ethereum's gas limit increases from 30M to 60M in 2025. ENS name registration now costs less than 5 cents on average in gas, down from close to $5 in gas a year ago.
When we compare this to the complexity and operational overhead of running our own L2, the calculus has fundamentally shifted. For example, if we subsidized every single ENS transaction that occurred in 2025, we'd spend roughly $10,000 at current gas prices. Even at the highest gas prices we've observed post-Fusaka, that number only rises to around $250,000, which is still substantially less than running our own L2. These savings mean that we can begin exploring ways to subsidize Ethereum L1 gas costs for all .eth holders when ENSv2 is live.
ENS has always been built on a few core principles: preserving user sovereignty, maximizing utility for end users, maintaining stability of ownership, and minimizing surprise. When we designed Namechain, we worked hard to approach it in a maximally trustless and decentralized way. But the reality is that any L2 introduces additional trust assumptions and potential centralization points compared to Ethereum L1.
For Namechain, those compromises primarily involved upgradability of the rollup contracts and the potential for a centralized set of preconfers handling block production. If we routed all ENS resolution through Namechain, every user would inherit these tradeoffs. While we believe these compromises were reasonable given the gas cost environment of 2023, they're harder to justify today when L1 transactions are affordable and getting cheaper.
Under our original plan, virtually all ENS names would route through CCIP-Read gateways at launch. Legacy names would need CCIP-Read to resolve, and even new registrations would rely on it for the foreseeable future. This meant we'd be introducing a fundamental bottleneck into the resolution process for millions of names, all dependent on gateway infrastructure that would need to be rock-solid from day one.
Ethereum L1 offers something no L2 can fully replicate: the same security, decentralization, and liveness guarantees that have made Ethereum the foundation of onchain finance and much more. By staying on L1, we're aligning ENS with the strongest possible infrastructure guarantees.
It's important to be clear about what this decision doesn't mean. We're not giving up on the innovations that have defined our work over the past 18 months. The vast majority of our engineering effort has gone into ENSv2 itself: the new registry architecture, the improved ownership model, better handling of name expiration, and the flexibility that comes from giving each name its own registry.
All of that is still shipping. Users will still benefit from the dramatically improved user experience that ENSv2 brings. We've streamlined registration flow end to end, so users can register a name in fewer steps, using assets from any EVM chain without manual bridging or gas. The streamlined ENS App and comprehensive ENS Explorer are both now in public alpha.
In fact, without the additional complexity that cross-chain resolution would have required, we can deliver these improvements with greater confidence in their stability. The architecture is simpler, the failure modes are easier to reason about, and the operational burden is dramatically reduced.
Deciding to stay on L1 doesn't mean we're closing the door on L2s entirely. The flexibility of the ENSv2 architecture makes L2 names more interoperable. Our new registration flow abstracts the complexity crosschain transactions. ENS still supports resolution for more than 60 different blockchains, including Bitcoin, Solana, Celo, and so much more. As the Ethereum ecosystem continues to evolve, ENSv2 gives us the flexibility to embrace new innovations that make ENS more versatile and user-friendly.
In 1960, when Britain and France began developing Concorde, supersonic passenger flight seemed inevitable. Demand for jet travel was exploding, and the introduction of jet airliners had cut transatlantic travel time from 14 hours to 8. Concorde would cut it to 3.5 hours. It was widely believed to be not just technically viable but a great investment in the future of air travel. By the end of that decade, though, things were changing. Improved air traffic control and engineering had cut another hour off conventional flights. Overland supersonic flight had been banned in the US and most of Europe. Instead of a plane that could fly anywhere in half the time, Concorde was restricted to transoceanic routes with an eroding time advantage. But development continued—according to many, "we have got to the point of no return and we have to go on with it."
By late 1973, Concorde was nearly complete. Production aircraft were built, certification was almost done. Then the oil crisis hit, spiking fuel prices from $25 a barrel to $70 a barrel in 2025 dollars. While the rest of aviation focused on fuel efficiency, Concorde entered service with 3-4 times the fuel consumption per seat-mile of subsonic jets. Cancellation was politically impossible—the UK and French governments sold the planes to British Airways and Air France below cost and effectively forced them to operate the service. The Concorde project as a whole never turned a profit. The lesson isn't that ambitious engineering is a mistake, it's that the courage to change course while you still can is a form of leadership, and there's a window when change is painful but still possible.
We've invested significantly in Namechain—in partnerships, in technical development, in communicating our plans to the community. Many people think of ENSv2 and Namechain as synonymous. The social and reputational costs of changing direction now are real. But if we step back and ask ourselves honestly: "If we were starting today, knowing what we know about Ethereum's scaling progress and trajectory, would we build our own L2 for ENSv2?" The answer is clearly no. We find ourselves in that window where changing course is painful but still possible.
That doesn't mean the work on Namechain was wasted; we're implementing our learnings about L2 architecture to make ENS more interoperable with different L2s and importantly, make it simpler for end users. Those insights have made ENSv2 better and will continue to inform our technical decisions going forward.
ENSv2 is still coming. The new apps are available in alpha. Upgrading names to ENSv2 will be clearer and simpler than before. And ENS will continue to be built on the most decentralized, secure foundation available: Ethereum itself.