Module 3 Application Submission

This module outlines key milestones and expectations for submitting a new gTLD application, highlighting key aspects such as the submission period and limits, backup application process, and application queuing and prioritization.

Module 3 also covers additional essential topics, including:

• DNS Stability and Root Zone Label Generation Rules.

• Application and string types.

• Fees and payments.

• Change requests.

This information is designed to clarify the application process, enabling applicants to prepare thoroughly and navigate it with confidence.

3.1 Submitting an Application

3.1.1 Application Submission Period

The application submission period is expected to open no later than 23:59 UTC on 30 April 2026 and remain open for 105 days, closing on 12 August 2026 at 23:59 UTC.

To be considered, all applications must be submitted by the close of the application submission period, as the system will not allow for late submissions. Applicants are encouraged to submit their completed applications as soon as practicable after the application submission period opens. Waiting until the end of this period to begin the process will not provide sufficient time to complete all the necessary steps and submit a complete application on time.

Applicants must pay their gTLD evaluation fee upon receipt of the invoice, and no later than seven days after the close of the application submission period for their application to be considered, as described in Section 3.3 Fees and Payments.

After submitting their application, applicants will not be able to make any changes outside the processes described in Section 3.8 Application Change Requests, which can only be submitted after String Confirmation Day.

3.1.2 TLD Application Management System

Applications must be submitted electronically through the TLD Application Management System (TAMS). Paper applications will not be allowed. Applicants are encouraged to consult the TAMS User Guide on the New gTLD Program website¹ for guidance on how to use the system to ensure proper understanding prior to submitting an application.

3.1.3 Application Questions

The application will consist of the following sections to be completed upon user registration:

1. Organization Information.

2. Financial Information.

3. gTLD Application Information.

To complete the application, users must answer a series of questions listed in Appendix 1 Application Questions and will be asked to provide supporting documents, as required. The system will validate that all mandatory fields include a response before applicants can submit an application.

If an applicant intends to submit more than one application, TAMS will accept the Organization and Financial Information only once when creating the organization record in TAMS. For any additional applications that the applicant wishes to submit, TAMS will only prompt the applicant to input the gTLD Application Information.

This means that the Organization and Financial Information of the applying entity will be locked upon submission of the first application. Applicants should ensure that the Organization Information is correct and that the Financial Information accounts for all applications that the applicant intends to submit prior to submitting the first application.

After submission, the application cannot be modified for the duration of the application submission period. Following the application submission period, the applicant will have the opportunity to make changes to the application(s) per the procedures described in Section 3.8 Application Change Requests.

3.1.4 Strings in an Application

Each application is for one gTLD and may include one or more of its allocatable variant strings, as applicable. An application may also be for one or more allocatable variant strings of an existing gTLD.²

3.1.5 Replacement String Selection

To potentially reduce the instances of string contention, applicants may also elect to submit replacement strings, as described in Section 5.1 Replacement Strings.

3.1.6 Application and String Types

This section outlines the various application types for new gTLD applications, including general, community, Geographic Name, Reserved Name, .Brand, IDN, variant of an existing gTLD, Primary IDN variant of a new gTLD, applications from governments, IGOs, and supported applicants (Government/IGO Applicant and Applicant Support Applicant application types). Each type may have unique requirements and processing steps that an applicant should be aware of when submitting an application for these Section 7.1 String and Application Types.

The table below provides an overview of the various application types, as well as the specific areas where differing requirements may apply. For detailed information, see the sections linked in Table 3-1.

Table 3-1: Overview of Application Types and Key Differences in Handling

3.1.7 Exclusive Use Strings (Closed Generics)

The Base Registry Agreement (Appendix 4), defines generic as “a string consisting of a word or term that denominates or describes a general class of goods, services, groups, organizations or things, as opposed to distinguishing a specific brand of goods, services, groups, organizations or things from those of others.” The base Registry Agreement describes “exclusive use” gTLDs as those that impose eligibility criteria that limit registrations exclusively to a single person or entity and/or that person’s or entity’s “Affiliates.” Registry operators are prohibited from operating generic gTLDs for exclusive use. This is often referred to as a prohibition on “closed generic” TLDs. Examples of potentially generic strings include .tree and .banana, but it should be noted that these examples might also qualify as a .Brand TLD.

The ICANN Board has resolved that closed generic applications will not be approved unless and until an approved methodology and criteria are established to evaluate whether a proposed closed generic domain would serve the public interest. During the application process, each applicant will be required to affirm that it is not applying for, and does not intend to operate, a closed generic string.

.Brand TLDs do not describe a general class of goods, services, groups, organizations or things and are therefore not subject to the prohibition on closed generics. Section 9.3 of Specification 13 of the Base Registry Agreement⁹ states that “.Brand TLDs are TLDs where: (ii) only Registry Operator, its Affiliates or Trademark Licensees are registrants of domain names in the TLD and control the DNS records associated with domain names at any level in the TLD.” See Section 7.3 .Brand TLD Eligibility Evaluation for more information.

3.1.8 Pre-Submission String Validations

3.1.8.1 Blocked Names Identification

The system has built-in checks before allowing an applicant to proceed with its application. When an applicant fills in the name of the applied-for string, the system will automatically check whether the applicant’s chosen string, including any variant strings, appears on the Blocked Names list, as described in Section 7.2.1 Blocked Names. If the string is found on this list, the system will prevent the applicant from proceeding with that string. To continue with the application, the applicant must revise the entry and select a different string that is not blocked.

3.1.8.2 Reserved Names Identification

When an applicant enters the applied-for string, the system will automatically check whether that string, including any allocatable variant strings, appears on the Reserved Names List. If it does, the exception process will be triggered, prompting the applicant to upload supporting documentation to demonstrate that they are the entity for which the name is reserved.

3.1.8.3 DNS Stability Review

New gTLD strings must not adversely affect the security or stability of the DNS. The DNS Stability Review determines whether an applied-for gTLD string complies with DNS and other relevant standards. This evaluation includes verifying the string for conformance with the technical requirements specified for gTLD strings. Applications will not proceed unless these checks have been completed successfully.

The applied-for gTLD string must comply with the following requirements:

1. The ASCII label must either be an NR-LDH¹⁰ or a valid A-label as described in section 2.3 of RFC 5890.¹¹

2. The NR-LDH label must consist entirely of letters (alphabetic characters a-z) in accordance with section 2.1 of RFC 1123.¹²

3. IDN gTLD strings must comply with IDNA2008¹³ (RFCs 5890-5893) and all standards-track RFCs that update IDNA2008.

4. IDN gTLD strings must comply with the applicable Root Zone Label Generation Rules.¹⁴ See Section 3.1.8.3.1 Root Zone Label Generation Rules for additional information on RZ-LGRs and processing of applications.

5. If a gTLD string is classified as a variant string of either an existing gTLD in the root zone or an applied-for primary gTLD, it must be an allocatable variant string of that primary gTLD (see Section 3.1.9 Internationalized Domain Names). The RZ-LGR is the sole source for calculating the variant strings of the primary gTLD and their disposition values, whether allocatable or blocked.

The verifications described above are incorporated into and implemented via TAMS. This means that these verifications will occur automatically when the applicant enters the string into its application.

If a string fails one of the verifications described above, the applicant will receive an error message explaining the detected problems, and the application will not be allowed to proceed.

In Section 7.7 Name Collision and Section 2.5 Security and Stability, additional issues and requirements are described relative to stability and security reviews.

3.1.8.3.1 Root Zone Label Generation Rules

3.1.8.3.1.1 Applicable RZ-LGR Version and Scripts and Languages Supported

IDNs are important to enable a multilingual Internet. In order to ensure a secure and stable DNS, the Root Zone Label Generation Rules (RZ-LGR)¹⁵ were developed to determine the validity of applied-for primary strings in different scripts as well as their allocatable variant strings.

The DNS is for identifiers, not for writing a language or its literature, so the RZ-LGR is not expected to allow the full range of expression of any natural language in the DNS, nor is any generated string by the RZ-LGR required to be a word in a language.

The RZ-LGR version 6 will be used, which integrates the scripts and writing systems noted below¹⁶ based on proposals developed by the community-based script generation panels (Generation Panels) and integrated by a list of expert reviewers (Integration Panel).

Arabic, Armenian, Bangla, Chinese (Han), Cyrillic, Devanagari, Ethiopic, Georgian, Greek, Gujarati, Gurmukhi, Hebrew, Japanese (Hiragana, Katakana, and Kanji [Han]), Kannada, Khmer, Korean (Hangul and Hanja [Han]), Lao, Latin, Malayalam, Myanmar, Oriya, Sinhala, Tamil, Telugu, Thaana and Thai.

The RZ-LGR contains a distinct LGR for each script or writing system. A writing system may contain more than one script, for example, the Japanese writing system consists of Hiragana, Katakana, and Kanji (Han) scripts.

3.1.8.3.1.2 Unsupported Script Applications

The RZ-LGR will only validate strings in scripts or writing systems integrated into it. Applicants will not be able to submit an application for a string in a script not integrated into the applicable version of the RZ-LGR.

In such a case, the potential applicant should first work with the script community to integrate the relevant script into the RZ-LGR, following the RZ-LGR Procedure.¹⁷ ICANN will support this process actively. The potential applicant may initiate this process with ICANN by emailing globalsupport@icann.org at any time. The applicant may be able to apply in a subsequent application period, if the relevant script has been integrated and made available in the applicable version of the RZ-LGR.

3.1.8.3.1.3 Choosing Primary and Variant Strings Using the RZ-LGR

The primary string is the main string submitted by the applicant, which must be valid as per the RZ-LGR calculation. Variant strings of the primary string are also calculated through the RZ-LGR, marked as either the allocatable and blocked variant strings. Collectively, the primary, allocatable and blocked variant strings are called a variant-string-set. For an existing gTLD, it is considered the primary string against which its variant-string-set will be calculated and submitted.

If the applicant is applying for a primary string, the applicant may also apply for additional allocatable variant strings of the primary string as part of a single application, but the applicant cannot apply for blocked variant strings of the primary string. A registry operator of an existing gTLD may also apply for allocatable variant strings of the gTLD in a single application, but cannot apply for blocked variant strings of the gTLD.

The choice of primary string (where primary is not an existing gTLD) within a variant-string-set will not change the total strings in the variant-string-set but it may change the subsets of allocatable and blocked variant strings within this set. Therefore, when selecting the primary string, applicants should consider the corresponding allocatable and blocked variant strings that will be created. The LGR Tool made available by ICANN at https://lgrtool.icann.org can be used to determine allocatable variant strings for a primary string.

3.1.8.3.1.4 Outcomes of Using RZ-LGR Calculations

The RZ-LGR will be applied to a primary string to determine if the primary string is valid as a TLD per the RZ-LGR.

The RZ-LGR will be applied to a variant string of a primary string or existing gTLD to:

1. Determine if the variant string is valid as a gTLD per the RZ-LGR.

2. Determine if it is a variant string of the primary string or the existing gTLD identified by the applicant.

3. Determine if it is an allocatable variant string of the primary string or the existing gTLD.

Strings that mix code points in LGRs for different scripts may be marked as invalid.

3.1.8.4 Challenging the Pre-Submission String Validations

In cases where an applicant believes it is being prevented from submitting its application or has to provide additional documentation because the pre-submission string validations have been incorrectly applied or miscoded, it will have the opportunity to file a challenge no later than 14 days prior to the close of the application submission period,¹⁸ as described in detail below:

• Blocked Names Identification: A system error in the automated Blocked Names Identification process resulted in an applicant’s string being incorrectly classified as a Blocked Name. Consequently, the applicant was unable to proceed to submission. See Section 3.1.8.1.

• Reserved Names Identification: A system error in the automated Reserved Names Identification process resulted in an applicant’s string being incorrectly classified as a Reserved Name. Consequently, the applicant was able to proceed to submission only by providing the requisite supporting documentation as specified for Reserved Names exceptions. See Section 3.1.8.2.

• DNS Stability Review: A system error in the automated DNS Stability Review tool calculation and the identified system error caused the applicant to fail the DNS Stability Review. Consequently, the applicant was unable to proceed to submission. This challenge mechanism does not apply for scripts not supported by the RZ-LGR. See Section 3.1.8.3 and Section 3.1.8.3.1.2 Unsupported Script Applications.

The Challenge Panel will communicate the result of the Pre-Submission String Validations within five days of an applicant filing the challenge.

3.1.9 Internationalized Domain Names

Internationalized Domain Names (IDNs) are domain names represented by characters other than the ASCII characters (letters a-z, for top-level domains). Such domain names are formed using characters from a script outside of ASCII (for example, Arabic or Chinese).

ICANN expects a diverse set of applications for new gTLDs, including IDNs, creating significant potential for new uses and benefits to Internet users across the globe, as well as promoting choice and digital inclusion.

3.1.9.1 Rules for IDNs and Their Variants

An applied-for IDN must comply with IDNA2008¹⁹ (RFCs 5890-5893)²⁰ and all of its successors. The IDN must also comply with the applicable version of the RZ-LGR. See Section 3.1.8.3.1 Root Zone Label Generation Rules.

An IDN can be represented in Unicode characters (called U-label) and its equivalent ASCII mapping prefixed by “xn--” (called A-label) as per IDNA2008. Applied-for IDNs (in U-label format) must be longer than a single character. This means that the U-label must have at least two code points with the General Category value²¹ of ‘L’ as defined by the Unicode Standard. The code points with the General Category value of ‘M’ will not be counted toward the length for purposes of determining whether an applied-for IDN is a single character. For additional string requirements, also see Section 3.1.8.3 DNS Stability Review.

The RZ-LGR is the sole source to calculate the variant strings and their disposition values (allocatable or blocked) for all existing gTLDs and all applied-for primary strings.

The LGR Tool made available by ICANN can be used to determine allocatable variant strings for a primary gTLD or applied-for string.²²

3.1.9.2 Application Submission of IDNs

An applied-for IDN that conforms to the mandatory string requirements, including IDNA 2008, as well as the RZ-LGR, can be submitted through TAMS. Where the RZ-LGR calculation during the algorithmic check deems an applied-for gTLD as “invalid” or “blocked” (for example, in case the applied-for string is a variant string), such application for a non-conforming string will not be accepted by the application submission system. See Section 3.1.8.3 DNS Stability Review for a more complete list of checks performed. The applicant may challenge the RZ-LGR calculation by the application submission system. See Section 3.1.8.3.1 Root Zone Label Generation Rules.

3.1.9.2.1 Application Submission of New Primary IDN and its Variant Strings

An applicant can apply for a new primary IDN along with one or more of its allocatable variant strings. These variant strings will only be allocated to the same applicant as the primary IDN gTLD and must share the same back-end registry service provider while they are delegated.

Allocatable variant strings can be applied for from the set generated using the RZ-LGR. An application for an allocatable variant string cannot precede an application for its primary IDN gTLD. A primary IDN gTLD and any of its allocatable variant strings being applied for in the same round must be submitted through one application. After successful evaluation, the primary gTLD and its applied-for allocatable variant strings will be allocated to the same registry operator through one Registry Agreement. An applicant cannot apply for a blocked variant string of the new primary IDN, as calculated by the RZ-LGR. See Section 3.3 Fees and Payments for details on application fees for allocatable variant strings.

Once the primary IDN gTLD is applied for, it cannot be changed, except for the applied-for primary string of a .Brand IDN gTLD application that has been placed in contention (see Section 5.3 .Brand String Change Requests).²³

After submission of an application, the applicant may withdraw any of the applied-for variant strings from that application by submitting an Application Change Request (Section 3.8), but cannot add any other allocatable variant string not originally applied for in that application. If an applicant withdraws its application for a primary IDN gTLD, all applied-for variant strings will also be withdrawn.

3.1.9.2.2 Application Submission of Variant Strings of Existing gTLDs

An applicant can apply for variant strings of an existing gTLD only if it is the same legal entity as the registry operator for the existing gTLD. All variant strings must share the same back-end registry service provider as the existing gTLD while they are delegated. The back-end registry service provider must be approved through the RSP Evaluation Program.²⁴

Allocatable variant strings of an existing gTLD can be applied for from the set generated using the RZ-LGR and must be submitted in a single application. After successful evaluation, the applied-for allocatable variant strings will be allocated to the existing gTLD registry operator. The registry operator will need to transition to the 2026 Round Base Registry Agreement, and the existing gTLD and all variant strings will be allocated through one Registry Agreement. An applicant cannot apply for a blocked variant string of an existing gTLD, as calculated by the RZ-LGR. See Section 3.3 Fees and Payments for details on application fees for allocatable variant strings.

After submitting an application, applicants may withdraw any applied-for variant string but cannot add any other allocatable variant string not originally applied-for in that application.

3.1.9.3 Requirements and Processing

3.1.9.3.1 Prioritization of Processing of Variant Strings of Existing gTLDs

As a one-time exception, applications for allocatable variant strings of existing gTLDs from the 2012 Round will receive processing priority over all other applicants, including those IDN applicants that choose to participate in the prioritization draw. See Section 3.7 Order of Application Processing and Prioritization Draw.

3.1.9.3.2 Multiple Applicants for the Same Primary String or its Variant Strings

If different applicants apply for strings from the same variant-string-set, then such applications will be placed in contention, and only one applicant will be selected through the contention resolution process. This means that applied-for primary strings and their applied-for allocatable variant strings will participate as a set in any contention resolution mechanisms, that is, Community Priority Evaluation (Section 5.4) or ICANN New gTLD Auction (Section 5.6) (see Module 5 Contention Set Resolution).

Any application for an allocatable variant string of an existing gTLD will be rejected if it is made by an applicant that is not the registry operator of that existing gTLD.

3.1.10 Registry Service Provider Selection

Applicants must specify which Registry Service Providers (RSPs) will deliver critical registry services if their application proceeds to delegation. The list of evaluated RSPs can be found on the Registry Service Provider (RSP) Applications page.²⁵

Applicants may engage external third-party RSPs or seek ICANN’s approval to deliver critical registry services themselves as RSPs through the RSP Evaluation Program.

Each RSP needs to only be evaluated once, regardless of the number of gTLDs it supports and receives qualification to provide specific Registry Services.

3.1.10.1 Expectations for RSP Selection When Submitting an Application

Applicants are encouraged to identify their RSPs and intended Registry Services upon submitting their application to avoid potential delays in processing. However, an applicant may also submit the application without specifying RSPs, choosing to do so just before Applicant and Application Evaluation.

Early selection of RSPs and Registry Services, ideally during preparation, is encouraged, as applicants may find it important to work closely with the selected RSPs during the application submission period to complete these parts of the application correctly.

If an applicant has not identified an RSP(s) to cover the required minimum critical registry functions by the time of the Applicant Evaluation Procedures (Module 6) and String and Application Evaluation Procedures (Module 7), Extended Evaluation may be selected to allow the applicant more time to provide the requested information from its chosen RSPs.

The applicant may specify or change its selected RSPs after submitting its application through the Application Change Request (Section 3.8) process.

During the contracting process, ICANN will seek confirmation from an applicant’s identified RSP that it acknowledges plans to support that particular applicant and gTLD or gTLDs.²⁶

3.1.10.2 Registry Functions and Types of RSPs

The Base Registry Agreement requires that registry operators support the following critical registry functions: Domain Name System (DNS), Domain Name System Security Extensions (DNSSEC), Extensible Provisioning Protocol (EPP), Registration Data Access Protocol (RDAP), and Data Escrow. There are four types of RSPs, each delivering a set of unique functions necessary for the operation of the critical registry functions:

1. Main RSPs, which operate the registration database for a gTLD, undertake escrow of domain registration data, and operate the EPP and RDAP services for a gTLD. A gTLD can only have one Main RSP.

2. DNS RSPs, which operate one or more DNS servers for a gTLD. A gTLD may use multiple DNS RSPs.

3. DNSSEC RSPs, which undertake the cryptographic operations necessary for DNSSEC. A gTLD can only have one DNSSEC RSP.

4. Proxy RSPs, which perform registration validation to comply with applicable local law in a given jurisdiction. This is an optional additional registry service that must be approved by ICANN in the RSP Evaluation Program.²⁷ A gTLD may use multiple Proxy RSPs, each of which provides access to a different jurisdiction.

An organization may be evaluated for one or more types of RSPs in the RSP Evaluation Program.²⁸

During the application process, the applicant will be asked to provide the RSPs it intends to use, and the additional Registry Services, if any, it intends to offer in the proposed gTLDs. At a minimum, the applicant must provide a Main RSP, a DNSSEC RSP, and a DNS RSP.

3.2 Administrative Check and Preparation for Reveal Day

Following the close of the application submission period, ICANN will perform necessary administrative due diligence and verify whether the evaluation fees have been received. ICANN will review the list of submitted applications and place applications for identical strings into contention sets in preparation for Reveal Day.

The administrative check is expected to be completed for all applications in a period of approximately eight weeks, subject to the overall application volume. In the event of a high volume of applications that prevents ICANN from processing all applications within the designated period, ICANN will post an updated timeline as soon as feasible.

3.3 Fees and Payments

This section describes the fees to be paid by the applicant, including payment instructions.

3.3.1 gTLD Evaluation Fee

The gTLD evaluation fee is set so that ICANN can recover all applicable costs associated with the New gTLD Program. This approach ensures that the Program is fully funded and revenue-neutral, and will not be subsidized by contributions from other ICANN funding sources, including gTLD registry operator and registrar fees and contributions from ccTLDs and Regional Internet Registries. ICANN has estimated that 2026 Round evaluations, contracting and delegation processes will continue through approximately 30 June 2030,²⁹ by which time all applications submitted are expected to have proceeded through these stages of the Applicant Journey (Module 1). The gTLD evaluation fee covers all required evaluations, including Extended Evaluation where applicable, during that time frame.

ICANN recognizes that exceptional cases may arise, requiring the extension of these services for a limited number of applications beyond the June 2030 time frame.

The gTLD evaluation fee is USD 227,000 per application for all applicants, except for those submitted by qualified Applicant Support Program (ASP) applicants and variant applications that meet the criteria below. The fee is due upon receipt of the invoice, and complete payment must be received by ICANN no later than seven days after the close of the application submission period. If the applicant has not paid the gTLD evaluation fee within this seven-day period, the application will generally not be processed any further and will be canceled. In the unlikely scenario of an ASP applicant still awaiting results of the ASP evaluation, the applicant may need to submit an application without payment. The application would be put on hold until the appropriate gTLD evaluation fee has been determined and payment has been received.

3.3.1.1 gTLD Evaluation Fee for Applications with Variant Strings

3.3.1.1.1 For New Applicants

The gTLD evaluation fee covers one application for a primary gTLD and up to four variant strings. If an applicant wants to apply for more than four variant strings under one primary string, the applicant must pay the USD 227,000 evaluation fee for each additional allocatable variant beyond the fourth variant. Additional fees for Conditional Evaluations (see Section 3.3.2) may apply.

3.3.1.1.2 For Existing gTLD Registry Operators from the 2012 Round

In this 2026 Round, a gTLD registry operator from the 2012 Round may apply for up to four variant strings of its existing gTLD with its application fee waived as a one-time exception. If applying for more than four variant strings, it will pay the full gTLD evaluation fee for each additional allocatable variant beyond the fourth variant. Additional fees for Conditional Evaluations (see Section 3.3.2) may apply.

3.3.1.2 gTLD Evaluation Fee for Qualified Applicant Support Program Applicants

Qualified ASP applicants will receive a 75-85% reduction of the gTLD evaluation fee. Therefore, the discounted gTLD evaluation fee for a qualified ASP applicant will range between USD 34,500 and USD 56,750 (including the USD 2,500 deposit submitted to confirm ASP financial viability). The exact amount will depend on the final number of qualified ASP applicants. ICANN will inform qualified ASP applicants that they qualify for a minimum of 75% discount, and the final discounted amount is expected to be shared 12-16 weeks after the close of the ASP application submission period. As indicated in Section 3.3.1.1 gTLD Application Fee for Applications with Variant Strings, the discount on the gTLD evaluation fee includes up to four variant strings. Supported applicants that apply for more than four variant strings will need to pay the USD 227,000 evaluation fee for each additional variant beyond the fourth.

3.3.2 Conditional Evaluations

In addition to the required evaluations covered by the gTLD evaluation fee, there are a number of conditional evaluations that applicants may elect or are required to undergo to obtain a specific status or exemption. The applicant fees for these conditional evaluations are also set to recover the costs associated with conducting these evaluations, which may be carried out or supported by third-party vendors. This will ensure that the Program is fully funded and revenue neutral, and will not be subsidized by contributions from other ICANN funding sources, including gTLD registry operator and registrar fees and contributions from ccTLDs and Regional Internet Registries. Selection of some of these conditional evaluations, such as Name Collision High-Risk String Mitigation Plan review, will only be available later in the evaluation process. For further details about what each of these evaluations entails, see the relevant sections that have been indicated in Table 3-2: Conditional Evaluations and Fees.

Applicants will be notified by ICANN when fees for conditional evaluations are due. This may be shortly after the close of the application submission period or at the time the evaluations take place. If an applicant fails to pay for a conditional evaluation, depending on the type of conditional evaluation, the applicant may be asked to submit an Application Change Request to remove that section of their application to proceed. Otherwise, required conditional evaluations must be paid on time to avoid disqualification.³⁰

For evaluations marked with one asterisk (*), a qualified ASP applicant will receive the same percentage reduction as it received on the gTLD evaluation fee. Before granting this reduction, ICANN will request that the ASP applicant verify continued eligibility to receive further financial support (see also ASP Terms and Conditions).³¹

Name Collision High-Risk String Mitigation Plan Evaluation has been marked with two asterisks (**) and must be performed for each string that has been identified as a high-risk string. As a result, the conditional fee must be paid for each string in the set that has been identified as a high-risk string.

Table 3-2: Conditional Evaluations and Fees

3.3.3 Refunds

3.3.3.1 gTLD Evaluation Fee Refunds

In certain circumstances, applicants may request a partial refund³² of the gTLD evaluation fee originally paid to ICANN as part of the application process, as set out below. The refund amount will vary based on the stage of the process at which the withdrawal is requested or the application status changes to Terminated (see Section 3.9 Application Statuses).

The application process will include three distinct refund windows, as follows:

1. The first window spans from the receipt of the applicant’s gTLD evaluation fee to ten days after String Confirmation Day, during which 65% of the gTLD evaluation fee paid is eligible for refund.

2. The second window covers the period from 11 days after String Confirmation Day until the start of the Application and Applicant Evaluation, with 35% of the gTLD evaluation fee paid eligible for a refund. An applicant will be notified when the Application and Applicant Evaluation is expected to be initiated. This notification will happen after the conclusion of the String Evaluation phase, or contention set resolution, if applicable.

3. The third window extends from the initiation of an Application and Applicant Evaluation up to the point at which the applicant enters into a Registry Agreement with ICANN, allowing for a 20% refund of the gTLD evaluation fee paid.

For further details on these windows and which evaluations and processes take place in these windows, see Module 1 The Applicant Journey.

Fees for conditional evaluations that have been paid but for which the evaluation has not started yet may also be refunded if the application status is categorized as Withdrawn, Will Not Proceed or Terminated.

3.3.3.1.1 Applicant Withdrawal

An applicant may withdraw an application at any time prior to its execution of the Registry Agreement with ICANN. An applicant that elects to withdraw its application is permitted to request a partial refund of the fees paid to ICANN, as set forth below. The refund request must be made as part of the withdrawal request. If the applicant does not request a refund at that time, it will forfeit the right to do so later.

3.3.3.1.2 Terminated Applications

ICANN will notify an applicant if its application will not proceed and has been assigned the Terminated status (see Section 3.9 Application Statuses). Upon receiving this notification from ICANN, the applicant may request a refund consistent with the refund window and percentage of the gTLD evaluation fee eligible for refund, as outlined below. To be eligible for a refund, the applicant must request a refund within 90 days of being notified of the Terminated status. Applicants that do not request a refund within this 90-day window will be considered to have forfeited their ability to request a refund.

3.3.3.1.3 Refund as a Result of Material Changes

Any applications that are withdrawn due to changes with a material impact to the Applicant Guidebook or Program processes as defined in the Appendix 6 Predictability Framework will be eligible for a refund. As part of its decision on any changes with a material impact to the Guidebook or Program processes, the ICANN Board will confirm applicant eligibility for a refund as well as the percentage of the gTLD evaluation fee paid that is eligible as a refund. An applicant that withdraws its application as a result of such changes must provide a formal declaration accompanied by supporting documentation to demonstrate that the change: (1) altered the status of its application, or (2) affected the outcome of the application’s evaluation, or (3) had a non-trivial financial or operational impact on the applicant, or (4) had a non-trivial impact on the timeline of its application processing and evaluation.³³ Consistent with Section 3.3.3.1.1 Applicant Withdrawal, a request for a refund as a result of such a change must be made as part of the withdrawal request.

3.3.3.1.4 Refunds for Strings Identified as High Risk of Name Collision

An applicant that decides to withdraw its application within 90 days of its applied-for string being determined as high risk of name collision, and that does not submit a Name Collision High-Risk String Mitigation Plan for evaluation, is eligible to receive a refund of 100% of the gTLD evaluation fee paid. Any applications for strings that have been determined to be at high risk of name collision in a previous round or were not approved as a result of such determination will not be eligible for this refund (.HOME, .CORP, and .MAIL).

3.3.3.1.5 Refund When a String is Eliminated Because of IDN ccTLD Application Process

In instances where a gTLD applicant has obtained the support or non-objection from the relevant government or public authority, yet the gTLD application does not proceed due to Visual Similarity with a string requested in the IDN ccTLD application process, a full refund of the gTLD evaluation fee shall be issued to the gTLD applicant. This refund is applicable provided that the gTLD application was submitted prior to the publication of the successfully evaluated ccTLD.

3.3.3.2 Application Volume Refund

ICANN applied a conservative approach in estimating the recovery of implementation costs before receiving a single application. To ensure that implementation efforts are recovered, the portion of the gTLD evaluation fee pertaining to estimated implementation expenses was based on an assumption of 1,000 fully paid applications. As a result, a volume refund may be applicable if two conditions are met: 1) more than 1,000 applications are received; and, 2) the implementation costs for the 2026 Round have been recovered.

Applicants will be requested to indicate at the time of application submission whether they want to receive a volume refund, should one be applicable.³⁴ If the applicant does not select the option to receive a volume refund, it will be considered to have forfeited its ability to receive a volume refund. After Reveal Day, ICANN will notify applicants that have selected the volume refund option if one is applicable. The volume refund amount will be calculated based on the number of applications received and the final amount of costs incurred for implementation. Only paying applications for the 2026 Round will be eligible for the volume refund, with qualified ASP applications receiving a volume refund proportional to the amount of fee paid.

3.3.4 Fees Required in Some Cases

Applicants may incur additional fees and costs when specialized process steps are applicable. Further details can be found in the respective sections that cover these specialized processes. Those possible additional fees include:

• Objections and appeal costs. See Section 4.5.6 Objections and Appeals Costs.

• Auctions. See Section 5.6 ICANN New gTLD Auction.

• .Brand TLD String Change Request documentation verification. See Section 5.3 .Brand TLD String Change Request.

3.3.5 Fees During Registry Operations

For applicants that are successful in all application processes and become a registry operator, there are other fees they will need to pay as a registry operator. These are outlined in the Appendix 4 Base Registry Agreement and include the registry fixed fee and registry-level transaction fees.

3.3.6 Payment Methods

Payments to ICANN must be made via wire transfer, Automated Clearing House (ACH), International SWIFT payment, or other method approved by ICANN for this service. Checks, cash and credit card payments are not accepted. Instructions for making a payment will be available in TAMS.

Payments to Dispute Resolution Service Providers should be submitted in accordance with the provider’s rules. See Section 4.5.6 Objections and Appeals Costs.

3.4 Reveal Day

Absent extraordinary circumstances, ICANN expects to publish the list of all applications that have passed the Administrative Check, including the relevant applied-for strings and any variant strings and replacement strings (if applicable), to the New gTLD Program website³⁵ on Reveal Day, no later than nine weeks following the close of the application submission period. The public portions of each application will also be made available, alongside a list of contention sets containing applications for identical strings. Certain communications and activities will be prohibited starting on Reveal Day for applications in contention. See Section 5.2.3.1 Prohibited Communications and Activities.

3.5 Replacement Period

Once applicants have access to the full list of applied-for strings, as well as any variant and replacement strings, they will have the opportunity to replace their original applied-for string with their replacement string. Applicants that have selected an eligible replacement string will have a 14-day Replacement Period to notify ICANN via TAMS of their intention to replace their original applied-for string with the replacement string identified in their application. See Section 5.1 Replacement Strings.

3.6 String Confirmation Day

On String Confirmation Day, ICANN will post an updated list of applications and their chosen strings (whether original or replacement, as noted above). An updated list of contention sets made up of applications for identical strings will also be published. See Section 5.2.4.1 Contention as a Result of Applications for Identical gTLD Strings.

3.7 Order of Application Processing and Prioritization Draw

The Priority Number assigned to an application determines the general order in which ICANN processes the successive stages of the application process. Priority Numbers will also be used to determine the general order of the release of evaluation results and execution of Registry Agreements.³⁶

Once assigned, an application’s Priority Number will not change, nor can it be transferred between applicants or applications.

Specific rules apply to the prioritization of applications for IDNs. See Section 3.7.3 Prioritization of IDN Applications.

3.7.1 The Prioritization Draw

Application processing priority will be established by a Prioritization Draw event (the Draw), which will be a live event. During this event, each application entered into the Draw will have a physical paper ticket drawn manually from the pool of participating applications and will be assigned a Priority Number.

Participation in the Draw is optional. For details on how processing priority is assigned to applications not entered into the Draw, see Section 3.7.4 Applications Not Included in the Prioritization Draw.

3.7.2 Participation in the Draw

A Prioritization Draw is expected to be held no later than 30 days after String Confirmation Day. Tickets for the Draw will cost USD 100 and must be purchased in person; online purchases are not available. To participate in the Draw, an applicant, through a designated representative or proxy, must purchase a ticket in person for each application that the applicant wants prioritized.

Applicants cannot attend the Draw in person but can follow the live event virtually.

ICANN expects to announce full details of the Draw no less than 30 days in advance.

Only one ticket may be purchased per application. If an applicant submits multiple applications, the applicant must buy a separate ticket for each application it would like to enter into the Draw.

3.7.3 Prioritization of IDN Applications

Applications entered into the Draw will be randomly drawn in groups of 500 until all applications have received a Priority Number. IDN applications will be prioritized in the Draw according to the following order and rules:

1. IDN applications for allocatable variant strings of 2012 IDN gTLDs.

   • As an exception for this application round, applications for allocatable variant strings of IDN gTLDs from the 2012 Round will be processed ahead of other new gTLD applications, including all other applications for IDN primary strings that have been entered into the Draw. These applications will be automatically included in the Draw without the need for applicants to purchase a ticket. These applications will be separated and drawn first.

2. Once all applications for variant strings of 2012 IDN gTLDs have been drawn, if there are fewer than 125 remaining IDN applications electing to participate in the Draw:

   • All IDN applications will be drawn first and assigned Priority Numbers before any non-IDN applications.

3. However, if there are 125 or more remaining IDN applications electing to participate in the Draw:

   • 25% (125) of the first group of 500 applications will be IDN applications, selected at random as part of the Draw. These selected IDN applications will then be drawn first and assigned Priority Numbers.

   • The remaining 75% (375) of applications in the first group to receive Priority Numbers will comprise both IDN and non-IDN applications. These will be randomly selected from the remaining pool of applications taking part in the Draw and will be drawn and prioritized at random.

4. For each subsequent group of 500 applications electing to participate in the Draw:

   • The first 10% of each group will be IDN applications selected at random, drawn first and prioritized, continuing until no IDN applications remain.

   • The remaining applications in each group will be randomly selected from the pool of remaining IDN and non-IDN applications, drawn and prioritized at random.

3.7.4 Applications Not Included in the Prioritization Draw

Applications not entered into the Draw will also be randomly drawn and allocated a Priority Number in groups of 500 applications, but only after all applications entered into the Draw have been drawn and prioritized. For example, if the final Priority Number allocated via the Draw is 1000, the lowest Priority Number an application not entered into the Draw can receive is 1001.

In each group of 500 applications, the first 10% must consist of IDN applications until there are no more left to draw. The remaining applications in each group will be selected at random and prioritized from the pool of remaining IDN and non-IDN applications.

3.7.5 Exceptions to Processing According to Priority Number

ICANN will aim to maintain priority order across applications being processed at each stage. However, this order may be affected by operational capacity and other application-related issues such as, but not limited to: objections, GAC Consensus Advice, Extended Evaluation, contention sets, ICANN Accountability Mechanisms, or processing holds due to Application Change Requests. Ongoing processing activities are likely to be paused until these processes have been completed. To avoid delays and ensure continued progress for other applications, ICANN will proceed with the next application in the priority order. Once ICANN determines that the issues affecting the paused application have been cleared, it will resume processing according to the assigned Priority Number.

3.8 Application Change Requests

This section describes the process for applicants to update inaccurate or outdated information in their application and to make other changes, as required. These Application Change Requests (ACRs) are reviewed by ICANN based on the change request determination criteria (see Section 3.8.2 Change Request Determination Criteria) and are subject to ICANN’s approval.

Material ACRs will be published for a 30-day comment period, as described in Section 3.8.3 Application Change Request Types and Required Processes, giving the general public the opportunity to provide input.

3.8.1 Application Change Requests Overview

Applicants may request changes or updates to Organization, Financial or Application Information throughout the application processing, from String Confirmation Day through Registry Agreement execution.

If at any time during the Program information submitted in response to Application Questions (Appendix 1) or the Organization Information becomes untrue, inaccurate, or outdated following, for example, agreement between ICANN and the applicant as an outcome of an evaluation,³⁷ the applicant must submit an ACR promptly (and in any case within seven days of becoming aware of any fact or circumstance giving rise to such obligation). ICANN reserves the right to require a re-evaluation of the application in the event of a material change,³⁸ which could result in additional fees. Failure to notify ICANN of any change in circumstances that would render any information provided in the application false or misleading may result in the application not being allowed to proceed.

An applicant may request changes to many aspects of its application, as described in Section 3.8.3 Application Change Request Types and Required Processes. However, an applicant may not change the applied-for string, except in cases where the applicant has qualified as a .Brand TLD (see Section 7.3 .Brand Eligibility Evaluation) and is in contention. .Brand String Change Requests follow the process described in Section 5.3 .Brand String Change Request.³⁹

Certain ACRs may require re-evaluations or other processes, as described in Section 3.8.3 Application Change Request Types and Required Processes, which may involve additional fees for the applicant. For more information on evaluations and fees, refer to Module 6 Applicant Evaluation, Module 7 String and Application Evaluation and Section 3.3 Fees and Payments.

ACRs from supported applicants will also be considered in relation to the applicant’s eligibility to receive further financial support via the Applicant Support Program. See the Applicant Support Program Terms and Conditions for more information.⁴⁰

3.8.2 Change Request Determination Criteria

When evaluating each ACR, ICANN will consider all available information against seven criteria, which were developed to allow necessary updates to applicant-specific information or applications while ensuring a fair and equitable process for all applicants. The weighting of each criterion may vary based on the specific circumstances of the change request and the application, including the applicant and the strings involved. Approval of changes will be determined by balancing the following factors:

1. Correcting Submission Errors: This criterion applies when the applicant requests a change to correct an error. The applicant must provide adequate information to support the request. Such requests are rare, but when submitted, this criterion carries significant weight.

Is there evidence to support an assertion or claim that the change is requested for the sole purpose of correcting an error?

2. Explanation: This criterion requires that the applicant provide an explanation for the requested changes. If an explanation is not provided, the applicant is given an opportunity to remediate.

Is a reasonable explanation provided?

3. Cause for Change:

Is the change requested in response to third-party input, such as application comments, objections, GAC Consensus Advice, or GAC Member Early Warnings? Is the change requested to reflect an organizational change (for example, a change to the organization name or mailing address)?

4. Precedents: ICANN assesses whether approving the change request would set a new precedent, or align with previously approved similar requests. At this stage of the New gTLD Program, requests that would set a new precedent are unlikely to be approved.

Is the change similar to others that have already been approved? Could the change lead others to request similar changes that could affect third parties or result in undesirable effects on the Program?

5. Impact to third parties, including other applicants: ICANN evaluates whether the change request materially impacts third parties, particularly other applicants. If a change could materially impact another applicant’s status, this criterion is heavily weighted.

What impact, positive or negative, would the change have on third parties, including other applicants? Would it be fair to the general community? Would it create an unfair advantage or disadvantage?

6. Materiality: ICANN assesses how the change request will impact the application’s status and its competing applications, the string, the contention set, and any additional Program processes such as Community Priority Evaluation. A material change will not automatically cause rejection but will influence the weight of other criteria.

Would the change affect evaluation outcomes, string contention, or potentially lead to objections?

7. Timing: This criterion determines whether the timing of the change request impacts criteria 4 - 6 above. If timing is found to impact these criteria, it will be heavily weighted.

Does the timing interfere with the application processing in some way?

Changes that result in material changes to public portions of the application will be subject to a 30-day comment period.⁴¹ Changes that require a 30-day comment period will be posted on the New gTLD Program website where the updated information will be displayed.⁴²

3.8.3 Application Change Request Types and Required Processes

The table below presents a non-exhaustive list of potential ACR types, specifying whether the ACR is allowed, and detailing the necessary processes for each type. The table also differentiates between the two distinct workflows that different ACR types will trigger. More information can be found below in Section 3.8.4 Application Change Request Workflows.

Except what is included in the table, relevant evaluations, such as String and Application Evaluation Procedures (Module 7) and Applicant Evaluation Procedures (Module 6), will be performed again based on the specific areas affected by the ACR; this will be assessed on a case-by-case basis.

The approval of application changes may depend on the specific facts and circumstances surrounding the ACR and the application, including the applicant and the strings involved. If an ACR’s approval necessitates re-evaluation, an additional fee may be charged.

Table 3-3: Application Change Request Types and Required Processes

3.8.4 Application Change Request Workflows

Different types of ACRs trigger different workflows, as described below. Specifically, absent extraordinary circumstances, ACRs will follow one of the two workflows below:

• Application Change Requests: Workflow 1: ACRs relating to all areas except Community Registration Policies and Registry Voluntary Commitments follow Workflow 1. See Section 3.8.4.1.

• Application Change Requests: Workflow 2: ACRs relating to Community Registration Policies and Registry Voluntary Commitments follow Workflow 2.

Each workflow is tailored to address the specific requirements and considerations associated with the respective types of ACRs. See Section 3.8.4.2.

3.8.4.1 Application Change Requests: Workflow 1

All ACRs, except those relating to Community Registration Policies and Registry Voluntary Commitments, will follow the workflow described below:

1. Submission: The applicant submits an ACR.

2. Administrative Review: ICANN determines whether the ACR type is generally allowed, as outlined in the table in Section 3.8.3 Application Change Request Types and Required Processes. If the change is not permitted, ICANN will inform the applicant that the ACR is not approved.

3. ICANN Review: ICANN reviews the change request materials against the seven change request determination criteria above. If additional information is required, ICANN will request it from the applicant.

4. Determination: After completing the review, ICANN will inform the applicant of its decision in the following ways:

   1. If the ACR is not approved, the applicant will be informed.

   2. If the ACR is approved, the proposed changes will be posted to the New gTLD Program website, the application will be updated, and the applicant will be informed. Additionally, the applicant will be informed of one of the following outcomes:

      1. No comment period or re-evaluation is required (process ends here).

      2. A comment period is required (see step 5).

      3. A comment period and re-evaluations are required (see steps 5 and 6).

5. Comment Period: If a comment period is required, the ACR will be posted for a 30-day comment period. This period will allow time for the community to review and submit comments on the changed portion of the application.

6. Re-evaluation: ICANN will issue an invoice for re-evaluation, where applicable. Upon payment, ICANN will perform re-evaluation on the affected evaluation areas concurrently with the Comment Period.

Figure 3-1: Application Change Requests: Workflow 1

3.8.4.2 Application Change Requests: Workflow 2

ACRs relating to Community Registration Policies and Registry Voluntary Commitments (RVCs) will follow the process described below.

1. Submission: The applicant submits an ACR.

2. Administrative Review: ICANN first determines whether the type of ACR is generally allowed, in accordance with the table in Section 3.8.3 Application Change Request Types and Required Processes. If the change is not permitted, ICANN will inform the applicant that the ACR is not approved.

3. ICANN Review: ICANN reviews the change request materials against the seven change request determination criteria above. If additional information is required, ICANN will request it from the applicant.

4. Determination: ICANN determines whether the change is material and takes the following steps:

   1. If not material, the proposed changes are posted to the New gTLD Program website, the application is updated, and the applicant is informed (process ends here).

   2. If material, see step 5.

5. Registry Commitment Evaluation (RCE): Material changes require an RCE.

6. Determination: Upon completing the RCE, ICANN will make a determination regarding the requested change. The determination will result in one of the following outcomes:

   1. If the requested change passes RCE, proceed to step 7.

   2. If the requested change does not pass RCE, the application will not be updated as requested via the ACR and will proceed without the requested change.

   3. If the requested change does not pass RCE, or the change was requested following GAC Consensus Advice or a Panel Determination in the context of an objection, and it was determined that the application cannot proceed without the change, the application cannot proceed. See Section 7.8.3.4 RVC Additions, Changes, and Removals for more information on this type of RVC.

7. Publication: All submitted RVCs or Community Registration Policies will be published alongside their respective ICANN determination following the RCE. If the submitted RVCs or Community Registration Policies undergo any changes as a result of the negotiation between the applicant and ICANN in order to be approved by ICANN, the approved RVCs or Community Registration Policies will be published alongside the original version submitted by the applicant.

8. Comment Period: A 30-day comment period will be launched. ICANN reserves the right to re-initiate negotiations or discuss comments raised during this period with the applicant.

Figure 3-2: Application Change Requests: Workflow 2

3.9 Application Statuses

An application will have one of the following statuses:

• Active: The application is progressing in the New gTLD Program.

• On hold: The application has pending activities that may impact its progress, for example, accountability mechanisms or objections.

• Withdrawn: The application is voluntarily terminated by the applicant. This process is irreversible.

• Pending Termination: Application did not meet the criteria set forth in the Applicant Guidebook and cannot proceed further in the Program. An applicant is expected to withdraw its application within 60 days or ICANN may change its application status to Terminated.

• Terminated: The application will not continue in the Program and the Applicant has exhausted available appeals and challenges.⁴⁸

• Deactivated: This status is assigned to any application that the applicant did not choose to proceed with following the Replacement String period. Such applications are no longer active in the program and will not advance to evaluation or delegation.

• Contracted: The Contracted status is assigned after the Registry Agreement is fully signed. The applicant then becomes a registry operator for the applied-for string or strings.

• Delegated: The TLD has been added to the DNS root zone.