Summary

  • A Blocked Name is an exclusion boundary, not a rival application or a contention-set winner.
  • A reconstructable result should expose the compared labels or variants, the relationship, panel rationale and challenge clock.

An applicant in ICANN’s 2026 new gTLD round can lose the ability to proceed even when no competing application exists. The obstacle may be a Blocked Name: a label that is unavailable for application and that also casts a visual-similarity boundary around itself and its variants.

That is a different mechanism from contention. A rival application wants the same or a confusingly similar place in the root. A Blocked Name does not apply for anything. It does not win, bid, withdraw or sign a registry agreement. Yet the Applicant Guidebook says that an applied-for string or one of its variants will not proceed if an independent panel finds it visually similar to a Blocked Name or a variant of one.

The practical result can look like a contest with an invisible opponent. The rule is clearer when treated for what it is: an exclusion decision, not a victory by another applicant.

Two routes to the same closed gate

ICANN’s current authoritative English Applicant Guidebook is version V2-2026.04.24, published on 24 April 2026. Section 7.2.1 describes Blocked Names as labels unavailable for application in the round. The categories reflect different protections and reservations; the mere label “blocked” does not imply one universal policy reason.

Table 7-5 then separates two outcomes. If an applied-for string is the same as, or a variant of, a Blocked Name, the application is not accepted. If the string passes that entry screen but the String Similarity Evaluation later finds it visually similar to a Blocked Name or its variant, the application cannot proceed.

Those routes matter. “Not accepted” and “cannot proceed” are not interchangeable descriptions of the record. One concerns the relationship captured at application handling; the other is an evaluation outcome reached through a comparison process. A useful public result should say which route applied.

A boundary is not a rival

Section 7.10.3.5 discusses contention among applied-for gTLD strings and their variants. Section 7.10.3.6 states the Blocked Name outcome separately. That structure supports a bounded but important conclusion: a Blocked Name functions as an exclusion boundary, not as another application in a contention set.

This distinction prevents several errors. The blocked label has not prevailed on merit. The applicant has not necessarily lost to a better proposal. No auction or private resolution is implied. And a visual-similarity finding does not establish bad faith, trademark infringement or misconduct by the applicant. It answers a narrower question about the appearance of strings under the Guidebook’s evaluation rules.

Calling the outcome “contention” would invent a rival. Calling the Blocked Name a delegated gTLD could invent a status. The accurate account is simpler: the rule prevents the application from advancing because of its relationship to a protected or reserved label.

Variants enlarge the comparison boundary

The rule does not compare only the applied-for label with only the base Blocked Name. It reaches variants on both sides. An applied-for string may be affected because its own variant is visually similar to the blocked label, or because the relevant comparison involves a variant of the Blocked Name.

That makes the decision difficult to reconstruct from a one-line failure notice. Readers need to know which two labels were actually compared. Was the trigger the applied-for string itself or one of its variants? Was the other endpoint the base Blocked Name or a blocked variant? Was the relationship identity, variant status or visual similarity?

Without those edges, “blocked” becomes an opaque conclusion. With them, the outcome becomes a checkable sequence: category, labels, relationship, panel finding and consequence.

The panel’s rationale and the challenge clock

The Guidebook describes the String Similarity Evaluation as a manual comparison by an independent panel. Section 7.10.2.4 says the panel documents its analysis and outcome with rationale. ICANN’s current evaluation page likewise presents the process as a manual review rather than an automatic string-matching score.

That matters because visual similarity is a judgment. A public record should preserve enough of the panel’s reasoning to show why the comparison crossed the rule’s threshold. It should not disclose only the final status while hiding the compared pair.

Section 7.10.4 also provides a challenge route for an alleged factual or procedural error under a clearly erroneous standard, with the stated 21-day filing period. A challenge is not a fresh policy argument and not an automatic second evaluation. But a usable deadline depends on a legible decision. An applicant cannot test a factual or procedural error intelligently if the record does not identify the decisive comparison.

What ICANN should publish

The official sources establish the rule, the panel process, the outcome categories and the challenge mechanism. They do not establish that ICANN currently publishes the complete record proposed here. The following is therefore governance doctrine, not a claim about existing practice.

For each Blocked Name exclusion, ICANN should publish a compact ledger containing:

  • the Blocked Name category, without collapsing distinct policy bases into one label;
  • the applied-for string or variant that formed one endpoint of the comparison;
  • the Blocked Name or blocked variant at the other endpoint;
  • whether the relationship was identity, variant status or visual similarity;
  • the panel’s reasoned finding and the resulting status; and
  • the date from which any challenge period runs.

That record would not expose confidential strategy or turn a protected name into an applicant. It would show the legal and procedural path by which one application stopped.

Exclusion should remain visible as exclusion

A Blocked Name can close the gate without standing on the other side of it. That is the key institutional fact. The absence of a competing applicant does not make the decision less consequential; it makes classification more important.

ICANN should not describe this outcome with the vocabulary of winners and losers. It should expose the boundary that was applied, the exact comparison that activated it and the process for testing an error. When an application cannot proceed, the public should be able to see what stopped it—without having to imagine a rival that never existed.

Primary sources