Summary

  • A 2026-round Community Application must pass Registry Commitments Evaluation of its proposed registration policies before it can enter Community Priority Evaluation.
  • The sequence tests an enforceable registry rulebook first and a claim to priority within a finalized contention set second; neither review proves a public mandate or guarantees delegation.

The phrase “community application” can sound like a claim about who a gTLD belongs to. In ICANN’s 2026-round process, it is first a designation made by the applicant. The consequence is procedural: if the applied-for string later enters a finalized contention set, the applicant may have an additional route to resolve that conflict. But the designation alone does not give it priority, and it does not certify that the applicant speaks for everyone who might identify with the named community.

The program puts a more concrete question ahead of that contest. A Community Application must include proposed Community Registration Policies for the registry agreement. ICANN’s current guidance says those policies must pass the Registry Commitments Evaluation, or RCE. Without approved policies, the application cannot proceed to the next stage, including the Community Priority Evaluation, or CPE. When a community application in contention elects CPE, RCE must happen first. In the 2026 Applicant Guidebook, RCE asks whether the policies can be approved for inclusion in the agreement; CPE later asks whether those approved policies align with the community objective set out in the application.

This order is the important design feature. A promise to reserve a namespace for a community is not yet an operating rule. The registration policy has to be written into a form that can become part of the registry’s contractual commitments. The priority panel then evaluates evidence about the applicant and its relationship to the proposed string. It does not replace the contract review or create the policy it is asked to score.

The two checks answer different questions. RCE concerns whether proposed policies are enforceable and compatible with ICANN’s Bylaws for inclusion in the Registry Agreement. CPE is an independent assessment by a third-party expert panel. The 2026 Applicant Guidebook sets out four criteria: community establishment, the connection between the proposed string and the community, registration policies, and community endorsement. The allocation of points gives community establishment the largest weight, followed by string-to-community nexus, endorsement and policies.

The guidebook anticipates about 180 days for CPE; ICANN says RCE normally takes 60 to 90 days absent extraordinary circumstances. These are planning estimates, not delivery commitments.

CPE is conditional. It applies only to an application in a finalized contention set, and the applicant must opt in. The Guidebook’s CPE rules say a passing result can give one community application priority to move forward over directly competing applications, subject to the rest of the program’s requirements. If more than one community application passes in the same set, those applications proceed to an ICANN auction. If none passes, the set proceeds to an auction among its applications. CPE therefore changes the route through contention; it is not an award of a delegated domain.

The designation itself is fixed earlier. ICANN says an applicant can select “community” only when submitting the application and cannot change that designation later. A footnote in the guidebook is explicit that applicants self-identify; CPE does not determine whether a community exists. If a designated application does not pass CPE, it remains a Community Application. That distinction prevents the evaluator’s score from being misread as a universal verdict on the identity or worth of a community. The panel decides whether this application qualifies for priority under this program’s criteria.

That architecture also makes the proposed policy consequential beyond the scoring event. If the application continues toward delegation, its Community Registration Policies are intended for the applicable registry agreement. The applicant must show how the claimed community relates to the string and how registration will be governed. In return, an application that satisfies the criteria may gain precedence over direct competitors without first winning an auction. A policy that is too vague to administer, too broad to enforce or poorly matched to the stated community could weaken that route.

The evidence is the application and its approved policy, not the word “community” in a press release.

The broader 2026 round offers context but not a conclusion about legitimacy. ICANN’s 7 October snapshot listed 1,615 applications, 16 designated as community-based, and said the final totals would be confirmed later. Those figures do not show how many applications will enter contention, opt into CPE, pass RCE, or receive priority. Nor does a panel’s review equal a vote by community members or authorization from people outside the application. Heng Lu’s Note 73 is useful here only as an editorial lens: participation and affected interest provide evidence, but they do not automatically create a mandate to bind absent principals.

For operators and applicants, the practical question is not simply whether a string is contested. It is whether the applicant has defined a community tightly enough to connect it to the string, and whether the associated registration rules can be approved and carried into a registry agreement. For observers, the key signals are the published contention-set state, the RCE outcome, whether the applicant elects and funds CPE when invited, and then the panel’s result. A community designation is an entry condition to a possible path. The rulebook and the evaluation determine whether that path can be used.

Sources