# Contention sets: when several applicants want the same TLD > In an ICANN round, two applicants for the same string cannot both win. How contention is resolved in outline, and the parallel with onchain. Source: https://hush.partners/contention-sets-explained Category: Market & ICANN Published by Hush Partners. --- The DNS has room for only one operator per TLD. That constraint is simple in concept and expensive in consequence when two or more applicants submit independently for the same string inside an ICANN round. The resulting situation is called a contention set, and working through one adds preparation, legal work and an uncertain final cost to an application that was already a serious commitment. This article explains what a contention set is and how contention tends to be resolved in outline, what the experience means for a brand caught in one, and how the same question of priority plays out onchain, where no coordinating body exists and the registry record decides. Reading the two models side by side gives a cleaner view of what each one rewards, and of what that means for any organization that cares about a specific string. After reading you will be able to describe contention in the DNS to a client or colleague, explain why onchain priority is structurally different, and think through the position of a brand that faces a contested string in either system. The article stays at the level of structure. The rules of a given round are in ICANN's own documents, and your own counsel decides how they apply to you.
1,616applications going forward in the 2026 ICANN round
USD 227,000what the evaluation of one application is expected to cost in fees, advisers and registry operations aside
Noneannual renewal fee on a Freename TLD

Sources: trade press reporting on the round for the number of applications, ICANN's new gTLD program pages for the evaluation fee, and the Freename registry for the absence of a renewal fee.

## What a contention set is A contention set is the group of applications, within one ICANN round, that ask for the same string or for strings so similar that they could not safely exist side by side. The set is a formal administrative grouping, not a dispute in the legal sense. No party in a set has done anything wrong. Each applicant followed the same process and committed to the same evaluation. The conflict comes from the structure of the DNS itself: a TLD maps to exactly one operator, so only one application in the set can succeed. Contention becomes visible when the list of applied-for strings is published. ICANN calls that moment Reveal Day. Before publication, an applicant knows its own string and nothing about anyone else's. An organization can prepare an application over a long period and learn only from the published list whether it is the sole applicant for its string or one of several. Two features of a set are easy to miss. The first is that identity of strings is not the only trigger. Strings that are confusingly similar to one another can be grouped as well, because two TLDs that users cannot tell apart create the same problem as two operators of one TLD. An applicant can therefore find itself in contention with an application for a string it never considered a rival. The second is that a set is not fixed on the day it first appears. Its composition can change as applications are withdrawn, fail evaluation or are otherwise removed from the round. A set of three can become a set of one without any contest between the applicants, in which case the remaining application simply continues through the ordinary process. Contention is a state an application is in. It is not a verdict on the application. ## Why one string cannot have two delegations The reason contention exists lies in how the DNS root works. The DNS root is the single, globally shared list of TLDs. Each entry points to the authoritative name servers of one registry, the organization that keeps the records for every name under that TLD. Delegation is the act of adding a TLD to that list and pointing it at its registry. A second operator pointing the same TLD at different name servers would split the answer. Depending on which resolver a device asked, the same name would lead to different places. Every website, every mailbox and every service built on a name under that TLD depends on the answer being the same everywhere. Consistency of resolution is the property the whole system is built to protect. This is not an arbitrary policy choice. It reflects an engineering requirement: one name, one answer, whoever asks. ICANN coordinates the DNS root so that each TLD in it is unique, and the contention set is how that uniqueness is enforced at the point of application, before any delegation takes place. For applicants the consequence is plain. A contention set does not end in a compromise where each party receives a part of the string. One application proceeds to delegation and the others do not. Applicants may choose different paths out of the set, but the string itself is not divisible. That indivisibility is what gives a contested string its cost. In an uncontested application, the applicant competes only against the evaluation criteria. In a contested one, it also competes against other organizations that passed, or may pass, the same criteria. Meeting the standard is no longer enough. ## How contention tends to be resolved ICANN's application rounds have handled contention through a small number of routes. The rules that govern each route are written for each round and have differed from one round to the next, so what follows is the outline, not the procedure. The applicant guidebook of the round you are in is the only authority on what is open to you, in what order and under what conditions. ### Leaving the set The simplest resolution is that applications leave. An applicant that sees who else is in the set may conclude that the string is not worth a contest and withdraw. An application may also fail evaluation or be removed after an objection. Each departure shrinks the set, and a set reduced to a single application is no longer in contention. Whether an applicant can do anything other than stay or withdraw, for example by changing the string it applied for or by reaching an arrangement with another applicant, depends entirely on the rules of the round. Rounds have differed on these points. Do not assume that an option reported from one round exists in another. ### Priority for community applications ICANN's program has recognized that some strings name a community rather than a product or a company. An application made on behalf of a clearly defined community, with the support of that community, can ask to be evaluated for priority. If an independent evaluation finds that the application meets the standard, it prevails over the other applications in the set without a contest on price. The standard is demanding by design. Priority removes every other applicant from the string, so the claim to speak for a community has to be more than a label on a commercial plan. An application that asks for priority and does not obtain it remains in the set on the same footing as the others. ### The mechanism of last resort Where more than one qualified application remains and no priority applies, the round needs a final mechanism that always produces one result. In ICANN's program that mechanism has been an auction among the remaining applicants. The outcome then depends on what each participant is prepared to pay for the string, which no one can know at the application stage.
The outline of a contention set, from publication to a single application
  1. Strings are publishedICANN publishes the list of applied-for strings. Applicants learn for the first time whether anyone else asked for the same string.
  2. Sets are formedApplications for identical or confusingly similar strings are grouped. The grouping is administrative and says nothing about the merits of any application.
  3. Applications leaveSome applicants withdraw, and some applications fail evaluation or fall to an objection. A set reduced to one application is resolved.
  4. Priority is testedWhere the rules provide for it, a community-based application can be evaluated for priority over the rest of the set.
  5. A last resort decidesIf several qualified applications remain, a final mechanism set by the rules of the round, historically an auction, selects the one that proceeds.
Read the outline for its logic, not as a timetable. Each stage answers a different question. The first three ask whether there is still a conflict at all. The fourth asks whether one applicant has a claim to the string that is different in kind. The fifth asks only who values the string most, and it is reached when no better distinction is left. ## What a contention set means for a brand For a company that applied for its own name as a TLD, which is usually called a dotBrand application, a contention set is an unwelcome complication. A brand applicant typically applies for a string that is its trademark or a close variant of it. The published list may show that another party applied for the same string or a confusingly similar one: a company in another sector with the same name, or an applicant that wants the string as a generic word. Priority for communities is not generally a route for a brand. It exists for defined communities, such as a profession, a cultural group or a place, and a TLD run for one company's exclusive use does not ordinarily fit that description. A brand in contention therefore faces the general routes: wait for the set to shrink, use whatever options the rules of the round give it, or be prepared for the mechanism of last resort. This raises a budgeting question for [brand and legal teams](/brands-and-legal-teams). In the 2026 round, the expected evaluation fee of USD 227,000 per application, published on ICANN's new gTLD program pages, is committed before any contention is known, and it comes before advisers and registry operations. A contest adds a cost that cannot be predicted when the application is filed. The total has to be weighed against the value of that specific string to the organization and against the alternatives, including a different string. It also raises the question of what the brand would lose. If another applicant obtains the string, it will operate the TLD for its own purposes, which may be entirely legitimate: many words are trademarks in one sector and ordinary words or other companies' names elsewhere. Whether that outcome creates confusion for your customers, or is simply a missed opportunity, depends on the string and on your circumstances. Rules vary by country, and your own counsel decides what it means in your jurisdiction and your sector. A trademark matters in this picture, but not in the way teams often expect. It does not move an application to the front of a set. Its role lies in the separate objection procedures of the program and, after delegation, in the rights protection mechanisms that apply to names registered under a TLD. A brand team that plans for contention plans two things in parallel: its position within the set, and its rights outside it. ## Priority onchain: the first registration stands Onchain TLDs work on a different model. An onchain TLD is a TLD recorded on a blockchain by a naming registry instead of being delegated in the DNS root. There is no application window, no evaluation, no coordinating body to weigh competing claims, and no contention set. A Freename TLD, to take one registry, exists as a token recorded onchain and sitting in a wallet. Once a string is registered there, the registry does not issue the same string a second time. Priority is therefore settled at the moment of first registration. There is no process to join, no queue and no panel to satisfy. The earlier registration stands because the ledger records what was done and in what order, and a later attempt cannot displace an earlier entry. The registry record that settles this priority is public, open to checking by anyone on a block explorer. The same logic appears in a patent. U.S. patent US 12,401,618 B1 is held by Freename AG. It was filed on February 23, 2024 and granted on August 26, 2025, and the text is available on Google Patents. It covers rules-based resolution of names that collide: competing names are scored, and the result decides which one resolves. For a reader used to contention sets, the telling detail is that "first registration", defined as the earliest date of creation, is one of the criteria weighing in that score. Domain Name Wire reported on the grant. Read the patent for what it is. It describes a method. It is not a court ruling and it does not bind ICANN. Its interest here is that it states openly an assumption that onchain naming rests on: when two names collide, the date of creation is evidence that can be verified and that carries weight. The practical consequence for an organization that wants a specific onchain TLD is direct. If someone else registered it first, neither a legal argument nor a willingness to pay changes the registry record by itself. The holder controls the TLD, including the decision whether to transfer it. Only the holder of a TLD can issue names under it, and on Freename there is no annual renewal fee, so a holding does not lapse for want of a payment. Nothing in the model forces the question to be reopened. ## What each model rewards The DNS model rewards preparation and capital. An applicant that files a complete application, pays the evaluation fee, meets the criteria and, if the string is contested, comes through the contention process receives a delegation. The system is built to favor organizations able to run a public TLD responsibly over the long term. A registry is infrastructure that other people rely on, and the process tests for that before the string is handed over. The onchain model rewards early attention. A string is available until it is registered, and the moment of registration is the moment of priority. There is no review period and no waiting list. An organization that identifies a string that matters to it and registers it holds that string without further conditions. Each model has a cost that the other avoids. The DNS process is slow and demanding, and an organization with a strong claim can still lose a string to a better-funded applicant at the last stage. The onchain model is quick, and it gives no second chance: an organization that comes late has no procedure to appeal to, whatever its history with the name. One system can be entered late at a high price. The other can only be entered first, or through an agreement with whoever was first. It follows that the two models ask different things of a legal team. In the DNS, the work is concentrated in a window: the application, the evaluation, the contest if there is one. Onchain, there is no window, so the work is a matter of knowing where a string stands and deciding what, if anything, to do about it. | Criterion | DNS (ICANN round) | Onchain TLD | | --- | --- | --- | | What sets priority | The outcome of a process | The date of first registration | | When priority is settled | At the end of evaluation and contention | At the moment of registration | | Competing claims | Grouped in a contention set and resolved | None arise within a registry: the string is held | | Cost of entry | USD 227,000 expected evaluation fee, before advisers | A registration with the registry | | Ongoing obligation | A registry agreement with ICANN | No annual renewal fee on Freename | | Path for a later party | Apply and contest within a round | Agree a transfer with the holder | ## Where the two models meet: the same string in both systems The two systems are not sealed from each other. A string registered onchain may later be applied for in an ICANN round. A string an organization applies for through ICANN may already exist as an onchain TLD. The Freename patent names new ICANN TLDs colliding with established web3 namespaces as a problem it addresses, which shows that the overlap is treated as a real design question and not as a curiosity. Two situations follow. In the first, an organization obtains a string through ICANN. That delegation does not acquire or cancel the onchain TLD of the same string. The systems are parallel, not hierarchical. A company that secures `.yourbrand` in an ICANN round operates it in the DNS. If `.yourbrand` is also registered onchain, that registration stays where it is. A name such as `pay.yourbrand` could then mean one thing in the DNS and another in software that reads the onchain registry. Which of the two a user reaches depends on the software in use. Onchain names resolve outside the ICANN DNS root, so an ordinary browser does not open them without support, and support in wallets and browsers is partial and changes. The page on [what works with onchain TLDs](/whats-live) lists the capabilities with their sources. For most web traffic, the DNS answer is the one users get. Inside wallets and applications that support onchain names, the onchain answer can be. In the second situation, an organization is planning an ICANN application and has not looked onchain. If the string is already held there, the organization has two separate matters: the ICANN process, with contention if there are several applicants, and the onchain holding, if it wants consistent control of the string in both systems. The second is not solved by success in the first. It is a transaction with a holder, on its own timeline, and [brand namespace recovery](/brand-namespace-recovery) is the name we give to that work. The inverse applies to holders. A holder of an onchain TLD should know that if the same string is delegated in the DNS, the two will coexist, and that software which asks the DNS first will reach the ICANN operator. The onchain record is unaffected, but the practical reach of the TLD can be. For a holder weighing that coexistence, the [comparison of a dotBrand and an onchain TLD](/dotbrand-vs-onchain-tld) lays out both assets next to each other. No rule decides between the systems where they overlap. ICANN's process does not consult onchain registries, and an onchain registry does not wait for ICANN. Anyone who cares about one string in both places has to manage both positions deliberately, because neither system will do it for them. ## Lessons for an applicant The structure of contention supports several practical lessons, whichever system you are working in. **Assess the string before committing.** In the DNS, you do not know whether your string is contested until the list is published. You can still estimate the likelihood by asking who else could want it: companies with the same name in other sectors, sector associations, applicants interested in generic words. If contention is likely and a contest would be out of proportion to the value of the string, that is better known when the application is designed than discovered afterward. Onchain, the answer is immediate: a search of the registry shows whether a string is taken. **Know which route is open to you.** Priority for communities is not a route for most brand applicants. If you enter a set as a commercial applicant, plan for the possibility that the last-resort mechanism decides, and give your budget a ceiling before the contest begins instead of during it. If you are a genuine community applicant, the priority route deserves careful preparation, because it resolves the set on the strength of the claim instead of the size of the bid. **Keep your trademark position separate.** A trademark does not win a contention set, and it remains your main instrument everywhere else. The page on [trademark TLDs](/trademark-tlds) explains what a TLD that matches a trademark is in the onchain setting, where the question arises without any application round. **Understand what you are securing.** An ICANN delegation gives you the right to operate a TLD in the DNS under a registry agreement. An onchain TLD gives you a token held in a wallet and the exclusive ability to issue names under it. On Freename, a royalty program gives the holder a share of each registration fee for names registered under the TLD, advertised at up to half, subject to the registry's current terms and activation conditions. Neither asset substitutes for the other. They have different uses, different legal settings and different reach. [The glossary](/glossary) defines the terms if you need to brief colleagues who know only one of the two systems. **Onchain, register early or acquire.** If a string matters to your organization and it is available onchain, registering it is simple. If it is already held, the only path is an agreed acquisition. A holder is under no obligation to sell, so pressure does not help. A structured approach does: a clear mandate, a credible counterparty and a clean transfer. Hush Partners acts for organizations that mandate it to find and approach a holder, under a standard mutual NDA, and closing runs through [onchain escrow](/escrow-and-transfer) on an aftermarket. **Know what you do not hold.** For an organization with a well-known name, the question is not only whether it holds the matching TLD but whether someone else does. [Namespace watch](/namespace-watch) is the service that monitors the names of a brand onchain. As a first step, the free [Namespace Exposure Score](/namespace-exposure-score) scores how exposed a brand is onchain. A contention set is the DNS's answer to a constraint every namespace faces: one string, one operator. The DNS answers with a process. An onchain registry answers with a date. If a string matters to you, the next step is the same in both cases: find out where it stands in each system before you commit budget to either. ## Questions people ask ### Can a trademark owner win a contention set automatically? No. A trademark does not grant priority within a contention set. The program provides separate objection procedures through which a rights holder can challenge an application, and these run on their own standards, outside the contention process. A successful objection affects the application it targets. It does not hand the string to the objector, who still needs an application of its own to obtain the TLD. Your own counsel should assess whether grounds exist and what the prospects are. ### Does the UDRP help in a contention set? No. The UDRP is the dispute policy that applies to domain names registered under TLDs through registrars bound by ICANN's contracts. It addresses a registered name that conflicts with a trademark. A contention set concerns applications for a TLD that has not been delegated, so there is no registered name for the policy to act on. The UDRP becomes relevant later, for names registered under the TLD once it operates. ### If my string is not contested, is the application safe? It is free of contention, which is one risk among several. The rest of the process still applies: the application is evaluated against the criteria of the round, third parties can raise objections, and the applicant must conclude a registry agreement before delegation. An uncontested application competes only against the standard, but it still has to meet it. ### Can the same string exist on more than one onchain registry? Yes. Each onchain registry keeps its own record, and first registration settles priority within that registry only. The same string can therefore be registered on separate naming systems by different holders. That is the collision the Freename patent addresses, by scoring competing names to decide which one resolves. For a brand, it means that a check of one registry is not a check of the onchain landscape as a whole.