AT-LARGE GATEWAY

At-Large Website

ALAC

RALOs

At-Large Regional Policy Engagement Program (ARPEP)

At-Large Governance

ALAC Liaisons and Representatives 

Policy Comments & Advice

Working Groups

ICANN Meetings

At-Large Summit (ATLAS III)

At-Large Review Implementation Plan Development

ALAC and RALO Elections, Selections, and Appointments

At-Large FY25 Strategic Priority Activities

Module 4
String Contention Procedures
This module describes situations in which contention over applied-for gTLD strings occurs, and the methods available to applicants for resolving such contention cases.
4.1 String Contention
String contention occurs when either:

  1. Two or more applicants for an identical gTLD string successfully complete all previous stages of the evaluation and dispute resolution processes; or
  2. Two or more applicants for similar gTLD strings successfully complete all previous stages of the evaluation and dispute resolution processes, and the similarity of the strings is identified as creating a probability of user confusion if more than one of the strings is delegated.

ICANN will not approve applications for proposed gTLD strings that are identical or that would result in user confusion, called contending strings. If either situation 1 or 2 above occurs, such applications will proceed to contention resolution through either community priority evaluation, in certain cases, or through an auction. Both processes are described in this module. A group of applications for contending strings is referred to as a contention set.
(In this Applicant Guidebook, "similar" means strings so similar that they create a probability of user confusion if more than one of the strings is delegated into the root zone.)
4.1.1Identification of Contention Sets
Contention sets are groups of applications containing identical or similar applied-for gTLD strings. Contention sets are identified during Initial Evaluation following review of all applied-for gTLD strings. ICANN will publish preliminary contention sets once the String Similarity review is completed, and will update the contention sets as necessary during the evaluation and dispute resolution stages.
Applications for identical gTLD strings will be automatically assigned to a contention set. For example, if Applicant A and Applicant B both apply for .TLDSTRING, they will be identified as being in a contention set. Such testing for identical strings also takes into consideration the code point variants listed in any relevant IDN table. That is, two or more applicants whose applied-for strings or designated variants are variant strings according to an IDN table submitted to ICANN would be considered in direct contention with one another. For example, if one applicant applies for string A and another applies for string B, and strings A and B are variant TLD strings as defined in Module 1, then the two applications are in direct contention.
The String Similarity Panel will also review the entire pool of applied-for strings to determine whether the strings proposed in any two or more applications are so similar that they would create a probability of user confusion if allowed to coexist in the DNS. The panel will make such a determination for each pair of applied-for gTLD strings. The outcome of the String Similarity review described in Module 2 is the identification of contention sets among applications that have direct or indirect contention relationships with one another.
Two strings are in direct contention if they are identical or similar to one another. More than two applicants might be represented in a direct contention situation: if four different applicants applied for the same gTLD string, they would all be in direct contention with one another.
Two strings are in indirect contention if they are both in direct contention with a third string, but not with one another. The example that follows explains direct and indirect contention in greater detail.
In Figure 4-1, Strings A and B are an example of direct contention. Strings C and G are an example of indirect contention. C and G both contend with B, but not with one another. The figure as a whole is one contention set. A contention set consists of all applications that are linked by string contention to one another, directly or indirectly.

Figure 4-1 – This diagram represents one contention set, featuring both directly and indirectly contending strings.
While preliminary contention sets are determined during Initial Evaluation, the final configuration of the contention sets can only be established once the evaluation and dispute resolution process stages have concluded. This is because any application excluded through those processes might modify a contention set identified earlier.
A contention set may be augmented, split into two sets, or eliminated altogether as a result of an Extended Evaluation or dispute resolution proceeding. The composition of a contention set may also be modified as some applications may be voluntarily withdrawn throughout the process.
Refer to Figure 4-2: In contention set 1, applications D and G are eliminated. Application A is the only remaining application, so there is no contention left to resolve.
In contention set 2, all applications successfully complete Extended Evaluation and Dispute Resolution, so the original contention set remains to be resolved.
In contention set 3, application F is eliminated. Since application F was in direct contention with E and J, but E and J are not in contention with one other, the original contention set splits into two sets: one containing E and K in direct contention, and one containing I and J.
Figure 4-2 – Resolution of string contention cannot begin until all applicants within a contention set havecompleted all applicable previous stages.
The remaining contention cases must then be resolved through community priority evaluation or by other means, depending on the circumstances. In the string contention resolution stage, ICANN addresses each contention set to achieve an unambiguous resolution.
As described elsewhere in this guidebook, cases of contention might be resolved by community priority evaluation or an agreement among the parties. Absent that, the last-resort contention resolution mechanism will be an auction.
4.1.2 Impact of String Confusion Dispute Resolution Proceedings on Contention Sets
If an applicant files a string confusion objection against another application (refer to Module 3), and the panel finds that user confusion is probable (that is, finds in favor of the objector), the two applications will be placed in direct contention with each other. Thus, the outcome of a dispute resolution proceeding based on a string confusion objection would be a new contention set structure for the relevant applications, augmenting the original contention set.
If an applicant files a string confusion objection against another application, and the panel finds that string confusion does not exist (that is, finds in favor of the responding applicant), the two applications will not be considered in direct contention with one another.
A dispute resolution outcome in the case of a string confusion objection filed by another applicant will not result in removal of an application from a previously established contention set.
4.1.3Self-Resolution of String Contention
Applicants that are identified as being in contention are encouraged to reach a settlement or agreement among themselves that resolves the contention. This may occur at any stage of the process, once ICANN publicly posts the applications received and the preliminary contention sets on its website.
Applicants may resolve string contention in a manner whereby one or more applicants withdraw their applications. An applicant may not resolve string contention by selecting a new string or by replacing itself with a joint venture. It is understood that applicants may seek to establish joint ventures in their efforts to resolve string contention. However, material changes in applications (for example, combinations of applicants to resolve contention) will require re-evaluation. This might require additional fees or evaluation in a subsequent application round. Applicants are encouraged to resolve contention by combining in a way that does not materially affect the remaining application. Accordingly, new joint ventures must take place in a manner that does not materially change the application, to avoid being subject to re-evaluation.
4.1.4 Possible Contention Resolution Outcomes
An application that has successfully completed all previous stages and is no longer part of a contention set due to changes in the composition of the contention set (as described in subsection 4.1.1) or self-resolution by applicants in the contention set (as described in subsection 4.1.3) may proceed to the next stage.
An application that prevails in a contention resolution procedure, either community priority evaluation or auction, may proceed to the next stage.
In some cases, an applicant who is not the outright winner of a string contention resolution process can still proceed. This situation is explained in the following paragraphs.
If the strings within a given contention set are all identical, the applications are in direct contention with each other and there can only be one winner that proceeds to the next step.
However, where there are both direct and indirect contention situations within a set, more than one string may survive the resolution.
For example, consider a case where string A is in contention with B, and B is in contention with C, but C is not in contention with A. If A wins the contention resolution procedure, B is eliminated but C can proceed since C is not in direct contention with the winner and both strings can coexist in the DNS without risk for confusion.
4.2Community Priority Evaluation
Community priority evaluation will only occur if a community-based applicant selects this option. Community priority evaluation can begin once all applications in the contention set have completed all previous stages of the process.
The community priority evaluation is an independent analysis. Scores received in the applicant reviews are not carried forward to the community priority evaluation. Each application participating in the community priority evaluation begins with a score of zero.
4.2.1Eligibility for Community Priority Evaluation
As described in subsection 1.2.3 of Module 1, all applicants are required to identify whether their application type is:

  • Community-based; or
  • Standard.

Applicants designating their applications as community-based are also asked to respond to a set of questions in the application form to provide relevant information if a community priority evaluation occurs.
Only community-based applicants are eligible to participate in a community priority evaluation.
At the start of the contention resolution stage, all community-based applicants within remaining contention sets will be notified of the opportunity to opt for a community priority evaluation via submission of a deposit by a specified date. Only those applications for which a deposit has been received by the deadline will be scored in the community priority evaluation. Following the evaluation, the deposit will be refunded to applicants that score 14 or higher.
Before the community priority evaluation begins, the applicants who have elected to participate may be asked to provide additional information relevant to the community priority evaluation.
4.2.2Community Priority Evaluation Procedure
Community priority evaluations for each eligible contention set will be performed by a community priority panel appointed by ICANN to review these applications. The panel's role is to determine whether any of the community-based applications fulfills the community priority criteria. Standard applicants within the contention set, if any, will not participate in the community priority evaluation.
If a single community-based application is found to meet the community priority criteria (see subsection 4.2.3 below), that applicant will be declared to prevail in the community priority evaluation and may proceed. If more than one community-based application is found to meet the criteria, the remaining contention between them will be resolved as follows:

  • In the case where the applications are in indirect contention with one another (see subsection 4.1.1), they will both be allowed to proceed to the next stage. In this case, applications that are in direct contention with any of these community-based applications will be eliminated.
  • In the case where the applications are in direct contention with one another, these applicants will proceed to an auction. If all parties agree and present a joint request, ICANN may postpone the auction for a three-month period while the parties attempt to reach a settlement before proceeding to auction. This is a one-time option; ICANN will grant no more than one such request for each set of contending applications.

If none of the community-based applications are found to meet the criteria, then all of the parties in the contention set (both standard and community-based applicants) will proceed to an auction.
Results of each community priority evaluation will be posted when completed.
Applicants who are eliminated as a result of a community priority evaluation are eligible for a partial refund of the gTLD evaluation fee (see Module 1).
4.2.3Community Priority Evaluation Criteria
The Community Priority Panel will review and score the one or more community-based applications having elected the community priority evaluation against four criteria as listed below.
The scoring process is conceived to identify qualified community-based applications, while preventing both "false positives" (awarding undue priority to an application that refers to a "community" construed merely to get a sought-after generic word as a gTLD string) and "false negatives" (not awarding priority to a qualified community application). This calls for a holistic approach, taking multiple criteria into account, as reflected in the process. The scoring will be performed by a panel and be based on information provided in the application plus other relevant information available (such as public information regarding the community represented). The panel may also perform independent research, if deemed necessary to reach informed scoring decisions.
It should be noted that a qualified community application eliminates all directly contending standard applications, regardless of how well qualified the latter may be. This is a fundamental reason for very stringent requirements for qualification of a community-based application, as embodied in the criteria below.
The sequence of the criteria reflects the order in which they will be assessed by the panel. The utmost care has been taken to avoid any "double-counting" - any negative aspect found in assessing an application for one criterion should only be counted there and should not affect the assessment for other criteria.
An application must score at least 14 points to prevail in a community priority evaluation. The outcome will be determined according to the procedure described in subsection 4.2.2.
Criterion #1: Community Establishment (0-4 points)
A maximum of 4 points is possible on the Community Establishment criterion:

4

3

2

1

0

Community Establishment

 

 

 

 

High Low
As measured by:

  1. Delineation (2)

    2

    1

    0

    Clearly delineated, organized, and pre-existing community.

    Clearly delineated and pre-existing community, but not fulfilling the requirements for a score of 2.

    Insufficient delineation and pre-existence for a score of 1.

  2. Extension (2)

    2

    1

    0

    Community of considerable size and longevity.

    Community of either considerable size or longevity, but not fulfilling the requirements for a score of 2.

    Community of neither considerable size nor longevity.

    This section relates to the community as explicitly identified and defined according to statements in the application. (The implicit reach of the applied-for string is not considered here, but taken into account when scoring Criterion #2, "Nexus between Proposed String and Community.")
    Criterion 1 Definitions
  • "Community" - Usage of the expression "community" has evolved considerably from its Latin origin – "communitas" meaning "fellowship" – while still implying more of cohesion than a mere commonality of interest. Notably, as "community" is used throughout the application, there should be: (a) an awareness and recognition of a community among its members; (b) some understanding of the community's existence prior to September 2007 (when the new gTLD policy recommendations were completed); and (c) extended tenure or longevity—non-transience—into the future.
  • "Delineation" relates to the membership of a community, where a clear and straight-forward membership definition scores high, while an unclear, dispersed or unbound definition scores low.
  • "Pre-existing" means that a community has been active as such since before the new gTLD policy recommendations were completed in September 2007.
  • "Organized" implies that there is at least one entity mainly dedicated to the community, with documented evidence of community activities.
  • "Extension" relates to the dimensions of the community, regarding its number of members, geographical reach, and foreseeable activity lifetime, as further explained in the following.  
  • "Size" relates both to the number of members and the geographical reach of the community, and will be scored depending on the context rather than on absolute numbers - a geographic location community may count millions of members in a limited location, a language community may have a million members with some spread over the globe, a community of service providers may have "only" some hundred members although well spread over the globe, just to mention some examples - all these can be regarded as of "considerable size."
  • "Longevity" means that the pursuits of a community are of a lasting, non-transient nature.

Criterion 1 Guidelines
With respect to "Delineation" and "Extension," it should be noted that a community can consist of legal entities (for example, an association of suppliers of a particular service), of individuals (for example, a language community) or of a logical alliance of communities (for example, an international federation of national communities of a similar nature). All are viable as such, provided the requisite awareness and recognition of the community is at hand among the members. Otherwise the application would be seen as not relating to a real community and score 0 on both "Delineation" and "Extension."
With respect to "Delineation," if an application satisfactorily demonstrates all three relevant parameters (delineation, pre-existing and organized), then it scores a 2.
With respect to "Extension," if an application satisfactorily demonstrates both community size and longevity, it scores a 2.
Criterion #2: Nexus between Proposed String and Community (0-4 points)
A maximum of 4 points is possible on the Nexus criterion:

4

3

2

1

0

Nexus between String & Community

 

 

 

 

High Low
As measured by:

  1. Nexus (3)

    3

    2

    0

    The string matches the name of the community or is a well known short-form or abbreviation of the community name.

    String identifies the community, but does not qualify for a score of 3.

    String nexus does not fulfill the requirements for a score of 2.

  2. Uniqueness (1)

    1

    0

    String has no other significant meaning beyond identifying the community described in the application.

    String does not fulfill the requirement for a score of 1.

    This section evaluates the relevance of the string to the specific community that it claims to represent.
    Criterion 2 Definitions
  • "Name" of the community means the established name by which the community is commonly known by others. It may be, but does not need to be, the name of an organization dedicated to the community.
  • "Identify" means that the applied for string closely describes the community or the community members, without over-reaching substantially beyond the community.

Criterion 2 Guidelines
With respect to "Nexus," for a score of 3, the essential aspect is that the applied-for string is commonly known by others as the identification / name of the community.
With respect to "Nexus," for a score of 2, the applied-for string should closely describe the community or the community members, without over-reaching substantially beyond the community. As an example, a string could qualify for a score of 2 if it is a noun that the typical community member would naturally be called in the context. If the string appears excessively broad (such as, for example, a globally well-known but local tennis club applying for ".TENNIS") then it would not qualify for a 2.
With respect to "Uniqueness," "significant meaning" relates to the public in general, with consideration of the community language context added.
"Uniqueness" will be scored both with regard to the community context and from a general point of view. For example, a string for a particular geographic location community may seem unique from a general perspective, but would not score a 1 for uniqueness if it carries another significant meaning in the common language used in the relevant community location. The phrasing "...beyond identifying the community" in the score of 1 for "uniqueness" implies a requirement that the string does identify the community, i.e. scores 2 or 3 for "Nexus", in order to be eligible for a score of 1 for "Uniqueness."
It should be noted that "Uniqueness" is only about the meaning of the string - since the evaluation takes place to resolve contention there will obviously be other applications, community-based and/or standard, with identical or confusingly similar strings in the contention set to resolve, so the string will clearly not be "unique" in the sense of "alone."
Criterion #3: Registration Policies (0-4 points)
A maximum of 4 points is possible on the Registration Policies criterion:

4

3

2

1

0

Registration Policies

 

 

 

 

High Low
As measured by:

  1. Eligibility (1)

    1

    0

    Eligibility restricted to community members.

    Largely unrestricted approach to eligibility.

  2. Name selection (1)

    1

    0

    Policies include name selection rules consistent with the articulated community-based purpose of the applied-for gTLD.

    Policies do not fulfill the requirements for a score of 1.

  3. Content and use (1)

    1

    0

    Policies include rules for content and use consistent with the articulated community-based purpose of the applied-for gTLD.

    Policies do not fulfill the requirements for a score of 1.

  4. Enforcement (1)

    1

    0

    Policies include specific enforcement measures (e.g. investigation practices, penalties, takedown procedures) constituting a coherent set with appropriate appeal mechanisms.

    Policies do not fulfill the requirements for a score of 1.

    This section evaluates the applicant's registration policies as indicated in the application. Registration policies are the conditions that the future registry will set for prospective registrants, i.e. those desiring to register second-level domain names under the registry.
    Criterion 3 Definitions
  • "Eligibility" means the qualifications that entities or individuals must have in order to be allowed as registrants by the registry.
  • "Name selection" means the conditions that must be fulfilled for any second-level domain name to be deemed acceptable by the registry.
  • "Content and use" means the restrictions stipulated by the registry as to the content provided in and the use of any second-level domain name in the registry.
  • "Enforcement" means the tools and provisions set out by the registry to prevent and remedy any breaches of the conditions by registrants.

Criterion 3 Guidelines
With respect to "Eligibility," the limitation to community "members" can invoke a formal membership but can also be satisfied in other ways, depending on the structure and orientation of the community at hand. For example, for a geographic location community TLD, a limitation to members of the community can be achieved by requiring that the registrant's physical address is within the boundaries of the location.
With respect to "Name selection," "Content and use," and "Enforcement," scoring of applications against these sub-criteria will be done from a holistic perspective, with due regard for the particularities of the community explicitly addressed. For example, an application proposing a TLD for a language community may feature strict rules imposing this language for name selection as well as for content and use, scoring 1 on both B and C above. It could nevertheless include forbearance in the enforcement measures for tutorial sites assisting those wishing to learn the language and still score 1 on D. More restrictions do not automatically result in a higher score. The restrictions and corresponding enforcement mechanisms proposed by the applicant should show an alignment with the community-based purpose of the TLD and demonstrate continuing accountability to the community named in the application.
Criterion #4: Community Endorsement (0-4 points)

4

3

2

1

0

Community Endorsement

 

 

 

 

High Low
As measured by:

  1. Support (2)

    2

    1

    0

    Applicant is, or has documented support from, the recognized community institution(s)/ member organization(s) or has otherwise documented authority to represent the community.

    Documented support from at least one group with relevance, but insufficient support for a score of 2.

    Insufficient proof of support for a score of 1.


  2. Opposition (2)

    2

    1

    0

    No opposition of relevance.

    Relevant opposition from one group of non-negligible size.

    Relevant opposition from two or more groups of non-negligible size.


    This section evaluates community support and/or opposition to the application. Support and opposition will be scored in relation to the communities explicitly addressed as stated in the application, with due regard for the communities implicitly addressed by the string.
    Criterion 4 Definitions
  • "Recognized" means the institution(s)/organization(s) that, through membership or otherwise, are clearly recognized by the community members as representative of the community.
  • "Relevance" and "relevant" refer to the communities explicitly and implicitly addressed. This means that opposition from communities not identified in the application but with an association to the applied-for string would be considered relevant.

Criterion 4 Guidelines
With respect to "Support," it follows that documented support from, for example, the only national association relevant to a particular community on a national level would score a 2 if the string is clearly oriented to that national level, but only a 1 if the string implicitly addresses similar communities in other nations.
Also with respect to "Support," the plurals in brackets for a score of 2, relate to cases of multiple institutions/organizations. In such cases there must be documented support from institutions/organizations representing a majority of the overall community addressed in order to score 2.
The applicant will score a 1 for "Support" if it does not have support from the majority of the recognized community institutions/member organizations, or does not provide full documentation that it has authority to represent the community with its application. A 0 will be scored on "Support" if the applicant fails to provide documentation showing support from recognized community institutions/community member organizations, or does not provide documentation showing that it has the authority to represent the community. It should be noted, however, that documented support from groups or communities that may be seen as implicitly addressed but have completely different orientations compared to the applicant community will not be required for a score of 2 regarding support.
When scoring "Opposition," previous objections to the application as well as public comments during the same application round will be taken into account and assessed in this context. There will be no presumption that such objections or comments would prevent a score of 2 or lead to any particular score for "Opposition." To be taken into account as relevant opposition, such objections or comments must be of a reasoned nature. Sources of opposition that are clearly spurious, unsubstantiated, or filed for the purpose of obstruction will not be considered relevant.
4.3Auction: Mechanism of Last Resort
It is expected that most cases of contention will be resolved by the community priority evaluation, or through voluntary agreement among the involved applicants. Auction is a tie-breaker method for resolving string contention among the applications within a contention set, if the contention has not been resolved by other means.
An auction will not take place to resolve contention in the case where the contending applications are for geographic names (as defined in Module 2). In this case, the applications will be suspended pending resolution by the applicants.
An auction will take place, where contention has not already been resolved, in the case where an application for a geographic name is in a contention set with applications for similar strings that have not been identified as geographic names.
In practice, ICANN expects that most contention cases will be resolved through other means before reaching the auction stage. There is a possibility that significant funding will accrue to ICANN as a result of one or more auctions. The purpose of an auction is to resolve contention in a clear, objective manner. Proceeds from auctions will be reserved and earmarked until the uses of the proceeds are determined. It is planned that costs of the new gTLD program will offset by fees, so any funds coming from a last resort contention resolution mechanism such as auctions would result (after paying for the auction process) in additional funding. Therefore, consideration of a last resort contention mechanism should include the uses of funds. Funds must be earmarked separately and used in a manner that supports directly ICANN's Mission and Core Values and also maintains its not for profit status.
Possible uses include formation of a foundation with a clear mission and a transparent way to allocate funds to projects that are of interest to the greater Internet community, such as grants to support new gTLD applications or registry operators from communities in subsequent gTLD rounds, the creation of an ICANN-administered/community-based fund for specific projects for the benefit of the Internet community, the creation of a registry continuity fund for the protection of registrants (ensuring that funds would be in place to support the operation of a gTLD registry until a successor could be found), or establishment of a security fund to expand use of secure protocols, conduct research, and support standards development organizations in accordance with ICANN's security and stability mission.
Further detail on the potential uses of funds will be provided with updated Applicant Guidebook materials.
4.3.1 Auction Procedures
An auction of two or more applications within a contention set is conducted as follows. The auctioneer successively increases the prices associated with applications within the contention set, and the respective applicants indicate their willingness to pay these prices. As the prices rise, applicants will successively choose to exit from the auction. When a sufficient number of applications have been eliminated so that no direct contentions remain (i.e., the remaining applications are no longer in contention with one another and all the relevant strings can be delegated as TLDs), the auction will be deemed to conclude. At the auction's conclusion, the applicants with remaining applications will pay the resulting prices and proceed toward delegation. This procedure is referred to as an "ascending-clock auction."
This section provides applicants an informal introduction to the practicalities of participation in an ascending-clock auction. It is intended only as a general introduction and is only preliminary. The detailed set of Auction Rules will be available prior to the commencement of any auction proceedings. If any conflict arises between this module and the auction rules, the auction rules will prevail.
For simplicity, this section will describe the situation where a contention set consists of two or more applications for identical strings.
All auctions will be conducted over the Internet, with participants placing their bids remotely using a web-based software system designed especially for auction. The auction software system will be compatible with current versions of most prevalent browsers, and will not require the local installation of any additional software.
Auction participants ("bidders") will receive instructions for access to the online auction site. Access to the site will be password-protected and bids will be encrypted through SSL. If a bidder temporarily loses connection to the Internet, that bidder may be permitted to submit its bids in a given auction round by fax, according to procedures described in the auction rules. The auctions will generally be conducted to conclude quickly, ideally in a single day.
The auction will be carried out in a series of auction rounds, as illustrated in Figure 4-3. The sequence of events is as follows:
1.For each auction round, the auctioneer will announce in advance: (1) the start-of-round price, (2) the end-of-round price, and (3) the starting and ending times of the auction round. In the first auction round, the start-of-round price for all bidders in the auction will be USD 0. In later auction rounds, the start-of-round price will be its end-of-round price from the previous auction round.
Figure 4-3 – Sequence of events during an ascending-clock auction.
2. During each auction round, bidders will be required to submit a bid or bids representing their willingness to pay within the range of intermediate prices between the start-of-round and end-of-round prices. In this way a bidder indicates its willingness to stay in the auction at all prices through and including the end-of-auction round price, or its wish to exit the auction at a price less than the end-of-auction round price, called the exit bid.

  1. Exit is irrevocable. If a bidder exited the auction in a previous auction round, the bidder is not permitted to re enter in the current auction round.
  2. Bidders may submit their bid or bids at any time during the auction round.
  3. Only bids that comply with all aspects of the auction rules will be considered valid. If more than one valid bid is submitted by a given bidder within the time limit of the auction round, the auctioneer will treat the last valid submitted bid as the actual bid.
  4. At the end of each auction round, bids become the bidders' legally-binding offers to secure the relevant gTLD strings at prices up to the respective bid amounts, subject to closure of the auction in accordance with the auction rules. In later auction rounds, bids may be used to exit from the auction at subsequent higher prices.
  5. After each auction round, the auctioneer will disclose the aggregate number of bidders remaining in the auction at the end-of-round prices for the auction round, and will announce the prices and times for the next auction round.
  • Each bid should consist of a single price associated with the application, and such price must be greater than or equal to the start-of-round price.
  • If the bid amount is strictly less than the end-of-round price, then the bid is treated as an exit bid at the specified amount, and it signifies the bidder's binding commitment to pay up to the bid amount if its application is approved.
  • If the bid amount is greater than or equal to the end-of-round price, then the bid signifies that the bidder wishes to remain in the auction at all prices in the current auction round, and it signifies the bidder's binding commitment to pay up to the end-of-round price if its application is approved. Following such bid, the application cannot be eliminated within the current auction round.
  • To the extent that the bid amount exceeds the end-of-round price, then the bid is also treated as a proxy bid to be carried forward to the next auction round. The bidder will be permitted to change the proxy bid amount in the next auction round, and the amount of the proxy bid will not constrain the bidder's ability to submit any valid bid amount in the next auction round.
  • No bidder is permitted to submit a bid for any application for which an exit bid was received in a prior auction round. That is, once an application has exited the auction, it may not return.
  • If no valid bid is submitted within a given auction round for an application that remains in the auction, then the bid amount is taken to be the amount of the proxy bid, if any, carried forward from the previous auction round or, if none, the bid is taken to be an exit bid at the start-of-round price for the current auction round.
  1. This process continues, with the auctioneer increasing the price range for each given TLD string in each auction round, until there is one remaining bidder at the end-of-round price. After an auction round in which this condition is satisfied, the auction concludes and the auctioneer determines the clearing price. The last remaining application is deemed the successful application, and the associated bidder is obligated to pay the clearing price.

Figure 4-4 illustrates how an auction for five contending applications might progress.

Figure 4-4 – Example of an auction for five mutually-contending applications.

  • Before the first auction round, the auctioneer announces the end-of-round price P1.
  • During Auction round 1, a bid is submitted for each application. In Figure 4-4, all five bidders submit bids of at least P1. Since the aggregate demand exceeds one, the auction proceeds to Auction round 2. The auctioneer discloses that five contending applications remained at P1 and announces the end-of-round price P2.
  • During Auction round 2, a bid is submitted for each application. In Figure 4-4, all five bidders submit bids of at least P2. The auctioneer discloses that five contending applications remained at P2 and announces the end-of-round price P3.
  • During Auction round 3, one of the bidders submits an exit bid at slightly below P3, while the other four bidders submit bids of at least P3. The auctioneer discloses that four contending applications remained at P3 and announces the end-of-round price P4.
  • During Auction round 4, one of the bidders submits an exit bid midway between P3 and P4, while the other three remaining bidders submit bids of at least P4. The auctioneer discloses that three contending applications remained at P4 and announces the end-of-auction round price P5.
  • During Auction round 5, one of the bidders submits an exit bid at slightly above P4, and one of the bidders submits an exit bid at Pc midway between P4 and P5. The final bidder submits a bid greater than Pc. Since the aggregate demand at P5 does not exceed one, the auction concludes in Auction round 5. The application associated with the highest bid in Auction round 5 is deemed the successful application. The clearing price is Pc, as this is the lowest price at which aggregate demand can be met.

To the extent possible, auctions to resolve multiple string contention situations will be conducted simultaneously.
4.3.1.1Currency
For bids to be comparable, all bids in the auction will be submitted in any integer (whole) number of US dollars.
4.3.1.2Fees
A bidding deposit will be required of applicants participating in the auction, in an amount to be determined. The bidding deposit must be transmitted by wire transfer to a specified bank account specified by ICANN or its auction provider at a major international bank, to be received in advance of the auction date. The amount of the deposit will determine a bidding limit for each bidder: the bidding deposit will equal 10% of the bidding limit; and the bidder will not be permitted to submit any bid in excess of its bidding limit.
In order to avoid the need for bidders to pre-commit to a particular bidding limit, bidders may be given the option of making a specified deposit that will provide them with unlimited bidding authority for a given application. The amount of the deposit required for unlimited bidding authority will depend on the particular contention set and will be based on an assessment of the possible final prices within the auction.
All deposits from nondefaulting losing bidders will be returned following the close of the auction.
4.3.2Winning Bid Payments
Any applicant that participates in an auction will be required to sign a bidder agreement that acknowledges its rights and responsibilities in the auction, including that its bids are legally binding commitments to pay the amount bid if it wins (i.e., if its application is approved), and to enter into the prescribed registry agreement with ICANN—together with a specified penalty for defaulting on payment of its winning bid or failing to enter into the required registry agreement.
The winning bidder in any auction will be required to pay the full amount of the final price within 20 business days of the end of the auction. Payment is to be made by wire transfer to the same international bank account as the bidding deposit, and the applicant's bidding deposit will be credited toward the final price.
In the event that a bidder anticipates that it would require a longer payment period than 20 business days due to verifiable government-imposed currency restrictions, the bidder may advise ICANN well in advance of the auction and ICANN will consider applying a longer payment period to all bidders within the same contention set.
Any winning bidder for whom the full amount of the final price is not received within 20 business days of the end of an auction is subject to being declared in default. At their sole discretion, ICANN and its auction provider may delay the declaration of default for a brief period, but only if they are convinced that receipt of full payment is imminent.
Any winning bidder for whom the full amount of the final price is received within 20 business days of the end of an auction retains the obligation to execute the required registry agreement within 90 days of the end of auction. Such winning bidder who does not execute the agreement within 90 days of the end of the auction is subject to being declared in default. At their sole discretion, ICANN and its auction provider may delay the declaration of default for a brief period, but only if they are convinced that execution of the registry agreement is imminent.
4.3.3Post-Default Procedures
Once declared in default, any winning bidder is subject to immediate forfeiture of its position in the auction and assessment of default penalties. After a winning bidder is declared in default, the remaining bidders will receive an offer to have their applications accepted, one at a time, in descending order of their exit bids. In this way, the next bidder would be declared the winner subject to payment of its last bid price. The same default procedures and penalties are in place for any runner-up bidder receiving such an offer.
Each bidder that is offered the relevant gTLD will be given a specified period—typically, four business days—to respond as to whether it wants the gTLD. A bidder who responds in the affirmative will have 20 business days to submit its full payment. A bidder who declines such an offer cannot revert on that statement, has no further obligations in this context and will not be considered in default.
The penalty for defaulting on a winning bid will equal 10% of the defaulting bid. If bidders were given the option of making a specified deposit that provided them with unlimited bidding authority for a given application and if the winning bidder utilized this option, then the penalty for defaulting on a winning bid will be the lesser of the following: (1) 10% of the defaulting bid, or (2) the specified deposit amount that provided the bidder with unlimited bidding authority.
Default penalties will be charged against any defaulting applicant's bidding deposit before the associated bidding deposit is returned.
4.4 Contention Resolution and Contract Execution
An applicant that has been declared the winner of a contention resolution process will proceed by entering into the contract execution step. (Refer to section 5.1 of Module 5.)
If a winner of the contention resolution procedure has not executed a contract within 90 days of the decision, ICANN has the right to deny that application and extend an offer to the runner-up applicant, if any, to proceed with its application. For example, in an auction, another applicant who would be considered the runner-up applicant might proceed toward delegation. This offer is at ICANN's option only. The runner-up applicant in a contention resolution process has no automatic right to an applied-for gTLD string if the first place winner does not execute a contract within a specified time.

  • No labels