From application to delegation: the path of a gTLD

An application for a generic top-level domain that passes evaluation has earned a right to continue, and nothing more. No name resolves under the string. No browser knows it. The applicant holds a favorable result in a file, and several separate pieces of work still stand between that result and a working TLD.

Those pieces are slower, more technical and less public than the application itself. They are also where a brand owner’s internal teams take over from the advisers who wrote the application, and where a holder of an onchain TLD of the same string should understand what is, and is not, changing on the other side.

This article walks the road in order: what settles a contest between applicants, the contract with ICANN, the technical testing, the delegation into the DNS root zone, and the launch. It stays in outline. The rules of each round live in that round’s applicant guidebook and in the contract itself, and those documents, read with your own advisers, are the authority.

What a passed evaluation gives an applicant, and what it does not

ICANN opened an application round for new generic top-level domains in 2026, its first in more than a decade. According to trade press reporting, 1,616 applications are going forward in it, and ICANN’s new gTLD program pages give an expected evaluation fee of USD 227,000 for each one, a figure that leaves out advisers and the cost of running a registry. That fee buys the review of an application. It does not buy a TLD.

Evaluation, in one sentence: reviewers check that the string is acceptable, that the applicant is who it says it is, and that it has the financial and technical means to operate a registry, while third parties have a chance to comment and to object. An application that clears all of that is eligible for the stages below. An application that shares its string with another, or with a confusingly similar one, has one more thing to settle first.

The table gives the whole road at a glance. Each row is a section of this article.

The stages are sequential but the preparation is not: a careful applicant works on contracting, the technical platform and the launch plan while evaluation is still running. An applicant can also stop at several points. A passed evaluation, and even a concluded contract, are not promises to launch.

How a contest between applicants is settled, in outline

When two or more applications ask for the same string, or for strings judged too alike to coexist, they form what ICANN calls a contention set. Only one member of the set can be delegated. In one sentence: the set is resolved either because all but one applicant withdraw, or through a mechanism of last resort that the round’s rules provide, with some rounds giving priority to certain kinds of applicant, such as a community that the string names.

A contest is a pause for everybody in it. Nothing in the later stages starts for a string until the set is resolved, however strong any one application is.

A contest is also not a trademark proceeding. It decides which applicant proceeds, under the rules of the round. Whether another applicant should be allowed to apply for a string that matches your mark at all is a different question, raised through the objection procedures during evaluation, and it follows its own rules and its own timetable.

For a brand that did not apply and sees its name contested between others, the practical position is to watch. The outcome tells you whose registration policy your brand protection team will have to work with afterwards.

Contracting: the registry agreement with ICANN

The applicant that remains is invited to contract. The document is the registry agreement, a long standard contract between ICANN and the entity that will operate the TLD, known from that point as the registry operator. It is largely a contract of adhesion. The base text is the same for everyone, it is public, and there is little room to rewrite it. The negotiation that does occur is mostly about which of the available specifications and exemptions apply to this TLD.

What the operator promises

In general terms, the agreement commits the operator to four families of obligation.

• Technical service. The TLD’s name servers must answer reliably and quickly, the zone must be secured with DNSSEC, the system that lets a resolver verify that an answer is authentic, and the registry must offer the standard interfaces through which registrars create and manage names and through which registration data can be queried.
• Protection of the data. A copy of the registration data is deposited at regular intervals with an independent escrow agent, so that the registry could be rebuilt by someone else if the operator failed.
• Rights protection and abuse handling. The operator must run the launch phases that give trademark owners a first opportunity, honor the dispute procedures that apply to names under gTLDs, publish a point of contact for abuse reports and act on them.
• Fees and reporting. The operator pays ICANN recurring fees for as long as the TLD exists and files regular reports. The amounts are in the contract and are outside this article.

The agreement also contains whatever the applicant promised in its application. Commitments made to answer a comment or an objection during evaluation, for example a promise to restrict who may register, tend to be written into the contract and become enforceable.

The provisions made for a brand

A company that applied for its own trademark as a TLD, and intends to keep every name under it for itself and its affiliates, asks for the provisions written for that case. They recognize what is usually called a dotBrand. In outline, they relieve the operator of duties that only make sense for a TLD open to the public, such as treating all registrars alike and running a public priority phase for other people’s trademarks, and they deal with what becomes of the string if the operator stops, so that the mark is not simply handed to another operator.

Those provisions come with conditions. The string has to correspond to a registered trademark of the applicant, and the names under it have to stay inside the group and its licensees as the contract defines them. A brand that later wants to offer names to customers or to the public is no longer in that case and needs to look at its contract again with counsel. A side-by-side view of that model and its onchain counterpart is on the page comparing a dotBrand with an onchain TLD.

Who inside the company owns the contract

This is where the project changes hands. The application was a document, written by a small team and outside advisers. The registry agreement is an operating commitment, and somebody has to own it by name: the compliance contact ICANN writes to, the person who receives abuse reports, the function that pays the recurring fees, the team that decides which names exist. The useful internal decision at this stage is a plain one: which department will hold the TLD in its budget and its objectives once the advisers have left.

Who runs the technology

Very few applicants operate registry systems themselves. Most appoint a specialized back-end provider that already runs name servers, registration systems and data deposits for other TLDs. The applicant remains the registry operator and remains answerable to ICANN, so its contract with the provider should mirror the registry agreement: every service level ICANN can hold the operator to should be one the provider owes the operator. The provider does not decide policy. Which names exist, who may hold them and how a complaint is handled belong to the operator, and a brand owner sometimes discovers this late, when the provider asks for a registration policy and nobody has written one.

Pre-delegation testing: proving the registry works before it is switched on

A contract is a promise. Before a string enters the DNS root zone, ICANN wants evidence that the promise can be kept, because a TLD that answers badly harms more than its own operator: resolvers all over the world will be sent to its name servers. Pre-delegation testing is that evidence.

The checks are technical and largely documentary and automated. The table gives their subject in general terms. The exact test plan belongs to each round, and the trend over time has been to assess a back-end provider’s platform once rather than repeating the same examination for every TLD it carries.

For the applicant, this stage is mostly the provider’s work. The applicant’s share is to make sure that what is tested is what will run. A failed test is not a rejection: the usual outcome is a set of defects to correct and another attempt, at a cost in time.

Delegation: the string enters the DNS root zone

Delegation is the moment the TLD begins to exist for the internet at large, and it is a small act. The DNS root zone is a short public file that says, for every top-level domain, which name servers are authoritative for it. To delegate a string is to add its entry to that file: the names and addresses of the TLD’s name servers, and the record that lets DNSSEC validation continue from the DNS root down into the new zone.

The request is handled by the IANA functions, the part of ICANN’s organization that administers the DNS root zone. It verifies that the request comes from the contracted operator, that the name servers named in it respond as they should, and that the technical contacts are real. The change is then made in the file, and the DNS root servers distribute it. From that point, a resolver anywhere that asks about a name ending in the new string is referred to the operator’s name servers instead of being told that no such TLD exists.

What exists the moment after is modest. By convention the operator sets up a single informational name, the equivalent of nic.yourbrand, which carries the registry’s contact details and policies. Nothing else is there. No customer can register anything, and a dotBrand’s own sites have not moved.

One caution belongs here. Some strings were used informally inside private networks before they were ever delegated, and once such a string resolves, old systems can be confused. ICANN’s process includes measures for this risk. A company should check whether its own internal networks use the string it applied for.

Launch: from an empty zone to names in use

After delegation the operator is free to create names, within its contract. What launch looks like depends entirely on which kind of TLD it is.

A TLD open to registrants

An open TLD, generic or reserved to a community, launches in phases that the registry agreement makes compulsory in outline. The first is the sunrise, a period in which trademark owners whose marks are recorded in ICANN’s Trademark Clearinghouse can register the matching name before anyone else. It is followed by a claims period, during which a person who tries to register a name matching a recorded mark is shown a notice of that mark, and the mark’s owner is told if the registration goes ahead. Then comes general availability, when anyone who meets the registry’s policy can register through a registrar.

For a brand owner that did not apply, this is the stage that produces work: each open TLD that launches is a sunrise to consider and a registration policy to read.

A dotBrand

A brand TLD has no public to open to. There is no general availability, and under the brand provisions the operator does not run a sunrise for third parties. Launch is an internal program.

1. Write the naming policyDecide which names will exist under the TLD, who inside the group may ask for one, and who approves. Short is better than complete.
2. Choose the first namesPick a handful with a clear purpose, for example a home name, a login name and a campaign name, instead of mirroring every existing domain.
3. Appoint the registrar and set the technical defaultsAgree how names are entered, where they point, and how certificates and DNSSEC are handled for each one.
4. Test acceptanceCheck that the new names are accepted by the forms, mail filters, applications and partner systems that your customers and staff use, since older software sometimes rejects an unfamiliar ending.
5. Move one real servicePut a live, low-risk service on a name under the TLD and watch it before moving anything customers depend on.
6. Tell people what it meansExplain to customers that a name ending in the brand is the brand, which is the whole security argument for owning the TLD.

The fourth step is the one that surprises. A delegated TLD resolves everywhere in the DNS, but software written with a fixed idea of a valid domain can still refuse a new ending in a form field.

Operating the TLD after launch

The path has no final stage. A delegated gTLD is a service with a counterpart, ICANN, that monitors it for as long as it exists. Name servers are measured against the service levels. Data deposits are checked. Reports are due at regular intervals. Abuse complaints must be handled and the handling can be audited. Recurring fees fall due whether one name exists under the TLD or a million.

The contract runs for a long term with an expectation of renewal, and it can be assigned to another operator with ICANN’s approval, which is how gTLDs change hands. If an operator fails, ICANN maintains arrangements to keep a TLD’s critical functions answering while its future is decided.

This is the honest weight of a DNS TLD, and also its strength. The same apparatus that makes the path long is what makes the result dependable: a name under a delegated gTLD opens in every browser, carries email, receives certificates from the usual authorities and sits under dispute procedures that trademark owners know. No naming system outside the DNS offers that combination.

Where an onchain TLD of the same string sits during that path

An onchain TLD is a different object. On Freename, it is a token recorded on a blockchain and kept in a wallet, and whoever holds that token is the only party able to issue names under it. It carries no yearly renewal fee, and because the record is public, a block explorer shows it to anyone who looks. It lives outside the ICANN root, which is why a standard browser needs added support before it opens a name under it.

The same string can therefore exist twice: once as an application moving through ICANN’s process, once as a token that was created earlier or later, by the same organization or by someone unrelated. The two do not interact through any formal channel. The table shows what each is doing at each stage.

Three things follow from that table.

Nothing in ICANN’s path touches the token. Contention, contracting and delegation are events in the DNS. None of them transfers, cancels or modifies an onchain record. The reverse is equally true: holding the onchain TLD gives no standing in the ICANN process and no claim on the delegated string.

After delegation the same string can answer in two places. On the onchain side, the software that reads Freename names is a short list: Bitcoin.com Wallet, MetaMask by way of Freename’s resolver, and desktop browsers with the Freename Web3 extension installed. That coverage is partial and it changes. For software that looks only at the DNS, which is the ordinary case, the delegated gTLD is the only one that exists. For software that also consults an onchain registry, there are two candidates for one string, and the software’s own rules decide which it shows. A brand that monitors its names should watch both sides from delegation onward, and our namespace watch page describes the onchain side. The page on what works with onchain TLDs sets out the supported uses with their sources.

There is a published method for that collision, and it is only a method. U.S. patent US 12,401,618 B1, held by Freename AG, filed on February 23, 2024 and granted on August 26, 2025, describes resolving names that collide by scoring the competing names against weighted criteria and letting the score decide which one resolves. The earliest date of creation, which the patent calls first registration, is one of those criteria, and the text names new ICANN TLDs colliding with established web3 namespaces among the problems it addresses. The patent text is on Google Patents, and Domain Name Wire reported the grant. It is a description of a technique that software could apply. It is not a court ruling, and it does not bind ICANN or change what the DNS root zone contains.

For a brand owner who has applied, the practical reading is that owning the delegated string does not by itself settle what a wallet shows for the same string. If the brand intends to use its name for payments or wallet addresses, the onchain TLD is a separate asset to secure, and the note on trademark TLDs explains what that asset is. For a holder of the onchain TLD, the reading is symmetrical and calmer than it is sometimes presented: the ICANN applicant’s progress neither threatens the record nor guarantees a buyer, and nothing in the path creates a deadline. The page for holders covers that position at more length.

What to prepare while an application is still moving

If you are the applicant, the work that pays is the work that starts before it is needed. Name the internal owner of the registry agreement before the invitation to contract arrives. Read the base agreement and your own application together, and mark every promise in the application that will become a term. Ask your back-end provider what it needs from you for testing, and write the naming policy, even a one-page version, before delegation instead of after. Then decide, as a separate question with its own answer, what you want to happen to the onchain TLD of the same string: use it, hold it unused, or leave it alone.

If you hold an onchain TLD whose string is in the round, put together the plain record of your position: when the TLD was created, which names have been issued under it and to whom, and what use it has had. That record is useful whatever happens next, and assembling it commits you to nothing. Read the applicant’s public materials for what they intend, and resist reading intentions into silence.

If you are a brand owner who did not apply and want to know whether the onchain TLD matching your mark exists and who could be approached about it, that is the part Hush Partners handles. We act under mandate for an organization that wants a holder found and approached, every exchange sits under a standard mutual NDA, and the page for brands and legal teams explains how a file begins. The desk is reached through the contact form.

Questions people ask

Can an applicant sell or hand over its application before delegation?

Rounds generally restrict changes to who the applicant is while an application is under review, and a change of control has to be notified to ICANN and may be re-examined. After contracting, the registry agreement can be assigned to another operator with ICANN’s approval. The precise rules are those of the round and of the contract, so this is a question for the applicant’s counsel.

Can a string be removed from the DNS root zone after delegation?

Yes. A TLD whose agreement ends and which is not passed to another operator can be retired, and its entry is then taken out of the DNS root zone. ICANN’s process provides for a wind-down so that people holding names under it are warned, and for a brand TLD the names are the operator’s own.

Do names under a new gTLD work for email as soon as it is delegated?

Technically yes, because the name resolves in the DNS and mail systems look names up there. In practice the acceptance problem described above applies to email more than to anything else, since some older filters and forms reject endings they do not recognize. Test with the systems your correspondents use before moving any address.