Summary

  • ICANN’s replacement period runs from 8 October 00:01 UTC to 21 October 23:59 UTC. An eligible applicant may switch only to a replacement already filed with its application; once selected, it permanently displaces the original string.
  • Switching can avoid some visible contention, but it is not a promise of a clear path: later singular/plural notifications, String Similarity Evaluation or a String Confusion Objection can still put the replacement into contention.

A choice with a closing clock

For an eligible 2026-round applicant, the decision window is short and the consequence is durable. ICANN’s published timetable gives applicants until 21 October at 23:59 UTC to notify it through the TLD Application Management System that they will use a previously designated replacement string. The deadline arrives well before String Confirmation Day, scheduled for 17 November, when ICANN will publish the finalized strings and updated contention sets.

That sequence turns the replacement into a one-way option rather than a reversible draft. If an applicant elects to switch, the replacement becomes the string carried through the remaining process. The Applicant Guidebook says the applicant cannot return to its original string, even if that original would otherwise remain undelegated during the round. If the applicant does nothing, the replacement option expires and the original string continues. A participant is therefore choosing between two paths, not holding both open until evaluation finishes.

The option must also have been created earlier. The applicant had to designate the replacement in its original application; there is no late opportunity to invent another candidate after seeing the public list. Nor can it change the replacement after submitting the application. That makes the present window an exercise of a pre-filed contingency, bounded by rules set before the applicant could see the full field.

What the public record can and cannot tell an applicant

Reveal Day provides useful information: the public application materials include applied-for strings, designated replacements and preliminary contention sets. An applicant can compare its original and alternative with the visible applications. If its original is identical to another applied-for string, a move may remove that direct collision when the rules permit it. ICANN also permits an applicant to elect a replacement even when the original is not currently in a contention set; the choice rests with the applicant and requires no published rationale.

But the list is not a final map of every future conflict. ICANN warns that a replacement can later enter a contention set after String Confirmation Day through a confirmed singular/plural notification, String Similarity Evaluation or a String Confusion Objection. A string can be confusingly similar in appearance, sound or meaning even when it was not an identical match in the preliminary set. Choosing the alternative may therefore exchange a known problem for a different exposure rather than eliminate contention altogether.

Eligibility is another constraint. The Guidebook bars use of a replacement that is identical to another applicant’s applied-for string or replacement string, and the replacement must not create or expand a contention set. It also warns against assuming that a singular/plural variant is safe. These rules make the choice more than a branding preference: an alternate can look commercially attractive yet be unavailable under the program’s string rules.

Irreversibility changes the comparison

The practical question is not simply “Which name is better?” It is “Which string can this applicant operate with if the other paths do not resolve as hoped?” A primary string may have stronger recognition inside an applicant’s portfolio, but the visible record may show a direct conflict. A replacement may offer a cleaner initial position while carrying less brand value, a narrower audience, or its own similarity risk. None of those commercial attributes can be inferred from the ICANN application list; they belong to the applicant’s own assessment.

The timing matters because the selection precedes later evidence. String Confirmation Day publishes updated sets, but the Guidebook and ICANN’s process descriptions preserve later routes by which strings can become contested. The applicant must decide before all evaluation and objection pathways have run. Waiting has a cost too: it forfeits the pre-filed alternative and locks the application onto its original string for the next stages.

This is not an invitation for applicants to bargain with competitors. ICANN prohibits direct or indirect discussion among applicants about replacement decisions and prohibits compensation offered in exchange for switching or not switching. The permitted decision is unilateral. That rule limits private coordination but also means an applicant cannot treat a rival’s future choice as a negotiable hedge.

Heng Lu’s Note 72, “The Bill of Rights of Uniqueness Coordination,” is an editorial lens, not evidence about ICANN’s rules. Its distinction between maintaining an accurate, unique record and claiming broader authority is useful here: a listed application records a proposal and its procedural state; it does not confer an approved or delegated TLD. The same care should apply to a replacement string. It is an option inside an evaluation process, not a guarantee of market access or a final name in the DNS root.

As of 15 October, the decision remains open for eligible applicants for less than a week. The operational ledger to watch is simple but consequential: which original string is being retained, which pre-filed alternative is eligible, what visible collision each path addresses, what later similarity or objection exposure remains, and which choice the applicant can live with if contention persists. The switch can alter the application’s future path. It cannot make that path certain.

Sources