Summary

  • A late Priority Number does not place a proposed string outside the comparison universe. ICANN's 2026 Round rules require the similarity review to cover every applied-for string before evaluation batches are formed.
  • Imagine two applications whose proposed top-level domains are visually similar. One receives an early Priority Number; the other lands far down the queue. If the early group were evaluated in isolation, ICANN could treat the first string as unopposed and discover the relationship only after the first batch was already fixed.

Imagine two applications whose proposed top-level domains are visually similar. One receives an early Priority Number; the other lands far down the queue. If the early group were evaluated in isolation, ICANN could treat the first string as unopposed and discover the relationship only after the first batch was already fixed.

The 2026 Round Applicant Guidebook closes that sequencing gap. Section 7.10.2.2 says that, if batching is required, String Similarity Evaluation is completed on all applied-for strings before evaluation priority batches are established. If applications are placed in a contention set, the strings in that set go into the same batch according to the set's highest-priority string.

That is a small rule with a large governance function. It makes priority a scheduling device, not a boundary around what the similarity panel is allowed to see.

One comparison universe, then batches

ICANN's current authoritative English guidebook is V2-2026.04.24. Module 1 locates String Similarity Evaluation within String Evaluation, a process focused on applied-for strings and their allocatable variants. It also makes a crucial distinction: the five String Evaluation elements are assessed concurrently, and String Evaluation does not follow application priority order.

Module 7 then defines the comparison field. For each application, the primary string and the relevant variant strings are checked against several categories. Those categories include existing delegated gTLDs, still-pending strings from earlier rounds, relevant ccTLD and requested IDN ccTLD strings, other applications in the current round, a subset of Blocked Names, and other two-letter ASCII strings. The detailed rules also account for allocatable and blocked variants as specified in the guidebook.

The all-strings-before-batches provision matters because one category is relational: other strings filed in the same round. A result for one application can therefore depend on an application with a very different Priority Number. Completing the comparison first preserves the full current-round field before an operational queue divides the work.

That last sentence is an inference about the rule's design, not language ICANN uses as its stated rationale. ICANN's express objective for String Similarity Evaluation is to prevent user confusion and loss of confidence in the DNS that could result from delegating visually similar strings. The “comparison universe” is a useful governance model for understanding how the sequencing rule supports that objective.