ENS Labs Quarterly Report- Q2 2026
Abstract
Q2 was about getting ENSv2 ready for Beta and Mainnet. ENS started with a simple problem: addresses are unreadable. But eight years later, ENS isn’t just making Ethereum addresses legible, but also serving as a human-readable reference for 60+ blockchains, offchain naming systems, content, agents, and other types of records. The protocol itself needs to be both predictable for apps and users that have been around for the last half decade, yet still needs to evolve to how blockchains are being used today.
That’s harder than it sounds, because ENSv2 has to satisfy audiences that require different things. Existing name holders need the upgrade to be safe and predictable. On the other hand, potential new users unfamiliar with wallets need to acquire a .eth name easily. And finally, wallets, apps, and libraries already integrated with ENS need to better resolve the many types of ENS names that now exist. With all this in mind, there were two major decision points that affected how we thought about and designed for v2.
The first was Hidden Contract Accounts (HCA), the smart-account model meant to let people register, renew, and manage names through the ENS App without thinking about gas or which chain they’re on. We made the tough decision to not build the HCA directly into the protocol, and instead require an explicit user opt-in (a one-time L1 transaction). We think we made the right tradeoff to maintain ownership guarantees, but it will come at some cost to the user. Advanced operations like resolver changes and transfers still require L1 ETH for users who haven’t deployed their HCA, though those who have will get a lifetime approval rather than per-transaction costs, and the architectural shift meant significant rework across the protocol design and front-end integration.
The second was choosing BigName, an indexer we built ourselves, over alternatives, as the production indexer for the V4 apps and Coinbase’s Base App at Mainnet. The case for it is architectural: it’s built from the ground up to index ENSv1, ENSv2, and Basenames, and better supports replay history and verified data. It’s also the harder path short-term, which is why Beta will run on the existing indexer, while BigName will go live as part of Mainnet.
Both technical decisions are about making sure ENSv2 is something existing users and existing integrations can rely on. The sections below cover how that played out across protocol, product, design, engineering, and the wider ENS ecosystem.
Re-architecting the HCA
One of the most consequential decisions this quarter was the re-architecture of HCAs. The original model was designed to give users a default smart account that could support gasless, sponsored, cross-chain interactions through account abstraction standards ERC-4337 and ERC-7579. The goal reflected the kind of experience ENSv2 should make possible: users should be able to register, renew, and manage names without constantly thinking about bridging, gas fees, or which chain they are on.
As the implementation matured, the team identified a deeper issue with the protocol-enshrined model. It created a new risk surface where DAO-level control could become broader than it is in ENSv1, potentially affecting name ownership rights.
The reworked model now requires explicit user opt-in through a one-time L1 transaction rather than automatically upgrading users into a protocol-recognized smart account. That choice preserves support for cross-chain registration and renewal while materially reducing the ownership-risk assumptions that made the original design uncomfortable. The change also creates real tradeoffs: advanced actions such as resolver changes, subname issuance, and secondary transfers still require L1 ETH.
This is the kind of decision that can look like a delay from the outside and feel like scope expansion on the inside. The point of ENSv2 is not to make every interaction smoother at any cost; it is to make ENS more powerful while preserving the guarantees that make the system worth trusting.
The same principle shaped the work on migration safety. The team resolved a V1 grace-period conflict by extending all names by 62 days, building the “graveyard” daemon, and preparing a V1 contract change to clear records on expiry so that re-registration on V2 is safe. Migration is where the protocol stops being theoretical and meets existing name holders where they are, including those with names in grace or using old resolvers.
Both of these decisions scope and affect the launch timeline, but it ultimately were the right ones. ENSv2 cannot trade ownership guarantees for speed. The team continued coordinating with two audit firms, completed formal verification work, and worked through the remaining implementation details with Rhinestone, with the same standard in mind: the protocol has to be safe enough before it can be launch-ready.
From Protocol Complexity to User-Ready Products
One of the more revealing parts of ENSv2 is the split between the ENS App and ENS Explorer.
- The ENS App is where most users should be able to register, renew, migrate, and manage names without needing to understand every detail under the hood.
- The Explorer is where builders, power users, support teams, and curious users should be able to see what is happening when a name resolves, changes, inherits permissions, or moves through the system.
That split shaped much of the product and design work in Q2. The Manager and Explorer were brought to Beta release readiness, including the V1-to-V2 upgrade experience, new registration and renewal screens reflecting updated pricing and grace-period behavior, new profiles and profile editing, entity highlighting in Explorer, registry contract views, role surfaces, address views, and a series of UX improvements that together make the system easier to navigate.
The upgrade flow is a good example of the kind of work that looks simple only when it has been designed well. It needed to handle locked names, locked resolvers, names that could not be upgraded to V2, eligibility checks, gas estimation, and record history without turning the experience into a checklist of protocol edge cases.
Pricing and grace-period work followed the same pattern. In April, we proposed two changes to .eth registration pricing to take effect with the ENSv2 launch: a multi-year registration discount and an increase in the annual registration fee for names with five or more characters from $5 to $8 per year.
The Product and Design teams translated the DAO-approved pricing changes into registration screens, pricing tiers, grace-period messaging, reminder communications, and the new “price cooldown” experience. The design work around the multi-year discount curve and tier structure also fed directly into the registration contracts, showing how research, governance feedback, product design, and protocol implementation came together.
ENS Explorer work addressed the other side of the same trust equation. As ENSv2 makes names more dynamic, the system naturally becomes more complex: role-based permissions can be assigned, registries can operate independently, names can be nested, and historical context becomes more important. The team’s prioritization helped us deliver on several features planned for the Beta launch, including the migration flow, pricing and grace period updates, Explorer entity highlighting, and the registry contract interface.
These product and protocol upgrades were a culmination of work across product, design, frontend, and QA over more than six two-week sprints, supported by weekly check-ins, and a design-one-sprint-ahead model. This new team process matters for a launch with this many dependencies.
Finally, Design and Marketing collaborated on a planned redesign of the ENS Domains website. An early review established what the site needs to communicate in the ENSv2 era and how to make the site feel less like a brochure and more like an explanation of how ENS benefits both individual users and organizations.
Building Reliable Infrastructure
Q2 Web Engineering work focused on the parts of ENSv2 that users should not have to think about but absolutely depend on: indexing, signing, payment paths, metadata, profile rendering, migration state, and resolver visibility. These are the details that determine whether ENSv2 feels reliable when a user registers, renews, migrates, edits, or shares a name.
Indexing is one of the clearest examples of the invisible work users depend on without ever seeing. In June, the team selected BigName, an internally built indexer, as the single production indexer for the V4 apps and Coinbase’s Base App at Mainnet launch. ENSv2 needs an indexing layer that can understand ENSv1, ENSv2, and Basenames together, replay changes cleanly, reconstruct historical name state, support verified-mode and provenance as first-class concepts, and remain extensible as the protocol keeps evolving.
BigName gives us the strongest path because it was built around that model from the start.
Its Command Query Responsibility Segregation (CQRS) / event-sourced architecture separates immutable raw facts from rebuildable current-state projections, so most changes can be replayed from the event log instead of re-indexing the chain. That gives us cleaner reorg handling, reconstructable name state at past blocks, and one indexing model across ENSv1, ENSv2, and Basenames.
The team did assess other options, but each had tradeoffs that made them less suitable for Mainnet. One internal option remains useful as a conformance reference, but it was V2-only, based on an ENSv1-shaped schema, and did not have the event log needed to cover ENSv1 plus Basenames or replay reorgs cleanly. One external option was more production-ready and Subgraph-compatible, but our ideal solution for indexing requires granular replay, historical reconstruction, and per-call verified-mode guarantees. Additionally its current-state model does not provide the same granular replay, historical reconstruction, or per-call verified-mode guarantees that BigName does.
For Beta, the existing indexer will stay in place while BigName moves toward ENSv2 Mainnet readiness.
Other key infrastructure decisions & progress during Q2:
- Apps V2-Readiness: ENS Manager & Explorer running against the V2 Sepolia deployment, with the hi-fi redesign, and V2 functionality close to feature-completion.
- Service Integrations: Work included an MVP of the Metadata service, an investigation into gas-sponsorship, Rhinestone integration, and cross-chain settlement for ETH and USDC swapping for name payment.
- Wallet Login: We continue to assess wallet login and credit card payment options against our key requirements, including headless integration, control over Wagmi, and ease of use. This work will continue post v2 as we work to expand the types of users that we can onboard into ENS.
- Maintenance & Policy: Work included fixes across Manager/Explorer (records display, My Names owner/manager fields) and CSP/gateway handling.
This work also required close coordination with external partners, including Rhinestone on payments and HCA, Crossmint on card checkout, Coinbase on indexer requirements such as batch indexing and Base support, and Rainbow plus others on CSP and gateway resolution issues.
The team also worked through several blockers, including HCA/account-abstraction architecture impacting frontend PRs, troubleshooting the App and Explorer environments, and working through an ownership-display issue caused by the V1 subgraph not cleaning up WrappedDomain entities after expired wrapped names were re-registered. Fortunately, the team was able to fix it through the ENS subgraph indexer, reinforcing how much launch readiness depends on the underlying infrastructure behaving reliably before users encounter it.
ENSv2: Ecosystem Upgrade
ENSv2 launches everywhere that ENS already exists: wallets, apps, exchanges, libraries, developer tools, and the interfaces people use without thinking about the naming infrastructure underneath.
To prepare the developer ecosystem this quarter, we focused on that readiness through a structured partner-readiness program, triaging partner support, ensuring they are ready for ENSv2, and unblocking library integrations across Ethers.js v6, web3.py, web3j, and go-ens. The work included direct readiness support with teams including MetaMask, Uniswap App, Ledger, Kraken Wallet, OpenSea, Safe, and Aave. On the longer tail, we were able to increase the number of ENSv2 ready repositories on Github from 21% to 38%. Follow this guide to make your application ENSv2 ready and reach out in the ENS Developer Telegram group for tailored support and potential co-marketing.
Documentation and tooling formed another part of the readiness effort. ENSv2 documentation was prepared ahead of Beta launch, the ENS CLI was released as a developer preview for agentic workflows, and ENSIP-26 continued to progress alongside the collaboration with GoDaddy on Agent Name Service. The growing need for AI agent identity infrastructure remains a priority as ENS works to maintain a leading role in this emerging space.
On the hackathon front, we were able to stress test the builder and developer experience. Across ETHGlobal Cannes, ETHPrague, ETHCC[9], ETHConf, and ETHGlobal New York, we were able to see where builders got excited, where they got stuck, and what needed to become clearer before Mainnet.
At ETHGlobal New York, 44% of teams built on ENS, the highest rate for any Tier 1 in-person hackathon, while the ENS Developers Telegram grew from 600 to 700+ members.
Winning hackathon projects worth highlighting of this quarter: Veil VPN (Cannes), ETHesis (Prague), Ghost in the Machine (Cannes), Kondor (Cannes), Phare (Prague).
Our work on ecosystem growth and strategic partnerships connected directly to this readiness effort. We focused on securing commitments from leading wallets and apps that are V2-ready and willing to support a coordinated co-marketing campaign around launch. That coordination only works if the technical work is real, and the technical work lands better when partners are also empowered on how to explain ENSv2 to their own users.
The quarter reinforced that ENSv2 readiness is both technical and social. Partners need Universal Resolver support, but they also need launch calendars, approved messaging, integration confidence, and enough clarity to know what the upgrade unlocks for their users. Getting those pieces to move at the same pace is crucial.
Setting the Migration Path for Success
A protocol upgrade can be technically sound and still fail to land with users if people do not understand what changed or why it matters. Across all teams, Q2 focused on developing the narrative, creative direction, and campaign readiness around ENSv2 so that launch feels like a major protocol milestone, not simply a maintenance notice with new branding.
To begin building awareness, we released the ENSv2 explainer video and published deep dives into the ENS App and ENS Explorer, giving users and developers a substantive preview of the product philosophy behind the two new applications.
- ENS App’s (https://app.ens.dev/) story is about designing through subtraction: hiding complexity where users do not need it and turning registration and management into flows the system can orchestrate.
- ENS Explorer’s (https://explorer.ens.dev/) story is about legibility: surfacing the full state of a name so that the protocol becomes easier to understand, rather than more opaque, as it becomes more powerful.
Growth and marketing efforts continued developing the broader ENS narrative in preparation for Beta launch. Including published pieces on hierarchical naming, practical onchain use cases, onchain identity as public infrastructure, and how ENS is the extension into the digital world for why humans name everything. These pieces help explain why ENSv2 is not only about a new set of contracts, but about making ENS more capable as the coordination layer for identity across the internet.
We also prioritized IRL events this quarter to continue building the hype for ENSv2.
We were the title sponsor of PizzaDAO’s Global Pizza Day, with 32,000+ RSVPs and more than 370 official events worldwide, over 1 million impressions, and 6,400 wallets submitted to receive ENS subnames.
We also showed up at the Agentic Finance Summit, ETHConf, and Refraction’s IRL Tour, with a mix of cultural reach, technical partner work, and institution-facing conversations. Check out Katherine’s talk at ETHConf in June on the Next Era of ENS.
The main coordination challenge was making sure launch readiness did not move ahead of security and audit work. Rather than letting the campaign calendar drive the protocol, the team used Q2 to keep partner readiness, co-marketing plans, creative assets, and launch-day content moving in parallel, ready to launch when the new protocol lands on Mainnet.
While v2 readiness was the primary objective for the Growth team, there were a few additional wins with organizations and sectors beginning to move onchain in meaningful ways. We partnered with DOMA on a primary name campaign which brought in 300+ newly set ENS primary names. Additionally, users can now use DOMA to set their tokenized DNS as their ENS name. Türkiye’s Directorate of Communication registered `cbiletisim.eth`, making its first step in establishing an official onchain identity by choosing ENS. Read more here.
Stewardship Required for Launch
As ENS becomes more widely used, the work around the protocol expands. Code and product remain central, but ENS also depends on the surrounding layers that make infrastructure durable: legal structure, security posture, IP protection, governance support, and external partner standards.
This quarter, we focused on establishing that infrastructure for ENSv2 across IP, patent, cybersecurity, and commercial efforts. We filed the ENSv2 patent application in the US through USPTO Track One expedited examination, advanced protection for ENS (USSN 99179803), ENS Design / logo (USSN 99179808), and FRENSDAY (USSN 99186369). As mentioned in the ENS Foundation Temp Check v2, the ENS Foundation is planned to manage the trademark ownership and enforcement, as well as the patents and “intangible assets” (e.g. brand, legal).
Security and compliance work also continued to scale with ENS’s footprint. We strengthened access control, incident response, and threat-intelligence work through partnerships with Quad9 and CleanerDNS, supported the eth.limo incident response and abuse-desk operations, drove Immunefi bug bounty revisions, and filed a police report with the Korean National Police Agency concerning malicious activity directed toward ENS. More adoption brings more attention, and more attention means the operational security surface has to keep maturing.
As part of our commitment to ENS’ role in the DNS Security space, we represented at the 2026 ICANN Contracted Parties Summit in Manchester, DNS OARC 46 in Edinburgh, and the ICANN86 Policy Forum in Seville.
Our work has strengthened relationships with registries, WIPO, and the contracted-party community, advanced our .ens gTLD preparation, and increased ENS visibility in technical, policy, and media discussions around naming systems, digital identity, and AI. Check out more in Slobo’s ICANN86 Seville key takeaways.
Another Q2 significant outcome was Nick’s appointment to ICANN’s new seven-member Technical Study Group on gTLD integrations with alternative naming systems. A lot of projects talk about replacing old infrastructure, but the harder and more useful work is making new infrastructure compatible with the systems that already serve billions of people. ENS having a seat in these TLD and DNS spaces is how the ENS protocol becomes the established internet infrastructure for years to come.
Financial Reporting
Income
Previously in the Q1 report financials, Grant Income was reported as $771,258.86, which has been corrected to $1,904,234.28 based on the accrual accounting method.
As of Q2 close on June 30, 2026, we have received $4,296,112.25 USDC (44.3% of the FY stream) from the ENS DAO.
Expenses
Q2 2026 expenses totaled $2,557,283.37, resulting in a Net Income of $(165,405.40) for Q2.
Top Q2 Expenses:
- Employee Compensation & Benefits (70.1%) for payroll, benefits, and employer contributions for a team of 39.
- Professional Services (18.3%) included expenses for ENSv2 frontend and smart contract external auditing, legal expenses for the ENSv2 patent and .ens TLD being finalized this year.
- Advertising & Marketing (3.6%) focused on go-to-market strategy for ENSv2 including IRL events, generative designs, and related marketing initiatives.
- Travel & Expense (2.3%) inclusive of Ethereum-focused conferences and hackathons, ICANN events, and travel related expenses for: ETHCC, ETHGlobal & Pragma Cannes; ICANN Contracted Parties Summit; ETHPrague; DNS OARC 46 Scotland; ICANN86 Policy Forum Seville; and ETHGlobal & ETHConf New York.
Next: ENSv2 Beta and Mainnet
As Q2 closes, ENS Labs remains focused on one priority: shipping ENSv2 Beta and Mainnet in 2026, guided by user safety and experience.
ENSv2 is not a conventional release. It touches the protocol, the App, the Explorer, migration tooling, developer libraries, partner integrations, GTM alignment, legal considerations, and the way millions of existing name holders experience the upgrade.
Q2 required difficult but necessary decisions. We reworked HCA architecture when the risk model was not strong enough. We hardened migration flows so existing names are treated with the care they deserve during migration from V1 to V2. We chose explicit user consent where automatic upgrade paths introduced the wrong ownership assumptions. We accepted more complexity where it better protected users, and we cut or deprioritized work where deemed necessary.
Q3 will involve completing the remaining security and audit work and reading v2 for final deployment. After v2 launches on mainnet Ethereum, the team is looking forward to a more experimental phase of product development around specific integrations and use cases.
To the ENS community: our commitment is straightforward. ENS Labs is fully committed to shipping ENSv2 in 2026, and to doing it in a way that preserves the guarantees that make ENS worth trusting. ENSv2 is the most substantial upgrade to ENS since the protocol began. It changes how names are structured, how ownership and permissions can work, how users migrate, how builders integrate, and how ENS can scale as the naming layer for the next generation of the internet.
The ENS user comes first. That has been the north star of every hard decision in Q2, and it will remain the standard for the work ahead. ENSv2 is not just the next ENS release. It is the next foundation for ENS.
Finally, to be clear, the expansion of the ENS Foundation does not change the protocol-level guarantees that make ENS valuable. Your ENS name still resolves across major web3 wallets, you can still import your own DNS domain, your name remains unruggable and immutable under ENS ownership rules, and ENS remains permissionless infrastructure for anyone to build on.