Appendix 1 Application Questions

Instructions:

Provide the full legal name of the applying entity as it appears on the official registration documents. Do not use abbreviations.

Instructions:

Provide the name under which the applying entity is doing business, if different from the full legal name answered in Question 1. Such a name must be registered with appropriate local jurisdiction or public authority.

Instructions:

Provide the long form (no acronyms) of the legal entity form/business structure of the applying entity as it appears on the official registration documents. If the original script of the legal entity form/business structure is not English, ONLY provide its official English translation. No additional information should be provided as this will be used for the automatic population of the Registry Agreement.

Notes:

1. Legal entity form/business structure refers to the type of business the entity is registered as.

2. Examples of legal forms/business structures may include "Corporation", "Limited Liability Company", "Public/Private Limited Company (Ltd.)", “Nonprofit”, “Government Entity”, “Intergovernmental Organization”, etc.

3. Natural persons and sole proprietorships do not qualify.

4. This is not the same as the full legal name of the entity.

Instructions:

The jurisdiction indicates the location in which the business of the applying entity is registered for legal and financial purposes. This is either 1) a country name, or a 2) state/territory name, depending on where the applying entity is registered. No additional information should be provided as this will be used for the automatic population of the Base Registry Agreement. Examples include "Delaware", "Germany", etc.

Instructions:

Enter the number issued such as a Tax ID, Business ID, VAT Registration Number, or equivalent issued by the local jurisdiction.

Instructions:

Enter the name of the authority that issued the Tax ID, Business ID, VAT Registration Number, or equivalent as per answer to question 5.

Instructions:

Enter the Legal Entity Identifier (LEI), a 20-character, alpha-numeric code that uniquely identifies legal entities participating in financial transactions, for the applying entity, if available.

Instructions:

1. Provide articles of incorporation/association/organization or other equivalent documents filed with the issuing authority (statutes, membership agreement, etc.) of the entity.

2. If the applying entity is a government body/organization or an intergovernmental organization, provide a certified copy of the relevant statute or governmental decision under which it has been established.

Instructions:

1. Provide a good standing certificate (or equivalent) that states that the applying entity is, among other things, compliant with annual filing requirements, active, not subject to any administrative orders or action against it, not in liquidation, is current on any required fees and dues, etc.

2. Where the authority that issues business registration documents in the applying entity's jurisdiction does not maintain documentation of good standing (or equivalent), such that the applying entity cannot provide this documentation, the applying entity must submit an affidavit drafted and signed by a notary public or a legal practitioner duly qualified in the courts of the applying entity’s jurisdiction, declaring that the organization is established and in good standing.

CR-1. Upload the appropriate documentation.

CR-2. Good standing certificate must be no more than six months old at the time of application submission.

Instructions:

Provide the website URL of the applying entity, if available.

Notes:

A valid URL must start with 'http://' or 'https://' followed by the domain name (for example, “https://www.example.com”).

1. 255 character limit

2. Entered text must be valid URL

Instructions:

1. Choose Yes or No.

2. Use the definition of Affiliate from the Base Registry Agreement (see Base Registry Agreement: https://www.icann.org/en/registry-agreements/base-agreement).

Instructions:

1. Specify if the applying entity is an existing registry operator, ICANN accredited registrar, and/or an Affiliate of a registry operator and/or registrar.

2. If the applying entity is an Affiliate, provide the details of such Affiliate relationship, including the name of the affiliated registry operator and/or registrar.

3. If the applying entity is an ICANN accredited registrar, specify the registrar ID number.

Instructions:

1. Choose Yes or No.

Instructions:

1. Use the definition of Affiliate from the Base Registry Agreement (see Base Registry Agreement: https://www.icann.org/en/registry-agreements/base-agreement).

2. Provide the type of the provider and the name of the applicable entity of which the applying entity is an Affiliate.

Instructions:

1. If the applying entity is publicly traded, provide its stock symbol.

2. If the applying entity is traded under multiple symbols/tickers, provide the symbol of the entity's primary equity listing that has the most units outstanding.

Instructions:

1. If the applying entity is publicly traded, select the Stock Exchange with which the applying entity is listed.

2. If the applying entity is traded on multiple exchanges, provide the exchange of the entity's primary equity listing.

Instructions:

Provide the primary business phone number without including the country code.

Instructions:

Provide the primary business email address of the applying entity.

1. 255 character limit

2. Entered text must be valid email address.

Instructions:

Enter the street address (no PO Box).

1. 255 character limit

2. Must be a physical address, no PO Box.

Instructions:

Enter the city, village, municipality, etc.

Instructions:

Enter the state, province, department, territory, prefecture, oblast, etc., if applicable.

Instructions:

1. Enter the postal code, if applicable.

2. If a postal code does not exist, type “Not Applicable”.

Instructions:

If applicable, provide the full legal name as it appears on the official registration documents of the Direct Parent Company of the applying entity. Do not use abbreviations.

Notes:

“Direct Parent Company” means, with respect to an Applicant, the entity that directly possesses the power to direct the management and policies of such Applicant through the ownership of voting securities, as a general partner, as a managing member, by contract, or otherwise.

CR-1. Enter appropriate information in text field.Notes:

CR-2. If this field is populated, all following questions in this subsection Questions 27-35) are required.

Instructions:

Provide the name under which the Direct Parent Company is doing business, if different from the full legal name answered in Question 26. Such a name must be registered with appropriate local jurisdiction or public authority.

Instructions:

Provide the long form (no acronyms) of the legal entity form/business structure of the Direct Parent Company as it appears on the official registration documents. If the original script of the legal entity form/business structure is not English, ONLY provide its official English translation.

Notes:

1. Legal entity form/business structure refers to the type of business the entity is registered as.

2. Examples of legal forms may include "Corporation", "Limited Liability Company", "Public/Private Limited Company (Ltd.)", “Nonprofit”, “Government Entity”, “Intergovernmental Organization”, etc.

3. Natural persons and sole proprietorships do not qualify.

4. This is not the same as the full legal name of the entity.

Instructions:

The jurisdiction indicates the location in which the business of the Direct Parent Company is registered for legal and financial purposes. This is either 1) a country name, or a 2) state/territory name, depending on where the Direct Parent Company is registered. Examples include "Delaware", "Germany", etc.

Instructions:

Enter the street address (no PO Box).

1. 255 character limit

2. Must be a physical address, no PO Box.

Instructions:

Enter the city, village, municipality, etc.

Instructions:

Enter the state, province, department, territory, prefecture, oblast, etc., if applicable.

Instructions:

1. Enter the postal code, if applicable.

2. If a postal code does not exist, type “Not Applicable”.

Instructions:

If applicable, provide the full legal name as it appears on the official registration documents of the Ultimate Parent Company of the applying entity. Do not use abbreviations.

Notes:

“Ultimate Parent Company” means, with respect to an Applicant (and, if applicable, a Direct Parent Company), the top-level entity that directly or indirectly possesses the power to direct the management and policies of such Applicant (and, if applicable, a Direct Parent Company) through the ownership of voting securities, as a general partner, as a managing member, by contract, or otherwise. An Ultimate Parent Company is not controlled by any other entity. If there are no intermediary entities between the Applicant and the Ultimate Parent Company, the Ultimate Parent Company would be the same entity as the Direct Parent Company.

CR-1. Enter appropriate information in text field.

CR-2. If this field is populated, all following questions in this subsection (Questions 37-48) are required.

Instructions:

Provide the name under which the Ultimate Parent Company is doing business, if different from the full legal name answered in Question 36. Such a name must be registered with appropriate local jurisdiction or public authority.

Instructions:

Provide the long form (no acronyms) of the legal entity form/business structure of the Ultimate Parent Company as it appears on the official registration documents. If the original script of the legal entity form/business structure is not English, ONLY provide its official English translation.

Notes:

1. Legal entity form/business structure refers to the type of business the entity is registered as.

2. Examples of legal forms may include "Corporation", "Limited Liability Company", "Public/Private Limited Company (Ltd.)", “Nonprofit”, “Government Entity”, “Intergovernmental Organization”, etc.

3. Natural persons and sole proprietorships do not qualify.

4. This is not the same as the full legal name of the entity.

Instructions:

The jurisdiction indicates the location in which the business of the Ultimate Parent Company is registered for legal and financial purposes. This is either 1) a country name, or a 2) state/territory name, depending on where the Direct Parent Company is registered. Examples include "Delaware", "Germany", etc.

Instructions:

Enter the street address (no PO Box)

1. 255 character limit

2. Must be a physical address, no PO Box.

Instructions:

Enter the city, village, municipality, etc.

Instructions:

Enter the state, province, department, territory, prefecture, oblast, etc., if applicable.

Instructions:

1. Enter the postal code, if applicable.

2. If a postal code does not exist, type “Not Applicable”.

Instructions:

Provide a graphical representation of ownership (for example, an organizational chart), which includes percentages of the associated entities or persons from the applying entity to the Ultimate Parent Company.

Instructions:

Choose Yes or No.

Instructions:

Provide an explanation.

CR-1. Enter appropriate information in text field.

CR-2. Text allowed is 4,000 characters or less.

Instructions:

Enter the full legal name of the Primary User as it appears on their passport or government-issued ID. Enter the full legal name in the local script or language and provide the name of the script or language in English, if applicable.

Notes:

1. Primary User is defined as the individual designated by the applying entity with the primary responsibility for management of the application, including responding to tasks in the TLD Application Management System (TAMS) during the various application phases. The Primary User listed should also be prepared to receive inquiries from ICANN and the public.

2. Information for two (2) Primary Users must be provided.

3. Information for up to five (5) Additional Users may be provided, if desired. Additional Users may access TAMS at a limited capacity to assist the Primary Users with respect to the application.

Instructions:

Enter the mailing address of the Primary User.

Instructions:

Enter the city, village, municipality, etc.

Instructions:

Enter the state, province, department, territory, prefecture, oblast, etc., if applicable.

Instructions:

1. Enter the postal code, if applicable.

2. If a postal code does not exist, type “Not Applicable”.

Instructions:

Provide the business phone number of the user without including the country code.

Instructions:

A distinct email address for each user is required in order to protect the access to the system of the applying entity, should one of the users lose its credentials.

1. 255 character limit

2. Entered text must be valid email address.

Instructions:

Provide the percentage of shares of the applying entity owned by this user, in the numerical value form (for example, 15%, etc.).

Instructions:

Provide the title of this user with respect to the organization of the applying entity (for example, CEO, CFO, Director, etc.). If the user is not employed by the applying entity, indicate "contractor," "consultant," or equivalent.

Instructions:

1. If the user holds a position of significant influence, please list the title in the space provided.

2. If not, type "Not Applicable"

Notes:

A signatory officer is an individual authorized to sign legally binding documents on behalf of the applying entity.

Instructions:

1. Provide information on who will be making payments with respect to the application on behalf of the applying entity.

2. If the payor is a business, provide the full legal name as it appears on the official registration documents of the payor. Do not use abbreviations.

3. If the payor is an individual, provide the full legal name of the payor as it appears on their passport or government-issued ID. Enter the full legal name in the local script or language and provide the name of the script or language in English, if applicable.

4. If the payor is an individual, TAMS will also request the following information: country code of residence, title of the individual, and year of birth.

Instructions:

If the payor is a business, provide the name under which the payor is doing business, if different from the full legal name answered in Question 65. Such a name must be registered with appropriate local jurisdiction or public authority.

CR-1. Enter appropriate information in text field.

CR-2. This field is only required if the payor is a business entity.

Instructions:

If the payor is a business, provide the long form (no acronyms) of the legal entity form/business structure of the payor as it appears on the official registration documents. If the original script of the legal entity form/business structure is not English, ONLY provide its official English translation.

Notes:

1. Legal entity form/business structure refers to the type of business the entity is registered as.

2. Examples of legal forms may include "Corporation", "Limited Liability Company", "Public/Private Limited Company (Ltd.)", “Nonprofit”, “Government Entity”, “Intergovernmental Organization”, etc.

3. Natural persons and sole proprietorships do not qualify.

4. This is not the same as the full legal name of the entity.

CR-1. Enter appropriate information in text field.

CR-2. This field is only required if the payor is a business entity.

Instructions:

Answer this question if the payor is a business. The jurisdiction indicates the location in which the business of the payor is registered for legal and financial purposes. This is either 1) a country name, or a 2) state/territory name, depending on where the payor is registered. Examples include "Delaware", "Germany", etc.

CR-1. Enter appropriate information in text field.

CR-2. This field is only required if the payor is a business entity.

Instructions:

Enter the street address (No PO Box) of the primary business address of the payor.

1. 255 character limit

2. Must be a physical address, no PO Box.

Instructions:

Enter the city, village, municipality, etc.

Instructions:

Enter the state, province, department, territory, prefecture, oblast, etc., if applicable.

Instructions:

1. Enter the postal code, if applicable.

2. If a postal code does not exist, type “Not Applicable”.

Instructions:

Provide the name of the financial institution (for example, the name of a bank, credit union, investment firm, etc.).

Instructions:

Provide the beneficiary name as it appears on the account in the financial institution listed in the answer to Question 75 bank account. A beneficiary is defined as the registered owner of the account being used for payment with respect to the application.

Instructions:

Provide the mailing address of the bank branch that is associated with the account information provided in the answers to Questions 85-90.

Instructions:

Enter the city, village, municipality, etc. of the bank branch that is associated with the account information provided in answers to Questions 85-90.

Instructions:

Enter the state, province, department, territory, prefecture, oblast, etc. (if applicable) of the bank branch which the applying entity will use to wire fees to ICANN and is associated with the account information provided in answers to Questions 85-90.

Instructions:

1. Enter the postal code of the bank branch that is associated with the account information provided in answers to Questions 85-90, if applicable.

2. If a postal code does not exist, type “Not Applicable”.

Instructions:

Choose the Country Code of the bank branch that is associated with the account information provided in answers to Questions 85-90.

Instructions:

Provide the long form (no acronyms) of the legal entity form/business structure of the financial institution as it appears on the official registration documents. If the original script of the legal entity form/business structure is not English, ONLY provide its official English translation.

Notes:

1. Legal entity form/business structure refers to the type of business the entity is registered as.

2. Examples of legal forms may include "Corporation", "Limited Liability Company", "Public/Private Limited Company (Ltd.)", “Nonprofit”, “Government Entity”, “Intergovernmental Organization”, etc.

3. Natural persons and sole proprietorships do not qualify.

4. This is not the same as the full legal name of the entity.

Instructions:

The jurisdiction indicates the location in which the business of the financial institution is registered for legal and financial purposes. This is either 1) a country name, or a 2) state/territory name, depending on where the financial institution is registered. Examples include "Delaware", "Germany", etc.

Instructions:

Provide the Transit/Domestic Routing Number of the payor.

Instructions:

Provide the International Bank Account Number (IBAN) of the payor, if applicable.

Notes:

IBAN consists of up to 34 alphanumeric characters, beginning with a two-letter country code, followed by two check digits used for security purposes. What comes next is a string of domestic banking details, referred to as Basic Bank Account Numbers (BBAN): the bank identifier code, Branch code (also known as Sort Code in UK), and the bank account number.

Instructions:

Provide the SWIFT Code of the payor. The SWIFT Code is also known as Bank Identifier Code (BIC code). The code must be 8 or 11 alphanumeric [0-9,a-z] characters.

Instructions:

Provide the account number of the payor.

Instructions:

Select an account type of the payor.

Instructions:

Select the account category of the payor.

CR-1. Select from a Dropdown Menu.

CR-2. Options are: Non-US, US Business, US Corporate, or US Personal.

Instructions:

Enter the full legal name of the individual serving as a Billing Point of Contact as it appears on their passport or government-issued ID. Enter the full legal name in the local script or language and provide the name of the script or language in English, if applicable.

Notes:

1. The Billing Point of Contact is the individual designated with the billing related responsibility, such as making payments and handling refund related matters.

2. If the Billing Point of Contact is the same as one of the users as provided under Question Set 2,

please re-enter the information of the user.

Instructions:

Enter the mailing address of the Billing Point of Contact.

Instructions:

Enter the city, village, municipality, etc.

Instructions:

Enter the state, province, department, territory, prefecture, oblast, etc., if applicable.

Instructions:

1. Enter the postal code, if applicable.

2. If a postal code does not exist, type “Not Applicable”.

Instructions:

Provide the business phone number of the Billing Point of Contact without including the country code.

1. 255 character limit

2. Entered text must be valid email address.

Instructions:

Provide the title of this Billing Point of Contact with respect to the organization of the applying entity (for example, CEO, CFO, Director, etc.). If the contact is not employed by the applying entity, indicate "contractor," "consultant," or regional equivalent.

Instructions:

Enter the full legal name, year of birth, country code of business, country code of residence, address, locality (for example, city, village, or municipality), and title of all directors (that is, members of the applying entity’s Board of Directors, if applicable). Enter the full legal name in the local script or language and provide the name of the script or language in English, if applicable.

Notes:

The applying entity should be aware that the names of the individuals listed in response to this question will be published as part of the application. The contact information listed for individuals is for identification purposes only and will not be published as part of the application.

Background checks may be conducted on individuals named in the applying entity’s response to this question. Any material misstatement or misrepresentation (or omission of material information) may cause the application to be rejected.

The applying entity certifies that it has obtained permission for the posting of the names and positions of individuals included in this application.

Officers/

Partners

Instructions:

Enter the full legal name, year of birth, address, locality (for example, city, village, or municipality), country code of residence, and title of all officers and partners. Enter the full legal name in the local script or language and provide the name of the script or language in English, if applicable.

Notes:

1. Officers are high-level management officials of a corporation or business, for example, a CEO, vice president, secretary, chief financial officer. Partners would be listed in the context of a partnership or other such form of legal entity.

2. The applying entity should be aware that the names of the individuals listed in response to this question will be published as part of the application. The contact information listed for individuals is for identification purposes only and will not be published as part of the application.

Background checks may be conducted on individuals named in the applying entity’s response to this question. Any material misstatement or misrepresentation (or omission of material information) may cause the application to be rejected.

The applying entity certifies that it has obtained permission for the posting of the names and positions of individuals included in this application.

Instructions:

Enter the full legal name and contact information of all shareholders (individuals and entities) holding at least 15% of outstanding shares (or other form of equity), and percentage held by each.

Notes:

1. For a shareholder entity, enter full legal name, the address, locality (for example, city, village, or municipality), country code of business, jurisdiction, and legal form. Enter the full legal name in the local script or language and provide the name of the script or language in English, if applicable.

2. For a shareholder individual, enter the full legal name, the year of birth, address, locality (for example, city, village, or municipality), country code of residence, and title of all individuals. Enter the full legal name in the local script or language and provide the name of the script or language in English, if applicable.

Instructions:

For an applying entity that does not have directors, officers, partners, or shareholders, enter the full legal name, year of birth, address, locality (for example, city, village, or municipality), country code of residence, and title of all individuals having overall legal or executive responsibility for the applying entity. Enter the full legal name in the local script or language and provide the name of the script or language in English, if applicable.

Instructions:

Disclose any entities or persons, including any entities or persons providing Financing (if any), that exercise or have the ability to exercise (or will exercise or will have the ability to exercise) direct or indirect decision-making or management over the operations or policies (i) concerning the Application, or (ii) of the applying entity or any of its affiliates relating to this Application, whether by ownership interest, contractual rights or otherwise.

For persons, enter the full legal name, year of birth, address, locality (for example, city, village, or municipality), country code of residence, and title of all individuals. Enter the full legal name in the local script or language and provide the name of the script or language in English, if applicable.

For entities, enter the full legal name, address, locality (for example, city, village, or municipality), country code of business, jurisdiction, and legal form. Enter the full legal name in the local script or language and provide the name of the script or language in English, if applicable.

Instructions:

Confirm the statement using the checkbox.

Instructions:

Select Yes or No.

Instructions:

If unable to confirm, please provide an

explanation.

Instructions:

Select Yes or No.

Instructions:

If unable to confirm, please provide an

explanation.

​​Confirm that the applying entity and individuals or entities named within the

Organizational Account, either in their current capacity or as part of a

previous entity over which they had ownership or control, have not

been subject to a final determination related to the Uniform Rapid

Suspension System (URS) Policy or Post-Delegation Dispute Resolution

Procedures (PDDRP).

Instructions:

Select Yes or No.

Instructions:

If unable to confirm, please provide an

explanation.

Instructions:

1. Enter ONLY the text of the applied-for string and no additional characters such as quotation marks, dots, or other punctuation.

2. If applying for an IDN, provide the A-label beginning with “xn--“.

Instructions:

If applying for an IDN, enter the U-label and the list of code points.

Notes:

Code points must be in the form of "U+0000" separated by space.

CR-1. Required if IDN

CR-2. Enter a valid U-label and code points in the text field.

CR-3. Text (NOTE UTF-8)

Instructions:

Provide the meaning, or restatement of the string in English, that is, a description of the literal meaning of the string in the opinion of the applying entity. If there is no literal meaning in English (for example, a brand name or a proper noun without a translation) simply state "No English Translation".

Notes:

String meaning/definition is not evaluated, but is purely for informational purposes. Such information may prove to be useful during the comment submission phase of the Program.

Instructions:

If an IDN, provide the script of the string (both in English and as referenced by the RZ-LGR/ISO 15924)

CR-1. Required if IDN

CR-2. Choose from ISO 15924 Dropdown.

Instructions:

Provide a representation of the string according to the International Phonetic Alphabet (IPA). See IPA: https://www.internationalphoneticassociation.org/IPAcharts/IPA_chart_orig/pdfs/IPA_Kiel_2020_full.pdf

Instructions:

Confirm the statement using the checkbox

Instructions:

1. Enter ONLY the applied-for variant string and no additional characters such as quotation marks, dots, or other punctuation.

2. If applying for an IDN, provide the A-label beginning with “xn--“.

Note:

1. Variant strings are calculated using the applicable version of the Root Zone Label Generation Rules. See Applicable RZ-LGR Version and Scripts and Languages Supported for Guidebook details.

2. An applying entity seeking one or more allocatable variant strings of an applied-for primary IDN string or existing gTLD must provide justification for the necessity of each variant string. See also Section 7.6 Variant String Evaluation.

Instructions:

If applying for an IDN, enter the U-label and the list of code points.

Notes:

Code points must be in the form of "U+0000" separated by space.

CR-1. Required if IDN

CR-2. Enter a valid U-label and code points in the text field.

CR-3. Text (NOTE UTF-8)

Instructions:

Provide the script of the variant string (both in English and as referenced by the RZ-LGR/ISO 15924).

CR-1. Required if IDN

CR-2. Choose from ISO 15924 Dropdown

Instructions:

Select an option.

Instructions:

Provide the meaning or intended meaning (for non-dictionary words) of each of the applied-for variant string(s), including sources. If there is no literal meaning in English (for example, a brand name or a proper noun without a translation) simply state "no English Translation/Meaning.”

Notes:

1. String meaning/definition of variant strings are evaluated.

2. Applying entities can use multiple dictionaries in different languages to make their case.

Instructions:

Provide at least three bona-fide examples to support the explanation (for example, evidence of trademark use by showing real world use cases).

CR-1. Enter appropriate information in text field or optional document upload.

See also Section 7.6 Variant String Evaluation.

Instructions:

1. Applying entities shall explain why one string is insufficient and two or more strings are necessary to satisfy regional, linguistic, or cultural drivers.

2. Identify the user communities served by primary and for each of the variant TLDs.

3. How are these user community needs reflected by differences or similarities in the design of the IDN tables offered for the primary and the each variant TLD?

Instructions:

Provide steps and descriptions that adequately demonstrate all defined criteria are met. See Section 7.6 Variant String Evaluation and Section 3.1.9.2.1 Application Submission of New Primary IDN and its Variant Strings.

Notes:

Commitments made by an applicant to minimize the noted operational and management complexities will form the basis of contractual requirements to be included in the applicable Registry Agreement.

Instructions:

Confirm the statement using the checkbox.

Instructions:

Select Yes or No.

Instructions:

1. Provide the name of the community that the applying entity is committing to serve.

2. Describe the distinct aspects of the community.

Instructions:

1. Describe the mission and purpose of the applied-for gTLD, including the intended registrants and users, and the related activities that have been or will be carried out to achieve this purpose.

2. Explain how this purpose is sustainable over time.

Instructions:

Enter a category that best describes your community. Some examples of community categories could include, but are not limited to: activity-based and volunteer groups, online or social media groups, religious or political groups, diasporic communities, linguistic communities, celebrity or sports team supporters.

Instructions:

Describe and provide evidence of the relationship between the applying entity and the identified community.

Instructions:

Describe and provide evidence related to the community organization, any relevant organizing bodies, and any relevant leaders within the community.

Instructions:

1. Describe any formal membership process, if there is one.

2. If there is no formal membership process, provide evidence related to how an individual can join the identified community (that is, “self-identify” as a community member).

Instructions:

Provide the primary location of the community.

Instructions:

1. Provide the estimated size of the community. The size should be in number format (for example, “1,000,000 members”).

2. If the community is divided by group, region, sector, etc., this should include estimated size for each group.

Instructions:

Provide the estimated size of the community that is administered or represented by each relevant organizing body in the identified community.

Instructions:

1. Provide evidence of any documented practices of community efforts to date.

2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission:

a) Offering support;

b) Sharing information;

c) Responding to specific community needs;

d) Fostering and strengthening relationships within the community.

Instructions:

1. Describe whether the applying entity has a role in any of the activities listed in Question 141.

2. If the applying entity does play a role, provide evidence of the applying entity’s role. If the applying entity does not play a role, describe why this is the case.

Instructions:

1. Provide evidence that demonstrates that community members are aware of the identified community and the different member groups or segments within the identified community.

2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission:

a) Surveys conducted;

b) Records of activities involving a diversity of community groups, segments, or members.

Instructions:

1. Provide evidence of community members’ awareness of the applying entity and its intent to apply for a Community gTLD.

2. If there is no such evidence, explain why not.

Instructions:

Provide evidence of the established presence of the community prior to the opening of the application submission period.

Instructions:

1. Provide evidence that demonstrates that individuals and groups outside of the community show an awareness of the identified community.

2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission:

a) Media or other public information regarding the community and its activities or members;

b) Discussion of the community in various fora, whether online or in person;

c) Evidence of partnerships or collaborations with groups outside of the identified community;

d) Evidence of the chartering or organization of the community prior to the opening of the application submission window;

e) Evidence of contributions (for example, cultural or scientific) to a larger society or population.

Instructions:

1. Provide evidence of the longevity of the community.

2. The applying entity should provide documentation of the following practices which should have occurred within the two years leading up to application submission:

a) Evidence of recurring or scheduled activities that demonstrate continuity over time;

b) Documented records of past activities that demonstrate a long-standing tradition or practice;

c) Records of discussions emphasizing the community’s enduring presence or its cultural significance.

Instructions:

Explain how the applied-for string matches the name of the community or is a well-known alternative name (whether long or short form) of the community.

Instructions:

1. Explain how the applied-for string clearly relates to or represents the community.

2. Explain whether the applied-for string has any other significant meaning beyond identifying the community or community members described in the application. The applying entity may wish to provide pertinent information regarding any particular geography, region, or themes that may be alluded to by the string, of which the community may or may not be a part.

Instructions:

Select from Radio Buttons - Yes/No

Notes:

1. Community Registration Policies are conditions that Community gTLD registry operators impose upon registrants within their gTLDs.

2. If you select “Yes” to this question, the applying entity is required to pay the conditional Registry Commitments Evaluation fee, and Community Registration Policies that are approved by ICANN will be scored in the CPE (if the applying entity elects to participate) and included in Specification 12 of the applicable Base RA.

3. If you select “No,” then the application cannot proceed as a Community Application.

CR-1. Community applicants must propose, and obtain ICANN’s approval of, at a minimum, Community Registration Policies concerning registrant eligibility and naming selection for inclusion in the Specification 12 of the applicable Base RAs.

CR-2. Such policies serve as a prerequisite to a Community Applicant’s participation in the Community Priority Evaluation (CPE). See Section 7.8.3 Registry Voluntary Commitments (RVCs) and Section 5.4 Community Priority Evaluation.

1. An option must be selected.

2. If “Yes,” proceed to Question 151 (the next question) in this section.

3. If “No,” a system warning will display "Without proposing a Community Registration Policy, your Community gTLD application cannot proceed and cannot participate in the Community Priority Evaluation (CPE)."

Instructions:

1. Draft the Community Registration Policy as proposed contract language. Policies that are approved by ICANN will be included in Specification 12 of the applicable Registry Agreement and will be subject to enforcement by ICANN Contractual Compliance. See Appendix 4 Base Registry Agreement, Specification 12 for drafting approach. Consider the usage of defined terms and the definitions of such terms in the 2026 Round Base RA.

2. Enter a single proposed Community Registration Policy with respect to registrant eligibility in each response field. Up to 10 Community Registration Policies can be submitted.

3. Follow this format to propose what the Registry Operator must do and/or must not do:

a) “Registry Operator shall___”; and/or

b) “Registry Operator shall not___”.

4. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars ,:

a) "Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or

b) "Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”.

5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements:

a) "Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring ___"; and/or

b) "Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting ___".

6. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example:

a) Registry Operator shall develop and implement a registration eligibility policy and publish this policy on its website no later than the date on which the TLD is delegated in the DNS.

b) Registry Operator shall review the registration policy described in (a) at least once per year, and publish the results of such review (including any updates to the registration policy) on its website within thirty (30) days following the anniversary of the Effective Date.

7. If the Community Registration Policy is limited in time, duration, scope, or any other factors, specify the applicable limitations. For example, if a registrant eligibility restriction is time-limited, the applying entity must state if the restriction will apply for the lifetime of the gTLD, only during a specified period, or for some other defined period (such as, Registry Operator shall, for a period of x days from the Effective Date, ___).

8. See Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria for evaluation criteria that ICANN will apply for evaluating each proposed Community Registration Policy.

Notes:

“Eligibility” means the qualifications that entities or individuals must have in order to be allowed as registrants by the registry.

CR-1. Submit only one action per response field.

CR-2. The proposed Community Registration Policy must be compulsory, clear, objective, and measurable. The registry operator must not have discretion as to whether or not to perform the committed action or to change the policy. Clearly state what the registry operator must do, not what the registry operator “may” or “might” do. Use definitive language, avoid qualifiers, and express certainty when describing the policy.

Instructions:

1. Draft the Community Registration Policy as proposed contract language. Policies that are approved by ICANN will be included in Specification 12 of the applicable Base Registry Agreement and will be subject to enforcement by ICANN Contractual Compliance. See Appendix 4 Base Registry Agreement, Specification 12 for drafting approach. Consider the usage of defined terms and the definitions of such terms in the 2026 Round Base RA.

2. Enter a single proposed Community Registration Policy with respect to name selection criteria or rules for the applied-for string in each response field. Up to 10 Community Registration Policies can be submitted.

3. These criteria or rules should align with the community objectives of the applied-for gTLD string.

4. Follow this format to propose what the Registry Operator must do and/or must not do:

a) “Registry Operator shall___”; and/or

b) “Registry Operator shall not___”.

5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars:

a) "Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or

b) "Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”.

6. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements:

a) "Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring___"; and/or

b) "Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting ___".

7. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example:

a) Registry Operator shall develop and implement a name selection rule and publish it on its website no later than the date on which the TLD is delegated in the DNS.

b) Registry Operator shall review the name selection rule described in (a) at least once per year, and publish the results of such review (including any updates to the rule) on its website within thirty (30) days following the anniversary of the Effective Date.

8. If the Community Registration Policy is limited in time, duration, scope, or any other factors, specify the applicable limitations. For example, if a name selection rule is time-limited, the applying entity must state if the rule will apply for the lifetime of the gTLD, only during a specified period, or for some other defined period (such as, Registry Operator shall, for a period of x days from the Effective Date, ___).

9. See Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria for evaluation criteria that ICANN will apply for evaluating each proposed Community Registration Policy.

Notes:

“Name selection” means the conditions that must be fulfilled for any second-level domain name to be deemed acceptable by the registry.

CR-1. Submit only one action per response field.

CR-2. The proposed Community Registration Policy must be compulsory, clear, objective, and measurable. The registry operator must not have discretion as to whether or not to perform the committed action or to change the policy. Clearly state what the registry operator must do, not what the registry operator “may” or “might” do. Use definitive language, avoid qualifiers, and express certainty when describing the policy.

Community (Community Registration Policy - Other; RCE Criteria

1, 2 & 3)

Instructions:

1. Draft the Community Registration Policy as proposed contract language. Policies that are approved by ICANN will be included in Specification 12 of the applicable Registry Agreement and will be subject to enforcement by ICANN Contractual Compliance. See Appendix 4 Base Registry Agreement, Specification 12 for drafting approach. Consider the usage of defined terms and the definitions of such terms in the 2026 Round Base RA.

2. Enter a single proposed Community Registration Policy in each response field. Up to 10 Community Registration Policies can be submitted.

3. Follow the format to propose what the Registry Operator must do and/or must not do:

a) “Registry Operator shall___”; and/or

b) “Registry Operator shall not___”.

4. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars:

a) "Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or

b) "Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”.

5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements:

a) "Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring___"; and/or

b) "Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting___".

6. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example:

a) Registry Operator shall develop and implement a Community Registration policy and publish this policy on its website no later than the date on which the TLD is delegated in the DNS.

b) Registry Operator shall review the Community Registration Policy described in (a) at least once per year, and publish the results of such review (including any updates to the registration policy) on its website within thirty (30) days following the anniversary of the Effective Date.

7. If the Community Registration Policy is limited in time, duration, scope, or any other factors, specify the applicable limitations. For example, if a commitment is time-limited, the applying entity must state if the rule will apply for the lifetime of the gTLD, only during a specified period, or for some other defined period (such as, Registry Operator shall, for a period of x days from the Effective Date, ___).

8. See Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria for evaluation criteria that ICANN will apply for evaluating each proposed Community Registration Policy.

CR-1. Submit only one action per response field.

CR-2. The proposed Community Registration Policy must be compulsory, clear, objective, and measurable. The registry operator must not have discretion as to whether or not to perform the committed action or to change the policy. Clearly state what the registry operator must do, not what the registry operator “may” or “might” do. Use definitive language, avoid qualifiers, and express certainty when describing the policy.

Instructions:

1. If you are proposing any limitation to a proposed Community Registration Policy in Questions 151-153, please provide a rationale in this response field. Please see Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria.

2. If you are not proposing any limitation to a proposed Community Registration Policy in Questions 151-153, please type "Not Applicable" in this response field.

Instructions:

1. Provide an explanation of how the proposed Community Registration Policies meet the Registry Commitments Evaluation criteria 4 and 5 using the considerations in the Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria.

2. Consider whether the proposed Community Registration Policy could be argued to be duplicative of a requirement under applicable law, ICANN agreements, or ICANN Consensus Policies or Temporary Policies. There may be circumstances in which a Community Registration Policy that would duplicate requirements under applicable consensus policy or law could be approved at ICANN’s sole discretion. If not duplicative, please explain why you believe the Community Registration Policy is not duplicative. If yes, please specify such a requirement and explain why you believe duplication in the Base RA is necessary.

3. Consider whether the proposed Community Registration Policy could be argued to be contrary to a requirement under applicable law, ICANN agreements, or ICANN Consensus Policies or Temporary Policies. ICANN will not approve any Community Registration Policies that are found to be contrary to applicable laws, ICANN agreements and policies. Please share your views on this issue in the answer to this question.

4. Consider whether the proposed Community Registration Policy could be argued to be incompatible with ICANN’s Bylaws. ICANN will not approve any Community Registration Policies that are found to be incompatible with the ICANN Bylaws. See background at the ICANN Board resolution 2024.06.08.08-2024.06.08.10. Please share your views on this issue in the answer to this question.

5. Consider whether the proposed Community Registration Policy requires the operation of an additional Registry Service. The applying entity shall engage its selected RSP to discuss the implementation of such an additional Registry Service, which must be evaluated through the RSP Program and approved by ICANN.

Instructions:

Please provide evidence of support for the applying entity’s application by attaching written endorsements from the organizing bodies relevant to the identified community (related to Question 136).

Instructions:

Provide an explanation of why opposition may or may not be relevant or how the applying entity intends to address or resolve the opposition, if applicable.

Is the applied-for string a geographic name as defined by it being any one of the following:

a) the capital city name of a country or territory listed in the ISO 3166-1 standard;

b) a city name, where it is clear from statements in the application that the applying entity intends to use the gTLD for purposes associated with the city name;

c) a sub-national place name listed in the ISO 3166-2 standard; or

d) Strings listed as UNESCO regions or appearing on the Geographic Regions section of the “Standard country or area codes for statistical use (M49)”

Instructions:

Select Yes or No.

Instructions:

Select Yes or No.

Instructions:

Provide a description and examples of how the TLD will be used in relation to the city name.

Geographic Terms (Support and Non-

Objection)

Instructions:

Attach documentation of support or non-objection from all relevant government entities or public authorities.

Notes:

See Section 7.5 Geographic Names for details of requirements for different types of geographical groups.

Sub-

section

Instructions:

Select Yes or No.

CR-1. Select from Radio Buttons - Yes/No

CR-2. Selection is based on the applying entities's self-assertion of Reserved Name status.

Instructions:

1. Where a parent organization exists, provide documentation of support from the parent organization including an illustration of its relationship to the applying entity.

2. Where a public authority oversees the applying entity’s organization, provide documentation of support or non-objection including a signed letter from the relevant public authority.

Instructions:

1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts:

a. Literally as described in the application.

b. Literally in any other language in which the string is a recognized word or phrase.

c. Informally in any language or regional variant, where alternative meanings exist.

2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.

CR-1. Yes/No selection

CR-2. If "yes" is selected, then the applied-for string(s) invokes a level of implied consumer trust, and must be considered to be in Safeguard Group 1 – Regulated Sectors/Open Entry Requirements in Multiple Jurisdictions – and require Safeguards 1-3.

Instructions:

1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts:

a. Literally as described in the application.

b. Literally in any other language in which the string is a recognized word or phrase.

c. Informally in any language or regional variant, where alternative meanings exist.

2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.

CR-1. Yes/No selection for each consideration.

CR-2. If "yes" is selected, then the applied-for string(s) carries elevated risk of consumer harm, and must be considered to be in Safeguard Group 1 – Regulated Sectors/Open Entry Requirements in Multiple Jurisdictions – and require Safeguards 1-3.

Instructions:

1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts:

a. Literally as described in the application.

b. Literally in any other language in which the string is a recognized word or phrase.

c. Informally in any language or regional variant, where alternative meanings exist.

2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.

CR-1. Yes/No selection for each consideration.

CR-2. If "yes" is selected, then the applied-for string(s) are associated with a market sector that has clear and/or regulated entry requirements (such as financial, gambling, professional services, environmental, health and fitness, corporate identifiers, or charity) in multiple jurisdictions, and must be considered to be in Safeguard Group 2 – Highly-Regulated Sectors/Closed Entry Requirements in Multiple Jurisdictions – and require Safeguards 1-8.

Instructions:

1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts:

a. Literally as described in the application.

b. Literally in any other language in which the string is a recognized word or phrase.

c. Informally in any language or regional variant, where alternative meanings exist.

2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.

CR-1. Yes/No selection for each consideration.

CR-2. If "yes" is selected, then the applied-for string(s) are associated with an industry where stringent licensing or accreditation is required by local, regional, or national governments. This typically involves regular inspections and ongoing government oversight, and must be considered to be in Safeguard Group 2 – Highly-Regulated Sectors/Closed Entry Requirements in Multiple Jurisdictions – and require Safeguards 1-8.

Instructions:

1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts:

a. Literally as described in the application.

b. Literally in any other language in which the string is a recognized word or phrase.

c. Informally in any language or regional variant, where alternative meanings exist.

I-2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.

CR-1. Yes/No selection.

CR-2. If "yes" is selected, then the applied-for string(s) are terms associated with harassment, intentional harm, or aggression that – intentional or not – causes distress or embarrassment to another,

and must be considered to be in Safeguard Group 3 – Potential for Cyber Bullying/Harassment – and require Safeguards 1-9.

Instructions:

1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts:

a. Literally as described in the application.

b. Literally in any other language in which the string is a recognized word or phrase.

c. Informally in any language or regional variant, where alternative meanings exist.

I-2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.

CR-1. Yes/No selection.

CR-2. If "yes" is selected, then the applied-for string(s) are associated with a function that is inherently in the domain of governments, such as military branches, and must be considered to be in Safeguard Group 4 – Inherently Governmental Functions – and require Safeguards 1-8 and Safeguard 10.

Instructions:

Select Yes or No.

Notes:

1. ICANN will evaluate whether an applied-for gTLD string requires one or more Safeguard Public Interest Commitments (Safeguard PICs) to be included in the Base RA).

2. In addition to the Mandatory Public Interest Commitments (PICs) that must be included in each Base RA, a subset of Base RAs must include Safeguard PICs based on ICANN’s Safeguard Assessment. See Section 7.8.2.3 Safeguard PICs.

3. Applying entities for TLDs that are not found to require Safeguard PICs can elect to add them to the applicable Base RAs voluntarily to, for example, further their business objectives, help address issues or concerns that are raised or could be raised with respect to their applications, or avoid the need for the evaluation and implementation of customized Registry Voluntary Commitment (RVC). See Section 7.8.3 Registry Voluntary Commitments (RVCs).

1. An option must be selected.

2. If “Yes” is selected, proceed to the next question (Question 171).

3. If “No” is selected, skip to the next section (Registry Voluntary Commitments (RVCs) - Question 172).

Instructions:

Choose the applicable Safeguard PICs from the provided list (more than one option can be selected).

Notes:

1. There are ten (10) Safeguard PICs. Applying entities may elect to incorporate one or more of the Safeguard PICs into the applicable Base RA by selecting one or more of the Safeguard PICs from this multiple choice list.

2. If any of the Safeguard PICs are selected, the selected Safeguard PIC(s) will be included as contractual obligations by the RA.

Instructions:

1. Select Yes or No.

2. In addition to Safeguard Public Interest Commitments (PICs), an applying entity will be permitted to propose one or more Registry Voluntary Commitments (RVCs) to provide additional safeguards with regard to the registry operator’s operation of an applied-for gTLD string. See Section 7.8.3 Registry Voluntary Commitments (RVCs).

3. RVCs are separate from Community Registration Policies. See Section 7.8.3 Registry Voluntary Commitments (RVCs) and Section 7.8.4 Community Registration Policies for more information. If you are applying for a Community gTLD, please submit the Community Registration Policies by answering Questions 150-155. However, if you propose to include additional Registry Voluntary Commitments in the RA beyond the Community Registration Policies, you may answer "yes" and proceed to answer the following questions.

4. You are encouraged to consider whether there are other means, separate from including commitment(s) in the Base RA, that could be used to further your business objectives or help resolve any anticipated or actual issue(s) raised regarding the applied-for gTLD string or application. See Section 7.8.3 Registry Voluntary Commitments (RVCs).

Notes:

If you select “yes” to this question, you are required to pay the conditional Registry Commitments Evaluation fee, and commitments that are approved by ICANN will be included in Specification 11 of the applicable Base RA as specific voluntary public interest commitments as contractual obligations.

1. An option must be selected.

2. If “Yes” is selected, proceed to the next question (Question 173).

3. If “No” is selected, skip to the next section (Registry Services - Question 176).

Registry Voluntary Commitments (RCE Criteria

1, 2 & 3)

Instructions:

1. Draft the Registry Voluntary Commitment (RVC) as proposed contract language. Policies that are approved by ICANN will be included in Specification 11 of the applicable Registry Agreement and will be subject to enforcement by ICANN Contractual Compliance. See Appendix 4 Base Registry Agreement, Specification 11, Section 2 for drafting approach. Consider the usage of defined terms and the definitions of such terms in the 2026 Round Base RA.

2. Enter a single proposed RVC in each response field. Up to 10 RVCs can be submitted. 3. Follow this format to propose what the Registry Operator must do and/or must not do:

a) “Registry Operator shall___”; and/or

b) “Registry Operator shall not___”.

3. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars:

a) "Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or

b) "Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”.

4. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements:

a) "Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring___"; and/or

b) "Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting___".

5. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Registry Voluntary Commitment. For example:

a) Registry Operator shall develop and implement a Registry Voluntary Commitment and publish this commitment on its website no later than the date on which the TLD is delegated in the DNS.

b) Registry Operator shall review the commitment described in (a) at least once per year, and publish the results of such review (including any updates to the registration policy) on its website within thirty (30) days following the anniversary of the Effective Date.

6. If the Registry Voluntary Commitment is limited in time, duration, scope, or any other factors, specify the applicable limitations. For example, if a commitment is time-limited, the applying entity must state if the commitment will apply for the lifetime of the gTLD, only during a specified period, or for some other defined period (such as, Registry Operator shall, for a period of x days from the Effective Date, ___).

7. See Section 7.8.3.3 Registry Commitments Evaluation Criteria for evaluation criteria that ICANN will apply for evaluating each proposed RVC.

CR-1. Submit only one action per response field.

CR-2. The proposed Registry Voluntary Commitment must be compulsory, clear, objective, and measurable. The registry operator must not have discretion as to whether or not to perform the committed action or to change the policy. Clearly state what the registry operator must do, not what the registry operator “may” or “might” do. Use definitive language, avoid qualifiers, and express certainty when describing the policy.

Registry Voluntary Commitments (RCE

Criterion 3)

Instructions:

1. If you are proposing any limitation to a proposed RVC in Question 173, please provide a rationale in this response field. See Section 7.8.3.3 Registry Commitments Evaluation Criteria.

2. If you are not proposing any limitation to a proposed RVC in Question 173, please type "Not Applicable" in this response field.

Registry Voluntary Commitments (Background, RCE

Criteria 4 & 5)

Instructions:

1. Provide background information to explain why the commitment is relevant, important, and necessary in support of the gTLD application. See Section 7.8.3.2.1 Applicants Must Identify Purposes for Proposed RVC.

2. Consider whether the proposed commitment could be argued to be duplicative of a requirement under applicable law, ICANN agreements, or ICANN Consensus Policies or Temporary Policies. There may be circumstances in which an RVC that would duplicate requirements under applicable consensus policy or law could be approved at ICANN’s sole discretion, for example, if this type of RVC is necessary to address GAC Consensus Advice. If not duplicative, please explain why you believe the commitment is not duplicative. If yes, please specify such a requirement and explain why you believe duplication in the Base RA is necessary.

3. Consider whether the proposed commitment could be argued to be contrary to a requirement under applicable law, ICANN agreements, or ICANN Consensus Policies or Temporary Policies. ICANN will not approve any commitments that are found to be contrary to applicable laws, ICANN agreements and policies. Please share your views on this issue in the answer to this question.

4. Consider whether the proposed commitment could be argued to be incompatible with ICANN’s Bylaws. ICANN will not approve any commitments that are found to be incompatible with the ICANN Bylaws. See background at the ICANN Board resolution 2024.06.08.08-2024.06.08.10. Please share your views on this issue in the answer to this question.

5. Consider whether the proposed commitment requires the operation of an additional Registry Service. The applying entity shall engage its selected RSP to discuss the implementation of such an additional Registry Service, which must be evaluated through the RSP Program and approved by ICANN.

6. For further guidance on the aforementioned considerations, please see Section 7.8.3.3 Registry Commitments Evaluation Criteria.

7. [If the commitment is being proposed as an Application Change Request]: If the commitment is being proposed in response to an objection, GAC Member Early Warning, GAC Advice, or application comment, please provide a reference to the item to which the commitment responds.

Instructions:

List all pre-evaluated RSPs this Registry intends to use. TAMS will prompt the following subquestions:

176.1 Please select a Main RSP.

176.2 Please select a DNS RSP.

176.3 Please select a DNSSEC.

176.4 [Optional] Please select a Proxy RSP.

There is a limit of one Main RSP and one DNSSEC. There is no limit to DNS RSP and Proxy. If the IDN has variants, only level 3 RSPs may be selected.

For more information about different types of RSPs, see AGB Section 3.1.10.2 Registry Functions and Types of RSPs.

Notes:

Applying entities are encouraged to identify their RSPs and intended Registry Services upon submitting their applications to avoid potential delays in processing. However, an applying entity may also submit the application without specifying RSPs, choosing to do so just before Applicant and Application Evaluation through the Change Request process. This will be one of the available options for response for this question.

Instructions:

List all Registry Services that will be used in this TLD. TAMS will prompt the following subquestions:

177.1 Select the Registry Services. The applying entity will select from a list of services that come from the selected main RSP. If no Main RSP is selected, the applying entity must choose "Will select later."

177.2 Will the applied-for variant TLDs, and, if applicable, supported IDNs, use the same registry services? The applying entity must choose yes or no. If the applying entity chooses no, the applying entity will finalize the details during contracting.

Notes:

1. Registry Services must be supported by the pre-evaluated RSPs this Registry intends to use.

2. Applying entities are encouraged to identify their RSPs and intended Registry Services upon submitting their applications to avoid potential delays in processing. However, an applying entity may also submit the application without specifying RSPs, choosing to do so just before Applicant and Application Evaluation through the Change Request process. This will be one of the available options for this question.

Instructions:

1. If IDN registrations will be supported, select the supported IDN tables from the available list. Items included are based on the selected RSP's prior evaluation.

2. If an IDN Table is not available in the list, the applying entity should reach out to the RSP to obtain ICANN's approval.

Instructions:

Select Yes or No.

Instructions:

Select Yes or No.

Instructions:

Attach an accurate and complete copy of the applicable trademark registration that forms the basis of the request for .Brand TLD qualification.

Instructions:

Provide the Signed Mark Data (SMD) File.

Notes:

Provided SMD files should correspond to the applied-for string, and any additional SMD file(s) may be submitted for variant strings.

Instructions:

Confirm statement with a checkbox.

Instructions:

Explain how the applying entity intends to operate the TLD such that there would not exist any such conflict with Section 3(d) of Specification 11.

Instructions:

This serves as an indication of intent to apply for an exemption to Specification 9 and that the applying entity is NOT requesting to be designated a .Brand TLD, pursuant to Specification 13.

Instructions:

Confirm statement with a checkbox.

Instructions:

Confirm statement with a checkbox.

Instructions:

Provide justification for why the Code of Conduct is not necessary to protect the public interest. This may include an explanation of how the TLD's operation under the exemption would serve the best interests of the registry operator, its stakeholders, and the broader Internet community, without adversely affecting the domain name ecosystem.

Instructions:

Select Yes/No.

If “Yes,” assign the Government profile and answer Questions 192-194.

If "No," proceed to the next question.

Instructions:

Select Yes/No.

If “Yes,” assign the Registry Operator profile and answer Questions 195-201.

If "No," proceed to the next question.

Instructions:

Select Yes/No.

If “Yes,” assign the Top 25 Public Stock Exchange profile, and answer Questions 202-207.

If "No," assign the Standard profile and answer Questions 208-219.

CR-1. The Top 25 Exchange profile is for a publicly traded company on a Top 25 stock exchange or an affiliated entity to the company listed on a Top 25 stock exchange. Reference: Market Statistics (https://focus.world-exchanges.org/issue/december-2025/market-statistics, as of December 2025)

CR-2. The Standard profile is for all other applying entities not qualified for one of the above profiles.

Financial Evaluation - Government Profile: Self-

Certification (Q1.1-1)¹¹

Q1.1-1 - Provide the applying entity’s self-certification document that commits government support on official letterhead from a proper authority, that the application for the gTLD(s) and its operation by the applying entity is permitted, and that represents and warrants:

SC1.1-1.1 - That the applying entity is the recognized government of its jurisdiction and that the government has authorized the application(s) for applied-for gTLD string(s) or is a recognized intergovernmental organization with relevant authorization for its application(s) for applied-for gTLD string(s).

SC1.1-1.2 - That the applying entity and/or an affiliate commits to the long-term funding required to operate all of the existing gTLDs (if applicable) and newly applied-for gTLD string(s) of the applying entity.

Instructions:

1. Provide a single document for Self-Certification question Q1.1-1.

2. The document must include only the SC1.1-1.1 and SC1.1-1.2 statements.

3. Do not modify any of the Self-Certification statements.

4. If the applying entity cannot Self-Certify the SC1.1-1.1 and SC1.1.1-2 statements, provide a document that explains why the applying entity cannot Self-Certify the SC1.1-1.1 and SC1.1.1-2 statements.

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. Applying entity provides the Self-Certification document.

CR-3. The document is signed by the applying entity and, if applicable, by the affiliate.

CR-4. The two Self-Certification statements confirm that the applying entity:

a) is the recognized government of its jurisdiction and has the authorization from the government to submit one or more applications.

b) or an affiliate commits to the long-term funding required to operate all the existing gTLDs (if applicable) and newly applied-for gTLD string(s) of the applying entity.

Financial Evaluation - Government Profile: Operational/

Planning (Q1.2-1)¹²

Instructions:

The document for Q1.2-1 must be a PDF.

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. A document with a list of all of the applying entity’s current gTLDs (if applicable) and a list of all gTLDs for entities affiliated with the applying entity (if applicable).

Financial Evaluation - Government Profile: Operational/

Planning (Q1.2-2)

Instructions:

The document for Q1.2-2 must be an Excel (.xlsx) file.

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. A document containing a list of all of the applying entity’s applied-for strings plus, for each string, a forecast of the number of Domains Under Management (DUMs) for Year 1, Year 2, and Year 3 beginning after delegation.

Sub-

section

Instructions:

1. Provide all documents prepared by the third-party accounting firm providing financial statements for this financial evaluation.

2. Annual Reports are not acceptable.

Notes:

1. A Qualified Parent Entity (QPE) is a legal entity that has at least 51% ownership in the applying entity, directly or indirectly.

2. Qualified Parent Statements (QPS) are Audited financial statements from a QPE.

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. Provide applying entity’s audited financial statements prepared by a third-party accounting firm or a Qualified Parent Entity's (QPE) audited financial statements.

CR-3. Where audited statements cannot be provided, provide either the applying entity’s reviewed or compiled financial statements for the most recently closed fiscal year or interim period.

CR-4. Acceptable accounting standards are: Nationally recognized accounting standards for the jurisdiction of the applying entity or QPE, International Financial Statements Reporting Standards (IFRS), Generally Accepted Accounting Principles (GAAP).

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. Clarify how the Qualified Parent Entity (QPE) meets the definition for providing financial statements as defined in the Financial Statements Instructions.

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. Explain why the submitted financial statements were chosen for submission, referring to “the most favorable cash flow” - indicating a strong liquidity position and ability to meet its financial obligations.

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. State what accounting standards were used to prepare the applying entity’s financial statements.

a) Acceptable accounting standards are: Nationally recognized accounting standards for the jurisdiction of the applying entity or Qualified Parent Entity (QPE), International Financial Statements Reporting Standards (IFRS), Generally Accepted Accounting Principles (GAAP).

Q2.2-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO, and/or equivalent officer of the applying entity. If financial statements are provided by a Qualified Parent Entity (QPE) of the applying entity, the CEO, President, CFO, and/or equivalent officer of the QPE must co-sign the certification document. The self-certification document must represent and warrant:

SC2.2-1.1 - As of the submission date of the application, the applying entity is a current registry operator or an affiliated entity of a current registry operator with one or more active RAs.

SC2.2-1.2 - The applying entity and/or a QPE will fund the startup and long-term operation of all of the applying entity’s current gTLDs and applied-for gTLD strings.

SC2.2-1.3 - The applying entity and/or its officers are bound by law in its jurisdiction to represent financial statements accurately and the applying entity is in good standing in that jurisdiction.

Instructions:

1. Provide a single document for Self-Certification question Q2.2-1.

2. The document must include only the SC2.2-1.1 through SC2.2-1.3 statements.

3. Do not modify any of the Self-Certification statements.

4. If the applying entity cannot Self-Certify the SC2.2-1.1 through SC2.2-1.3 statements, provide a document that explains why the applying entity cannot Self-Certify the SC2.2-1.1 through SC2.2-1.3 statements.

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. Applying entity provides the Self-Certification document.

CR-3. The document is signed by the applying entity and, if applicable, by a Qualified Parent Entity (QPE).

CR-4. The three Self-Certification statements in the question confirm the applying entity:

a) is a current registry operator or an affiliated entity of a current registry operator,

b) commits to long-term funding for all current and applied-for gTLD strings,

c) is bound by law in its jurisdiction to represent financial statements accurately, and is in “good standing in that jurisdiction”: filing annual reports, business licenses, and other required documents on time; paying required fees, taxes, and other financial obligations; maintaining proper registrations with local, state, and national authorities are current and accurate.

Instructions:

The document for Q2.3-1 must be a PDF.

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. A document with a list of all of the applying entity’s current gTLDs (if applicable) and a list of all gTLDs for entities affiliated with the applying entity (if applicable).

Instructions:

The document for Q2.3-2 must be an Excel (.xlsx).

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. A document containing a list of all of the applying entity’s applied-for strings plus, for each string, a forecast of the number of Domains Under Management (DUMs) for Year 1, Year 2, and Year 3 beginning after delegation.

Instructions:

1. Provide all documents prepared by the third-party accounting firm providing financial statements for this financial evaluation.

2. Annual Reports are not acceptable.

Notes:

1. A Qualified Parent Entity (QPE) is a legal entity that has at least 51% ownership in the applying entity, directly or indirectly.

2. Qualified Parent Statements (QPS) are Audited financial statements from a QPE.

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. Provide applying entity’s audited financial statements prepared by a third-party accounting firm or a Qualified Parent Entity's (QPE) audited financial statements.

CR-3. Acceptable accounting standards are: Nationally recognized accounting standards for the jurisdiction of the applying entity or QPE, International Financial Statements Reporting Standards (IFRS), Generally Accepted Accounting Principles (GAAP).

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. Clarify how the Qualified Parent Entity (QPE) meets the definition for providing financial statements as defined in the Financial Statements Instructions.

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. Explain why the submitted financial statements were chosen for submission, referring to “the most favorable cash flow” - indicating a strong liquidity position and ability to meet its financial obligations.

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. State what accounting standards were used to prepare the applying entity’s financial statements.

a) Acceptable accounting standards are: Nationally recognized accounting standards for the jurisdiction of the applying entity or Qualified Parent Entity (QPE), International Financial Statements Reporting Standards (IFRS), Generally Accepted Accounting Principles (GAAP).

Q3.2-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. If the applying entity’s financial statements are provided by a Qualified Parent Entity (QPE), the CEO, President, CFO, and/or equivalent officer of the QPE must co-sign the certification document. The self-certification document must represent and warrant:

SC3.2-1.1 - As of the submission date of the application, the applying entity is currently a listed member in one or more of the public stock exchanges identified on ICANN’s list from Market Statistics (https://focus.world-exchanges.org/issue/december-2025/market-statistics, as of December 2025), including information on both the relevant exchange and the current registration ticker symbol.

SC3.2-1.2 - The applying entity is in good standing with the public stock exchange in which it is a listed member.

SC3.2-1.3 - The applying entity commits to the long-term funding of all applied-for gTLD strings.

SC3.2-1.4 - The applying entity and/or its officers are bound by law in its jurisdiction to represent financial statements accurately and the applying entity is in good standing in that jurisdiction.

Instructions:

1. Provide a single document for Self-Certification question Q3.2-1.

2. The document must include only the SC3.2-1.1 through SC3.2-1.4 statements.

3. Do not modify any of the Self-Certification statements.

4. If the applying entity cannot Self-Certify the SC3.2-1.1 through SC3.2-1.4 statements, provide a document that explains why the applying entity cannot Self-Certify the SC3.2-1.1 through SC3.2-1.4 statements.

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. Applying entity provides the Self-Certification document.

CR-3. The document is signed by the applying entity and, if applicable, by a Qualified Parent Entity (QPE).

CR-4. The four Self-Certification statements in the question confirm the applying entity:

a) is a currently listed member in one of the public stock exchanges identified at Market Statistics (https://focus.world-exchanges.org/issue/december-2025/market-statistics, as of December 2025),

b) is in good standing – in compliance with all rules and regulations for ongoing listing – with the public stock exchange of which the applying entity is a listed member.

c) commits to long-term funding for all applied-for gTLD strings,

d) is bound by law in its jurisdiction to represent financial statements accurately and is in “good standing in that jurisdiction”: filing annual reports, business licenses, and other required documents on time; paying required fees, taxes, and other financial obligations; maintaining proper registrations with local, state, and national authorities are current and accurate.

Instructions:

The document for Q3.3-1 must be an Excel (.xlsx).

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. A document containing a list of all of the applying entity’s applied-for strings plus, for each string, a forecast of the number of Domains Under Management (DUMs) for Year 1, Year 2, and Year 3 beginning after delegation.

Instructions:

1. Provide all documents prepared by the third-party accounting firm providing financial statements for this financial evaluation.

2. Annual Reports are not acceptable.

Notes:

1. A Qualified Parent Entity (QPE) is a legal entity that has at least 51% ownership in the applying entity, directly or indirectly.

2. Qualified Parent Statements (QPS) are Audited financial statements from a QPE.

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. Provide applying entity’s audited financial statements prepared by a third-party accounting firm or a Qualified Parent Entity's (QPE) audited financial statements.

CR-3. Where audited statements cannot be provided, provide either the applying entity’s reviewed or compiled financial statements for the most recently closed fiscal year or interim period.

CR-4. Acceptable accounting standards are: Nationally recognized accounting standards for the jurisdiction of the applying entity or QPE, International Financial Statements Reporting Standards (IFRS), Generally Accepted Accounting Principles (GAAP).

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. Clarify how the Qualified Parent Entity (QPE) meets the definition for providing financial statements as defined in the Financial Statements Instructions.

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. Explain why the submitted financial statements were chosen for submission, referring to “the most favorable cash flow” - indicating a strong liquidity position and ability to meet its financial obligations.

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. State what accounting standards were used to prepare the applying entity’s financial statements.

a) Acceptable accounting standards are: Nationally recognized accounting standards for the jurisdiction of the applying entity or Qualified Parent Entity (QPE), International Financial Statements Reporting Standards (IFRS), Generally Accepted Accounting Principles (GAAP).

Q4.2-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. If financial statements are provided by a Qualified Parent Entity (QPE), the CEO, President, CFO, and/or equivalent officer of the QPE must co-sign the certification document. The self-certification document must represent and warrant:

SC4.2-1.1 - The applying entity and/or a QPE will fund the startup and long-term operation of all applied-for gTLD strings and (if applicable) currently operated gTLDs of a QPE.

SC4.2-1.2 - The applying entity or QPE has at a minimum of USD 50,000 plus 25% of the application base fee for each applied-for gTLD string in Cash and Cash Equivalents on the balance sheet of the provided financial statements, up to a maximum of USD 300,000, designated to support the startup and operation of all of the applying entity’s applied-for gTLD strings.

SC4.2-1.3 - The applying entity and/or its officers are bound by law in its jurisdiction to represent financial statements accurately and the applying entity is in good standing in that jurisdiction.

Instructions:

1. Provide a single document for Self-Certification question Q4.2-1.

2. The document must include only the SC4.2-1.1 through SC4.2-1.3 statements.

3. Do not modify any of the Self-Certification statements.

4. If the applying entity cannot Self-Certify the SC4.2-1.1 through SC4.2-1.3 statements, provide a document that explains why the applying entity cannot Self-Certify the SC4.2-1.1 through SC4.2-1.3 statements.

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. Applying entity provides the Self-Certification document.

CR-3. The document is signed by the applying entity and, if applicable, by a Qualified Parent Entity (QPE).

CR-4. The three Self-Certification statements in the question confirm the applying entity:

a) commits to long-term funding for all current and applied-for gTLD strings,

b) has at a minimum of USD 50,000 plus 25% of the application fee for each applied-for gTLD string in Cash and Cash Equivalents on the balance sheet of the applying entity provided financial statements , up to a maximum of USD 300,000, designated to support the startup and operation of all of the applying entity’s applied-for gTLD strings.

c) is bound by law in its jurisdiction to represent financial statements accurately and is in “good standing in that jurisdiction”: filing annual reports, business licenses, and other required documents on time; paying required fees, taxes, and other financial obligations; maintaining proper registrations with local, state, and national authorities are current and accurate.

Instructions:

The Instructions for the Most Likely Scenario (MLS) are in the Instructions - Financial Evaluation Template - document.¹³

Note:

See Appendix 5 for Templates for Standard Financial Profile, which includes the following templates: Most Likely Scenario Financial Projection, Worst Case Scenario Financial Projection, Risk Assessment Template, and Registration Projections Template.

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. The Most Likely Scenario (MLS) Projections Template has not been modified.

CR-3. All required cells have data input.

CR-4. Cash on Hand at Time of Application calculation is correct.

CR-5. Cash and Cash Equivalents from the provided financial statement’s balance sheet exceed the Cash on Hand at Time of Application.

CR-6. All rows with data have sufficient relevant Comments content.

CR-7. Projected Total Cash Flow is positive in Year 3.

Instructions:

The Instructions for the Most Likely Scenario (MLS) are in the Instructions - Financial Evaluation Template document.

Note:

See Appendix 5 for Templates for Standard Financial Profile, which includes the following templates: Most Likely Scenario Financial Projection, Worst Case Scenario Financial Projection, Risk Assessment Template, and Registration Projections Template.

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. The Most Likely Scenario (MLS) Projections Template has not been modified.

CR-3. All required cells for Operating Costs have data input.

CR-4. All rows with input data have sufficient relevant Comments content as specified in the Instructions - Financial Evaluation Template document (see Appendix 5).

CR-5. Variances for 20% or more are Explained in Comments,

CR-6. Provided Pre-evaluated RSP and all other outsourced contracts, LOIs, or proposals (except employment agreements).

CR-7. Contracts, Letters of Intent (LOIs), and proposals costs are accounted for in the MLS Projections Template.

Instructions:

The Instructions for the Most Likely Scenario (MLS) are in the Instructions - Financial Evaluation Template document.

Note:

See Appendix 5 for Templates for Standard Financial Profile, which includes the following templates: Most Likely Scenario Financial Projection, Worst Case Scenario Financial Projection, Risk Assessment Template, and Registration Projections Template.

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. Provided Pre-evaluated RSP and all other outsourced contracts, Letters of Intent (LOIs), or proposals (except employment agreements).

Instructions:

The Instructions for the Funding and Revenue are in the Instructions - Financial Evaluation Template document.

Notes:

1. Funding can be derived from several sources such as existing capital or proceeds/revenue from operation of a registry.

2. Funding resources must be adequately provided to produce positive cash flow by the end of the third year of operations.

3. See Appendix 5 for Templates for Standard Financial Profile, which includes the following templates: Most Likely Scenario Financial Projection, Worst Case Scenario Financial Projection, Risk Assessment Template, and Registration Projections Template.

CR1. Applying entity provided a strategy registration revenue that included all applied-for gTLD strings collectively, launch plans, market size and planned penetration goals, unique registry services, etc.

CR-2. Applying entity clearly identified any other funding sources, amounts, and timing of use for each source.

Instructions:

The Instructions for the Funding and Revenue are in the Instructions - Financial Evaluation Template document.

Notes:

1. Funding can be derived from several sources such as existing capital or proceeds/revenue from operation of a registry.

2. Funding resources must be adequately provided to produce positive cash flow by the end of the third year of operations.

See Appendix 5 for Templates for Standard Financial Profile, which includes the following templates: Most Likely Scenario Financial Projection, Worst Case Scenario Financial Projection, Risk Assessment Template, and Registration Projections Template.

CR-1. Applying entity provided a strategy registration revenue that included all applied-for gTLD strings collectively, launch plans, market size and planned penetration goals, unique registry services, etc.

CR-2. Applying entity clearly identified any other funding sources, amounts, and timing of use for each source.

Instructions:

Instructions for the Risk Assessment are provided in the Instructions - Financial Evaluation Template document.

Note:

See Appendix 5 for Templates for Standard Financial Profile, which includes the following templates: Most Likely Scenario Financial Projection, Worst Case Scenario Financial Projection, Risk Assessment Template, and Registration Projections Template.

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. All required Risk Assessments were completed – Risk Scenario, Probably, Impact, Mitigation.

CR-3. Any applying entity identified risks were assessed and documented in the Risk Assessment Template

Instructions:

The Instructions for the Worst Case Scenario (WCS) are in the Instructions - Financial Evaluation Template document.

Notes:

1. The Worst-Case Scenario (WCS) Financial Projection will quantify the plans to operate the registry when events occur that negatively impact the ability to fund the applying entity’s applied-for gTLD strings.

2. See Appendix 5 for Templates for Standard Financial Profile, which includes the following templates: Most Likely Scenario Financial Projection, Worst Case Scenario Financial Projection, Risk Assessment Template, and Registration Projections Template.

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. The Worst Case Scenario (WCS) Projections Template has not been modified.

CR-3. All required cells have data input.

CR-4. Cash on Hand at Time of Application calculation is correct.

CR-5. Cash and Cash Equivalents from the provided financial statement’s balance sheet exceed the Cash on Hand at Time of Application.

CR-6. All rows with data have sufficient relevant Comments content.

CR-7. Projected Total Cash Flow is positive in Year 3.

Q5.1-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. The self-certification document must represent and warrant:

SC5.1-1.1 - The applying entity will appropriately protect confidentiality of data and prevent unauthorized access to data and services.

SC5.1-1.2 - The applying entity will maintain a mature, appropriately funded and staffed security Program, following a recognized, modern security framework based on risk management (such as the ISO27000 series, COBIT, HITRUST CSF, legally required security frameworks, or equivalent). The security Program must be in place prior to delegation, and exist through at least the period of the Base RA.

SC5.1-1.3 - The applying entity is aware of and has designed its systems and business to comply with the relevant privacy and security regulations for all countries in which it operates.

Instructions:

1. Provide a single document for Self-Certification question Q5.1-1.

2. The document must include only the SC5.1-1.1 through SC5.1-1.3 statements.

3. Do not modify any of the Self-Certification statements.

4. If the applying entity cannot Self-Certify the SC5.1-1.1 through SC5.1-1.3 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.1-1.1 through SC5.1.1-3 statements.

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. Applying entity provides the Self-Certification document.

CR-3. The document is signed by the applying entity.

CR-4. The three Self-Certification Statements confirm that the applying entity:

a) commits to its role in the protection of confidentiality of data in the applying entity’s care, and prevention of unauthorized access to applying entity’s services.

b) has planned for and will budget to support the operation of the necessary security capabilities.

c) has or plans to implement a recognized, modern security framework based on risk management such as the ISO27000 series, COBIT, HITRUST CSF, legally required security frameworks, or equivalent.

d) has a plan to ensure appropriate staffing for its security capabilities.

e) has designed operational practices and technical infrastructure to meet the security and privacy requirements it is subject to.

Q5.2-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. The self-certification document must represent and warrant:

SC5.2-1.1 - The applying entity will, no later than delegation of the Top Level Domain (TLD), establish a dedicated abuse point of contact responsible for addressing matters requiring expedited attention and providing a timely response to abuse complaints concerning any name registered in the TLD.

SC5.2-1.2 - The applying entity will, no later than delegation of the TLD, establish, publish, and provide to ICANN the location of a mechanism for members of the public to submit reports of abuse in accordance with the current obligations of the Base RA and any Consensus Policies.

SC5.2-1.3 - The applying entity has developed proposed measures for removal of orphan glue records for names removed from the zone when provided with evidence in written form that the glue is present in connection with malicious conduct (see Specification 6).

SC5.2-1.4 - The applying entity has or will have at time of delegation, established policies for handling complaints regarding abuse. Such policies are to be maintained and posted publicly so that anyone can review the policies via the Internet and any other means deemed appropriate by the applying entity. The applying entity’s policies at a minimum should contain appropriate confirmation of the receipt of the abuse report, the process of review of the report, and actions that will be taken if the applying entity confirms the report is legitimate.

SC5.2-1.5 - The applying entity understands that DNS Abuse is Phishing, Malware, Botnets, Pharming and Spam (when used to deliver other forms of DNS Abuse). The applying entity understands and is prepared to contribute to the mitigation or disruption of DNS Abuse in domains in the TLD zone.

SC5.2-1.6 - The applying entity’s abuse response capabilities are resourced appropriately to ensure a timely and adequate investigation and response to reports of DNS Abuse. This includes capabilities to receive and evaluate evidence of DNS Abuse in reports, and to take action to stop or disrupt the DNS Abuse.

SC5.2-1.7 - The applying entity is prepared to conduct periodic scans of its zone to identify if domains are being used to perpetrate DNS Abuse, and to maintain statistical reports of the scans, the findings, and actions taken.

Instructions:

1. Provide a single document for Self-Certification question Q5.2-1.

2. The document must include only the SC5.2-1.1 through SC5.2-1.7 statements.

3. Do not modify any of the Self-Certification statements.

4. If the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements.

CR-1. Applying entity follows the Instructions without exception and provides complete, commercially reasonable, and good-faith responses.

CR-2. Applying entity provides the Self-Certification document.

CR-3. The document is signed by the applying entity.

CR-4. The seven Self-Certification Statements confirm that the applying entity:

a) will, no later than delegation of the Top-Level Domain (TLD), establish a dedicated abuse point of contact and provide a timely response to abuse complaints

b) will, no later than delegation of the TLD, establish, publish, and provide to ICANN the location of a mechanism for members of the public to submit reports of abuse in accordance with the current obligations of the Base RA and any Consensus Policies

c) has developed proposed measures for removal of orphan glue records for names removed from the zone when provided with evidence in written form that the glue is present in connection with malicious conduct (see Specification 6).

d) has established and maintains policies on handling complaints regarding abuse. Such policies are posted publicly so that anyone can review the policies via the Internet and any other means deemed appropriate by the applying entity. The applying entity’s policies at a minimum should contain appropriate confirmation of the receipt of the abuse report, the process of review of the report, and actions that will be taken if the applying entity confirms the report is legitimate.

e) confirms that DNS Abuse is Phishing, Malware, Botnets, Pharming and Spam (when used to deliver other forms of DNS Abuse). The applying entity is prepared to contribute to the mitigation or disruption of DNS Abuse in domains in the TLD zone.

f) will resource abuse response capabilities appropriately to ensure a timely investigation and response to reports of DNS Abuse, receive and evaluate evidence of DNS Abuse in reports, and to take action to stop or disrupt the DNS Abuse.

g) is prepared to conduct periodic scans of its zone to identify if domains are being used to perpetrate DNS Abuse, and to maintain statistical reports of the scans, the findings, and actions taken.

Instructions:

1. An applying entity may use this response field to submit any additional, optional information or documentation that the applying entity believes enhances understanding of its application or may be of interest to the general public. This could include, but is not limited to, the applying entity’s:

a) Individual registry policies;

b) Separate agreement with a third party to fulfill certain commitments;

c) Terms of use;

d) Additional registration policies not intended for RA inclusion;

e) Other materials that clarify the applying entity’s mission, values, or intended use of the gTLD.

Notes:

1. This question is optional and for informational purposes only.

2. The information provided here will not be evaluated as part of the application, or be contractually binding on the applying entity.

3. All submissions to this question will be posted for the public to review and comment.

Instructions:

Confirm the statement using the checkbox.

Instructions:

Confirm the statement using the checkbox.

Instructions:

Select one of the following options:

1. The applying entity elects to receive the Application Volume Refund if one is made available.

2. The applying entity does not elect to receive the Application Volume Refund and understands that the applying entity forfeits a future request to obtain that refund if one is made available.

Notes:

ICANN has indicated the potential situation to offer an Application Volume Refund where more than 1,000 applications are submitted and implementation costs have been recovered; see Application Volume Refund.