Beyond the Dot: The Crucial Questions Facing the 2026 New gTLD Round

4 Aug 2026, Alfredo Calderón-Serrano.

Can Applicant Support Turn Multilingual Access into Durable Community Infrastructure?

The 2026 New Generic Top-Level Domain Round is not simply another expansion of internet naming. It is a test of whether domain name policy can distinguish between opening an application process and building the institutional capacity required to operate a registry for years—or even decades.

ICANN opened the application window on April 30, 2026, and applications will be accepted through August 12, 2026. The round permits applications in 27 scripts representing hundreds of languages, including Arabic, Chinese, Cyrillic, Devanagari, and Thai. This represents an important opportunity to expand linguistic diversity within the Domain Name System. Yet the number of delegated strings alone will not determine whether the round succeeds. The more consequential question is whether the organizations behind those strings can keep their registries secure, financially viable, operationally resilient, and meaningful to the communities they intend to serve. (ICANN, 2026a, 2026b). (ICANN)

The future of a multilingual internet depends less on how many new dots are added than on whether the communities represented by those dots can endure.

Figure 1. Created: ChatGPT, July 22, 2026 (C) ACS

From Access to Durable Capacity

At the center of this challenge is ICANN’s Applicant Support Program. The program is intended to reduce financial, technical, informational, and geographic barriers that have historically limited participation in the new-gTLD process.

Qualified applicants may receive capacity development assistance, access to volunteer professional service providers, guidance from an Applicant Counselor, bid credits in certain contention-resolution procedures, reduced base Registry Operator fees, and a 75–85 percent reduction in the standard gTLD evaluation fee. These measures can make participation more realistic for community organizations and other entities that would otherwise be unable to absorb the considerable cost and complexity of applying for a new gTLD. (ICANN, n.d.-a). (New gTLD Program)

Consider a cultural or linguistic organization seeking a top-level domain in its community’s script. Fee reductions might make the initial application financially possible. Pro bono legal or technical services could help the organization address unfamiliar contractual and operational requirements. An Applicant Counselor could help its leaders understand the application process and locate relevant ICANN resources.

These benefits matter, but they should not be confused with approval or long-term viability. Qualification for Applicant Support does not guarantee that an applicant will pass evaluation, prevail in a contention set, execute a Registry Agreement, or receive delegation of its requested string. Supported applicants must still submit a separate gTLD application and satisfy the same applicable evaluation requirements as other applicants. (New gTLD Program)

More importantly, application assistance does not automatically produce a sustainable registry operator. A successful registry must maintain technical infrastructure, oversee service providers, comply with contractual obligations, respond to security incidents, protect users, manage financial risk, and sustain community participation after initial assistance has ended.

The Applicant Support Program should therefore be evaluated not merely as an access initiative but as a capacity-building experiment. Its ultimate value will depend on whether temporary assistance can help create durable institutions.

Figure 2. Created: ChatGPT, July 22, 2026. (C) ACS

Why IDN Community gTLDs Raise the Stakes

The challenge becomes particularly significant when Applicant Support intersects with Internationalized Domain Names and Community gTLDs.

Internationalized Domain Names allow domain names to be represented using characters beyond the basic ASCII alphabet. They make it possible for people to navigate the internet, establish digital identities, and potentially use email addresses in the scripts associated with their own languages. IDNs are therefore more than translated versions of existing domain names. They are part of the infrastructure required for a genuinely multilingual internet.

A Community gTLD, under the 2026 Applicant Guidebook, is intended to operate for the benefit of a clearly delineated community. An applicant may identify a cultural, linguistic, regional, professional, or other defined community and propose registration policies governing who may register names and how names may be selected. Those policies must be evaluated and approved before being incorporated into Specification 12 of the applicable Registry Agreement. (New gTLD Program 2026 AGB)

When a Community Application enters a contention set, the applicant may elect to participate in Community Priority Evaluation. CPE allows an independently evaluated Community Application to seek priority over competing applications for the same string. However, Community Priority Evaluation is not an automatic benefit of identifying an application as community-based; it applies only in cases of contention and requires the applicant to satisfy specific evaluation criteria. (New gTLD Program 2026 AGB)

These requirements reflect the distinct responsibilities associated with a Community gTLD. A commercial registry may primarily measure success through registrations, revenue, and market share. A community-oriented registry may pursue a different combination of objectives: cultural representation, trusted communication, educational access, preservation of language-specific resources, local economic development, or the delivery of public-interest services.

A successful IDN Community gTLD could give schools a recognizable namespace for educational resources, enable cultural institutions to preserve materials under names written in the community’s script, help small businesses demonstrate local legitimacy, and allow public-interest organizations to communicate with users in linguistically familiar ways.

Its value may therefore depend less on reaching millions of registrations than on becoming a trusted and consistently used part of the community’s digital environment.

Conversely, the failure of such a registry would represent more than an unsuccessful commercial venture. It could weaken trust in local-script domains, reduce access to community services, undermine confidence in future IDN initiatives, and leave the community without the digital representation it was promised.

The stakes of the 2026 Round consequently extend beyond market expansion. They include digital inclusion, linguistic participation, cultural representation, and the ability of communities to govern meaningful parts of their online identity.

Security as a Condition of Trust

A community namespace cannot fulfill these functions unless users trust it. Security is therefore not an optional technical enhancement; it is a prerequisite for adoption.

For an IDN registry, security begins with disciplined management of the characters and variants that may appear in registered names. IDN gTLD applications must comply with applicable Root Zone Label Generation Rules. These rules help determine which strings are valid and how variant relationships are handled within particular scripts. Registry policies must also address script-specific character tables and the potential risks created by visually similar characters. (New gTLD Program 2026 AGB)

Visual similarity does not make IDNs inherently unsafe. Confusable characters also exist within Latin-script environments. Nevertheless, script-specific risks require careful registration policies, transparent treatment of variants, and coordination with linguistic and technical experts. Poorly designed policies could permit deceptive registrations, user confusion, or impersonation.

Security also requires the protection of the registry’s core DNS infrastructure. DNS Security Extensions, or DNSSEC, allow validating systems to confirm the origin and integrity of signed DNS data. DNSSEC does not prevent every form of cyberattack, but it can help detect unauthorized modification of DNS responses and strengthen confidence that users are receiving authentic DNS information. (ICANN, 2019). (ICANN)

For a Community gTLD used by schools, public institutions, healthcare providers, cultural organizations, or local businesses, failures in DNS integrity could affect more than the registry operator. They could undermine confidence in the entire community namespace.

DNS abuse mitigation is equally important. Registry operators must maintain accessible abuse-reporting mechanisms, review actionable evidence, conduct appropriate technical analysis, and take proportionate steps to stop or disrupt well-evidenced DNS abuse. Mitigation should be prompt and effective while avoiding unnecessary harm to legitimate registrants, particularly when a domain has been compromised rather than intentionally registered for abuse. (ICANN, 2024). (ICANN)

A secure community registry therefore needs more than technical infrastructure. It needs trained personnel, defined escalation procedures, reliable monitoring, appropriate relationships with registrars and service providers, and an incident-response plan understood by both technical staff and community leadership.

Security is ultimately a governance function. Technology can identify or reduce certain risks, but institutions must decide how reports are evaluated, who has authority to act, how affected registrants are treated, and how decisions are documented and reviewed.

Sustainability as an Operational Reality

Security cannot be separated from sustainability. A registry that lacks the resources to maintain its systems, retain qualified personnel, supervise vendors, or respond to incidents will eventually create security risks regardless of how well it was designed at launch.

Financial sustainability is therefore one of the central uncertainties facing supported applicants. Registry operations generate continuing costs: Registry Service Provider fees, ICANN fees, legal and compliance expenses, DNS infrastructure, data protection, security monitoring, marketing, community outreach, staff training, and contingency planning.

For a community-oriented registry, conventional assumptions about scale may not apply. The registry may serve a comparatively small population or pursue public-interest goals that do not produce high registration volumes. Its sustainability model may consequently require a combination of registration revenue, institutional partnerships, grants, public support, philanthropic investment, or cross-subsidization.

This does not mean that every community registry must become commercially large. It means that every applicant needs a credible model for continuing its mission when initial support, publicity, and launch funding are no longer available.

Operational sustainability also depends on institutional continuity. A registry may rely heavily on one community leader, technical expert, donor, or vendor during its formative stages. Without succession planning, documented procedures, diversified leadership, and clear contractual arrangements, the departure of one person or organization could place the entire namespace at risk.

The crucial question is not simply whether an applicant can launch. It is whether the applicant can survive leadership transitions, changes in funding, vendor failures, security incidents, and shifts in community demand.

Universal Acceptance: The Missing Link Between Delegation and Use

For IDN Community gTLDs, sustainability also depends on factors outside the direct control of the registry operator.

A domain may be validly delegated in the DNS and still fail during ordinary use. Websites may work while online forms reject the domain. Email systems may refuse addresses written in a local script. Mobile applications, payment platforms, identity-management systems, customer databases, and software validation routines may incorrectly classify the domain or email address as invalid.

Universal Acceptance seeks to ensure that all valid domain names and associated email addresses can be accepted, validated, stored, processed, and displayed correctly, regardless of script, language, character length, or the date on which a TLD was introduced. (ICANN, n.d.-b). (ICANN)

UA is therefore not merely a technical advocacy issue adjacent to IDNs. It is an operational dependency.

When users repeatedly encounter rejected addresses or malfunctioning services, adoption slows. Low adoption weakens registration revenue and reduces incentives for local businesses and institutions to establish services under the new namespace. Limited use then discourages software providers from correcting UA defects, creating a self-reinforcing cycle of low compatibility and low demand.

This is particularly damaging for community TLDs. A community may invest substantial effort in creating a namespace that expresses its language and identity, only to discover that essential digital platforms do not recognize it.

Registry applicants should therefore treat UA readiness as part of their sustainability planning. This may require partnerships with universities, software developers, government agencies, financial institutions, local technology companies, and civil-society organizations. Such partnerships can test systems, document failures, train developers, and encourage institutions serving the community to become UA-ready.

Applicant Support can help an organization reach the application stage. Only a wider ecosystem of interoperable technologies can ensure that the resulting domain becomes useful.

What Should Success Look Like?

The 2026 Round should not be evaluated solely by counting applications or delegated strings. Those indicators measure activity, but they do not establish whether the program produced durable inclusion.

A more meaningful evaluation would ask whether supported Community gTLDs remain operational three, five, and ten years after delegation. It would examine whether they maintain DNSSEC and other technical requirements, address well-evidenced DNS abuse, demonstrate financial continuity, and preserve effective governance structures.

Evaluation should also consider actual community use. Are schools, cultural organizations, public institutions, businesses, and residents establishing websites or services within the namespace? Are users able to employ the domains and related email addresses across commonly used applications? Does the community regard the registry as legitimate, responsive, and representative?

Other indicators might include:

• Registry continuity and compliance over time.

• DNS availability, resilience, and DNSSEC performance.

• Rates and patterns of DNS abuse.

• Responsiveness to abuse and security reports.

• Adoption by community institutions.

• Universal Acceptance across locally important platforms.

• Financial diversification and reserve capacity.

• Community participation in registry governance.

• Transparent registration and enforcement policies.

• Succession planning and institutional continuity.

These measures would provide a more accurate picture of whether Applicant Support created lasting capacity or merely enabled participation at the beginning of the process.

They would also help ICANN and the wider community identify where future intervention may be necessary. If supported registries repeatedly encounter similar problems after delegation, those patterns could justify expanded training, shared technical services, regional UA programs, mentoring networks, or carefully designed forms of post-delegation assistance.

From Application Support to Institutional Development

Applicant Support can help produce secure and sustainable IDN Community gTLDs, but only if it is understood as the beginning of an institutional-development process rather than the completion of an inclusion objective.

Fee reductions, counseling, professional assistance, and capacity-development resources can help historically excluded organizations reach the starting line. They cannot, by themselves, guarantee competent governance, secure operations, community adoption, Universal Acceptance, or long-term financial stability.

Those outcomes will depend on decisions made by applicants, registry service providers, registrars, software developers, community institutions, governments, funders, ICANN, and end users.

The most important questions facing the 2026 Round therefore begin where the application process ends:

• Can supported applicants convert temporary assistance into permanent operational capacity?

• Can IDN Community gTLDs become routinely usable across email systems, applications, and digital services?

• Can community registries protect users without imposing disproportionate restrictions?

• Can they develop financial models that support public-interest objectives without depending indefinitely on temporary funding?

• Can community members participate meaningfully in the governance of the namespace intended to represent them?

• And will ICANN evaluate success through long-term security, usability, sustainability, and community value rather than through delegation numbers alone?

The answer to the article’s central question is necessarily conditional. Applicant Support can contribute to secure and sustainable IDN Community gTLDs, but only when access is connected to operational readiness, Universal Acceptance, accountable governance, community adoption, and long-term institutional support.

Inclusion is the promise of the 2026 Round. Endurance will be its proof.

--

References

• Internet Corporation for Assigned Names and Numbers. (n.d.-a). Applicant Support Program.

• Internet Corporation for Assigned Names and Numbers. (n.d.-b). Universal Acceptance.

• Internet Corporation for Assigned Names and Numbers. (2019). DNSSEC: What is it and why is it important?

• Internet Corporation for Assigned Names and Numbers. (2024). 2024 global amendments to the 2013 Registrar Accreditation Agreement and Base gTLD Registry Agreement.

• Internet Corporation for Assigned Names and Numbers. (2026a, April 30). ICANN opens application window for new generic top-level domains.

• Internet Corporation for Assigned Names and Numbers. (2026b). New Generic Top-Level Domains Program: 2026 Round Applicant Guidebook.

• Internet Corporation for Assigned Names and Numbers. (2026c). Applicant Guidebook, Module 5: Contention set resolution.

• Internet Corporation for Assigned Names and Numbers. (2026d). Applicant Guidebook, Module 7: String and application evaluation procedures.

About the Author

Alfredo Calderón-Serrano is a Puerto Rican educator, instructional designer, and Internet governance leader with more than three decades of experience in higher education, educational technology, and capacity building. An active At-Large/NARALO volunteer with ICANN since ICANN53, he served as the 2024 NomCom delegate for the North American At-Large community and is co-founder of the North American School of Internet Governance (NASIG) and the Virtual School on Internet Governance (VSIG). In 2025, the ICANN Board awarded him the Dr. Tarek Kamel Award for Capacity Building in recognition of his work founding and sustaining these schools. A board member of the Internet Society Puerto Rico Chapter since 2014, he focuses on Universal Acceptance, IDNs, accessibility, and digital inclusion — translating complex governance topics into learning opportunities for academic, civil society, and regional communities.