What the list of applied-for strings tells a brand owner

A single document changes what every brand owner with a stake in the DNS is able to know. Until it is published, the set of applied-for strings is sealed: an organization knows its own application and nothing about anyone else’s. Once it is public, every proposed string and the applicant behind it are a matter of record. That shift matters whether your organization filed an application, considered filing and decided against it, or never followed the process at all.

The document is ICANN’s list of applied-for strings, and the program calls the day of its publication Reveal Day. A focused team can read it in one sitting. Reading it without a method, or not reading it at all, leaves gaps that are harder to close later, because the questions the list raises are easier to answer while the record is fresh and the people who know your marks are in the room. This article is a working guide for brand and legal teams: what the list contains, how to work through it in order, and what it does not tell you.

By the end, you will know what each combination of findings means for your organization, which of them call for a conversation with counsel, and where the onchain layer raises a parallel set of questions that the ICANN list does not address.

1,616applications going forward in the 2026 round

USD 227,000evaluation fee a brand applicant should expect for each application, with advisers and registry operations still to add

Noneannual renewal fee on a Freename TLD

The trade press reports the application count, ICANN's new gTLD program pages give the evaluation fee, and the Freename registry states the absence of a renewal fee.

What the applied-for strings list actually contains

The list is the public face of the application round that ICANN opened in 2026, the first round for new generic top-level domains in more than a decade. Its application window closed on August 12, 2026. In outline, the list pairs each applied-for string with the organization that applied for it. Around that core, the public part of an application describes what the applicant says it intends to do with the string. The confidential parts of an application, such as financial and security detail, stay out of public view.

Two terms need a short explanation. A string is the sequence of characters to the right of the last dot, the TLD itself. A contention set is the group of applications that ask for the same string. Only one of them can end up operating it, so the applicants in a set must eventually settle who proceeds, whether by agreement among themselves or through the procedures the program provides for that purpose.

The trade press reports 1,616 applications going forward. That figure counts applications, not strings. Where several applicants want the same string, several applications collapse into one string, so the number of distinct strings is lower than the number of applications. For a brand team, the practical consequence is that one string may carry several rows, and each row is a different organization with a different stated plan.

The list is also a first picture, not a final one. Applications can be withdrawn, objected to, or grouped with others when two different strings are judged too similar to coexist. The list you read is therefore the first complete view of the round and the starting point for your decisions, without being the end state.

One structural point shapes everything that follows. The list is a record of strings and applicants, not a record sorted by your concerns. A brand team must therefore search it in more than one way: by your exact string, by variants that look or sound like it, and by the sector words that sit next to your marks.

If your string appears under your organization’s name

Finding your string under your own name is the cleanest result, but it is not the end of the review. The first question is whether you are alone on that string or whether another applicant asked for it too.

If you are the sole applicant, your application moves into ICANN’s evaluation, which looks at the applicant and its ability to run a registry as well as at the string. No other party has a competing application for the same string, although the program’s objection procedures remain open to third parties. The list confirms your position but does not create it; your application does.

If your string sits in a contention set, the list tells you who the other applicants are and, through the public application materials, what purpose they state. That information shapes how your advisers approach the question of who proceeds. A competitor in your own sector that wants the string for its own name is a different counterpart from an applicant that wants the same characters as a generic word open to the public. Your own counsel will advise on which path fits your application and what the public record of the competing application suggests about how that applicant will act.

A brand application, where the string is your own trademark and the names under it are meant for your own use, also reads differently to outsiders than an open, generic application. Once it is public, your customers, your competitors and the press can all see that you intend to run a namespace of your own. It is worth agreeing in advance who answers questions about it and what the answer is.

Finally, check the details of your own entry. The applicant entity named in the public record should be the entity that holds the relevant trademarks, or one whose relationship to the trademark holder your counsel can explain in a sentence. A mismatch between the applicant and the trademark owner is easier to document at the start than to explain later.

If your string appears under another applicant’s name

This is the finding brand teams find hardest to act on, because the list confirms a fact without resolving it. Another organization has applied for a string that corresponds to your brand, mark or product name.

The first question is whether that applicant has a plausible independent claim. Many marks are also ordinary words, family names or place names. An organization may have applied for a word that is a sector term in its own industry and that happens to overlap with your mark in yours. The stated purpose in the public application is the best early evidence of which situation you are in: an application built around the dictionary meaning of the word is not the same as one that makes sense only by reference to your brand.

The distinction matters because the program’s objection procedures are built around the nature of the conflict. One of them exists for holders of legal rights such as trademarks, and in outline it asks whether the applied-for string would take unfair advantage of an existing mark or create a likelihood of confusion with it. Whether the facts of your case meet that standard, and whether an objection is the right instrument at all, is for your own counsel to decide. The dates for filing are set by the program’s timetable; the list itself is not a filing deadline.

What you can do at once is preserve the record. Note the applicant’s identity, the stated purpose in the public application, and the date on which you read it. If there is prior correspondence with that applicant, prior registrations of the same name in any namespace, or trademark filings that predate the application, put the sequence in writing while the people who remember it are available. That documentation supports any objection or negotiation that follows.

Resist the reflex to write to the applicant the same day. A first message sets the tone of everything after it and may be read later by a panel or a court. Decide with counsel whether contact helps, who makes it, and what it says.

The page for brands and legal teams is written for general counsel and brand protection teams, and the trademark TLD page holds the free Trademark Name Check for your marks.

Strings close to yours and the similarity question

A contention set groups applications for the identical string. It does not capture strings that look like your mark, sound like it, or carry the same meaning. That work falls to your team.

Consider a mid-sized manufacturer whose primary mark is a single English word. This is an invented scenario, not a real organization. The exact string may be uncontested, or not applied for at all. But a string that is the plural of the word, that differs by one letter, or that is a common synonym may have been applied for by an applicant with no relationship to the manufacturer. If that string is delegated and opened to the public, names registered under it could sit close enough to the mark to confuse customers, without the string itself being identical to anything the manufacturer owns.

The list gives you the material to run this analysis. The method is systematic: take every mark in your trademark portfolio, write down a controlled set of visual and phonetic variants, and check each one against the published strings. Organizations with short marks made of common words face the widest exposure, simply because more strings fall within a letter or a syllable of them. The result of that sweep is not a legal filing. It is a briefing document for counsel and a record of what you found and when.

Keep the sweep disciplined. A variant set that grows without limit produces a register nobody reads. A workable rule is to keep only variants that a customer could plausibly mistake for your mark when typing, reading or hearing it, and to note the reason next to each one.

Similarity between strings is also something the program examines itself. Strings judged too alike to coexist can be grouped together, and there is an objection procedure built on confusion between strings. In outline, that procedure serves operators and applicants of TLDs, not trademark owners as such, so it may or may not be open to you. Whether it is available and appropriate in your situation is a question for your advisers.

The free Namespace Exposure Score on this site scores how exposed a brand is onchain, and complements your review of the ICANN list.

What the list does not tell you

The list answers one question precisely: who applied for which string in this ICANN round. Everything outside that boundary requires separate inquiry.

It does not tell you who holds the matching onchain TLD. Onchain registries, Freename among them, operate independently of ICANN. A string recorded onchain before an ICANN application was filed is not reflected in the ICANN list and is not changed by its publication.

It does not tell you what an applicant will do in practice. The public application states a purpose. It does not disclose commercial plans the applicant chose not to describe, the price at which names will be offered, or the partners the applicant will work with. A stated purpose is a declaration, and you should read it as one.

It does not tell you who intends to object to an application, or which applicants are already talking to each other about a contention set.

It does not tell you that anything is live. An applied-for string does not exist in the DNS until it has been evaluated and delegated, meaning added to the DNS root so that it resolves. An applicant on the list has no operational TLD yet, and no names under the string can be registered or used. For a brand team, this means the list describes a future state of the DNS, not a present one.

That limit cuts both ways when you compare the two systems. Once delegated, an ICANN TLD resolves in every ordinary browser and mail system, which is the DNS’s plain advantage. Onchain names resolve outside the ICANN root, so an ordinary browser does not open them without added support, and that support is partial and changes over time. What the onchain side has is immediacy: an onchain TLD can exist and be in use regardless of where any ICANN application stands.

Why applied-for names are looked at more closely

An applied-for string is a public declaration of intent backed by a substantial commitment. ICANN’s new gTLD program pages give an expected evaluation fee of USD 227,000 per application, and that is before advisers and the cost of running a registry. An organization that files at that cost has made a considered decision, and everyone reading the list knows it.

That is why publication concentrates attention. Before the list, a word is one of countless possible strings. After it, the same word is a string somebody has paid to pursue, with a named applicant and a stated plan. Journalists read the list for well-known names. Competitors read it for each other. Investors and name holders in other systems read it to see which words the market has just confirmed as worth an application.

For a brand, the consequence is that the applied-for names connected to you will be looked at by people who never looked before, in every place a name can exist: in existing domain extensions, on social platforms and in onchain registries. The name has not changed. The number of people examining it has.

Treat that as a reason for an orderly check, not as an emergency. The useful questions are simple. Where does this name already exist? Who controls it there? Is that the outcome your organization intended? An answer of “we do not know” is the finding to fix first.

Attention also has a timing aspect for your own preparation. The program’s timetable sets when formal objections can be filed, and the work that makes an objection possible, such as reviewing the application, documenting your trademark position and briefing counsel, takes place between the list and those dates. A team that files the list away as background reading gives up part of that preparation time for no benefit.

The onchain counterpart of every applied-for string

Every string on the ICANN list has a possible counterpart in an onchain registry, and that counterpart may already exist.

An onchain TLD is not delegated by ICANN. On the Freename registry, for example, it takes the form of a token, recorded onchain and sitting in a wallet. There is no annual fee to renew it, and the right to issue names under it belongs to its holder alone. An onchain TLD can be created without any reference to the ICANN round, so the same characters can exist as an applied-for string in one system and as a held TLD in the other. The holder of the onchain TLD and the ICANN applicant may be different parties, with different positions in different systems.

This matters to brand teams for two reasons. First, an organization that obtains a delegated ICANN TLD does not thereby acquire the matching onchain TLD. The two are separate. If your organization plans to operate .yourbrand in the DNS, you also need to know what exists at .yourbrand onchain, because a name such as pay.yourbrand can mean one thing in a browser and another in a wallet that supports onchain names. Second, if another party’s application for a string matching your brand succeeds, the onchain counterpart is a further place where the same name may be controlled by someone other than you.

The question of what happens when the two systems carry the same name has a technical side. Freename AG holds U.S. patent US 12,401,618 B1, filed on February 23, 2024 and granted on August 26, 2025, a grant reported by Domain Name Wire. According to the patent text on Google Patents, it covers a rules-based way of resolving names that collide: the competing names are scored, and the score decides which one resolves. One of the weighted criteria is first registration, meaning the earliest date of creation. The patent itself names new ICANN TLDs colliding with established web3 namespaces as a problem it addresses.

Read that for what it is. A patent describes a method. It is not a court ruling, it does not bind ICANN, and it does not determine how any browser or wallet will behave. What it shows is that the question of colliding names is being worked on, and that in at least one described method the date on which a name was created counts.

The practical point is modest: for each string you care about, find out whether the onchain counterpart exists and whether your organization controls it. A brand team weighing both systems will find them laid out point by point in the comparison of a dotBrand and an onchain TLD. Where the onchain TLD that matches your brand is held elsewhere, brand namespace recovery is the service for acquiring it.

How to review the list in seven steps

The review works best as one session with the right people present: whoever owns the trademark portfolio, whoever manages domain names, and a lawyer who can say which findings need outside counsel. The order below moves from what you know to what you have to look up.

1. Compile your mark inventoryBefore opening the list, assemble the marks, brand names, product names and sector terms your organization uses or plans to use. This inventory is the input to every later step.
2. Search for exact matchesRun each item in your inventory against the published strings. Record every hit: the string, the applicant and whether other applicants asked for the same string. Note your own applications first, then others.
3. Search for near matchesFor each mark, write down a controlled set of visual and phonetic variants, such as plurals, one-letter differences and synonyms, and repeat the search. The output is a near-match register.
4. Read the public application materialsFor every hit, read the public part of the application. Note the applicant's stated purpose and any justification it gives for the string. This is what your counsel will use to assess an objection or a negotiation.
5. Check the onchain counterpartFor every string that concerns you, see whether the same string exists as an onchain TLD. Registry records are public, and a block explorer lets anyone look one up.
6. Classify each findingUse the table in the next section to assign each finding a category and an action. Send the classified register to counsel and to whoever owns your trademark portfolio.
7. Record the program datesAsk your advisers for the dates of the stages that follow publication, and put them in the calendar of the person responsible. The list itself does not announce them.

Two habits make the result usable. Write the register so that someone who was not in the session can follow it: one row per finding, with the string, the applicant, the source and the date you checked. And record negative results too. “Searched, nothing found” is a finding, and it is the only way to show later that the search was made.

Reading each finding and what to do with it

The table maps what you may find in the list to the first action for each case. It assumes you have completed the review above.

Each row is a different position. In the first two, you are a participant in the ICANN process. In the next two, you are a possible objector, and the difference between them is practical: with several applicants, you do not yet know which one you will be dealing with, so your documentation has to hold up against each of them. The near-match row is the one where the legal analysis is least obvious, because the procedures built on similarity were not designed around trademark owners.

The last row deserves more attention than it usually gets. A string that nobody applied for in the ICANN round is not thereby absent from onchain registries. If your brand is not on the list at all, the ICANN part of your review is short, and the onchain part is the whole of it. For that part, Namespace Watch is the service that monitors the names of a brand onchain, so that the check does not depend on a periodic manual review.

A short action list for after the review

The review produces a classified register of findings. That register is a working document, and what follows depends on what is in it.

Inside the ICANN process, the actions are few and belong to your advisers. If your application stands alone, it proceeds through evaluation. If you are in contention, your advisers work on the contention set. If another party has applied for your string, counsel assesses whether an objection is justified and when it can be filed. In each case your own counsel decides; nothing in this article is legal advice.

The parallel track is onchain. For every string that matters to your organization, the question of who holds the onchain counterpart is separate from everything in the ICANN round, and it can be answered without waiting for any further stage of the program. In order:

• Check each string of your register against the onchain registries your customers are likely to meet.
• Where your organization holds the matching TLD, record which wallet holds it and who inside the organization controls that wallet.
• Where it is held elsewhere, decide with counsel whether that matters enough to act, and if so, how you wish to approach the holder.
• Where it does not exist, decide whether your organization wants it to.

This is where a desk such as ours has a role. Hush Partners is a private desk for onchain TLDs. An organization can mandate it to find and approach the holder of a TLD, and a lawyer or adviser acting for a brand will find the page for advisors written for that situation. Exchanges with the desk fall under a mutual NDA in a standard form, and the desk is reached through the contact form.

Questions people ask

Does the applied-for strings list confirm trademark rights?

No. The list records who applied for which string in an ICANN round. It is not a trademark register, and ICANN is not a trademark authority. An applicant’s appearance on the list does not create, confirm or transfer any trademark right. The program has procedures that take trademarks into account, but they do not replace trademark law, which varies by country. Your own counsel advises on your trademark position in each jurisdiction.

If we did not apply in this round, can we still affect an outcome?

In limited ways. An organization that is not an applicant may be able to use the program’s objection procedures, including the one based on legal rights such as trademarks, if it meets the conditions for bringing it. Governments have their own advisory channel within ICANN. The conditions for each procedure are set out in the program’s rules, and your advisers can assess which, if any, apply to you.

Is there a deadline to check the onchain counterpart of a string?

There is no ICANN deadline for reviewing onchain registries, because onchain TLDs sit outside ICANN’s remit. There is also no reason to delay. The check is quick, its result does not depend on any stage of the round, and knowing the answer makes every later conversation with counsel more precise.

What is the difference between a contention set and an objection based on confusion between strings?

A contention set means that two or more applicants asked for the same string, and the matter is settled among those applicants or through the procedures the program provides. An objection based on confusion concerns two different strings, where one party argues that the other string is too similar to coexist with its own. The two involve different parties and different questions, and one application can be affected by both.

Does holding an onchain TLD give any standing in ICANN’s objection procedures?

Not by itself. Those procedures are built around recognized interests such as trademark rights and defined communities, and an onchain registry record is not one of them. Whether the record of an onchain TLD has any use as supporting material in a wider argument about rights is a question for your legal advisers, not a conclusion that follows from the registry record.