DNS, ENS, and the ICANN Technical Study Group

Over the past 24 hours I have been in attendance at the ICANN Contracted Parties Summit in sunny Manchester, UK.

@Alexu and @slobo.eth have also been on the ground representing ENS’ interests.

There have been some interesting developments that pertain to ICANN’s positioning on ā€˜alternate name spaces’ which I have documented as part of my continued efforts to support the responsible integration of ENS with the DNS.

6 Likes

Thanks for the writeup, Thomas. It’s clear that you care about this topic a lot. But wanted to put a few things on the record in case there is any misunderstanding.

There is no Technical Liaison role between ENS and ICANN that has been formally designated. Alex Urbelis, @Alexu , whom you all know well, is our representative on ICANN matters given his credentials and extensive experience in this field. He’s also the one who actually authored the public comment on name collision procedure cited in your post, among so much other work he has taken up in this space over the years for ENS. No other liaisons have been appointed. Same goes for the Technical Study Group. Any ENS representation there should be coordinated through ENS Labs officially, not through self-nomination, as there are things in the works already.

Of course, attendance at ICANN events in a personal capacity, and writing on ENS topics as an independent commentator, is welcome and I think encouraged. But representing ENS in those settings to external parties, formally or by implication, without coordination or authorization makes us look worse. Whether it’s with institutions or formal standards bodies, going rogue creates miscommunication and makes us look disorganized, and can be more detrimental than beneficial.

Katherine - to clarify, I have not claimed any formally designated role on behalf of ENS. When I attend ICANN events, I’m clear about my affiliation and that my work is as an ENS DAO-funded Service Provider.

Alex Urbelis is the ENS Labs representative within the ICANN ecosystem, and I referenced his contribution with appropriate credit.

In November 2025 at ICANN Dublin I attended technical discussions and workshops relating to alternate namespaces and answered questions on ENS. I was subsequently asked by ICANN’s Security and Stability Advisory Committee (SSAC) to provide further technical input to the RIDE Work Party, which I did earlier this year.

ICANN operates a multi-stakeholder model. The Technical Study Group announcement included an open call for self-nomination, and given my prior contributions I was encouraged directly to put my name forward. Participation on that basis is consistent with how ICANN expects engagement to work.

More broadly, ENS is a DAO with multiple contributors funded by it. ENS Labs plays an important role, but it isn’t the entirety of ENS. Clearer visibility on what’s already underway would help contributors align and avoid the kind of confusion we’re trying to prevent.

For completeness: I’ve updated a sentence in the blog post to clarify wording around my involvement with ICANN and avoid implying any formally designated role.

Thanks for documenting this, Thomas. Tracking how ICANN is positioning on alternate namespaces is useful, and the divergence between the SSAC posture set out by Rick Wilhelm and the Registry Service framing offered by Francisco Arias is the part of the Manchester announcement that warrants the closest attention. The ā€œRegistry Serviceā€ question in particular has implications well beyond .eth.

To affirm Katherine’s note and put the coordinating practice in one place:

As has been the case for the past two years, ENS Labs coordinates ENS representation in formal ICANN bodies, and participation in the new Technical Study Group on ENS’s behalf will run through that channel. I raised this point directly at the Manchester meeting where the TSG was announced and am in touch with the organizers. This is not about gatekeeping who can be in the room; it is about ensuring that anything attributed to ā€œENSā€ in ICANN records reflects a position ENS can defend.

On the broader visibility point, that’s well-taken and we should address it constructively. I’d like to propose a short, lightweight check-in: any DAO contributor planning to attend an ICANN meeting, working group, study group, or advisory body in a capacity that touches ENS sends a brief note in advance to the ENS Labs ICANN coordination channel describing the venue, the framing of the engagement, and the intended scope. No approvals, no bureaucracy; just visibility and coordination, so we can flag conflicts, share what is already in motion, and avoid parallel-track problems before they arise. I will draft and circulate something in the next week.

On the substance of the Manchester sessions, happy to share notes and to coordinate with anyone working on the SSAC/RIDE track.

2 Likes