.icp

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 US$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 US$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.

Answered with a document. Attachments are not published by ICANN.

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 registry agreement. 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.

Answered with a document. Attachments are not published by ICANN.

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.

Answered with a document. Attachments are not published by ICANN.

Script of String

Latin

As per Section 3(d) of Specification 11 of the Base Registry Agreement, a registry operator of a “generic string” may not impose eligibility criteria for registering names in the TLD that limit registrations exclusively to a single person or entity and/or that person’s or entity’s “Affiliates” (as defined in Section 2.9(c) of the Registry Agreement). “Generic String” means a string consisting of a word or term that denominates or describes a general class of goods, services, groups, organizations or things, as opposed to distinguishing a specific brand of goods, services, groups, organizations or things from those of others. Confirm that the applied-for string is not a “generic string” in which the applying entity intends to limit registrations exclusively to a single person or entity.

true

Explain the rationale for any limitations to the commitment proposed by the applying entity in Question 173.

The RVC is limited to the web frontend rather than the full technology stack because defining and verifying a comprehensive hosting requirement for all application components is technically impractical. While ICP supports full-stack hosting including data storage and backend logic, many applications legitimately interact with APIs of external services, making it infeasible to draw a clear compliance boundary for backend infrastructure. The frontend requirement is meaningful because it is the component that is publicly served at the domain name and can be cryptographically verified. Verification mechanism: The Registry Operator will operate an automated compliance scanner that periodically issues HTTP requests to registered .icp domains and validates the ic-certificate response header. This scanner checks (1) that the header is present, (2) that the certificate's Merkle proof is valid against the subnet's public key, and (3) that the response body matches the certified hash. Scans are performed at minimum monthly after the 90-day activation window and again at each annual renewal. Lifecycle integration: A newly registered domain enters a 90-day activation grace period during which no compliance check is enforced. After activation, non-compliant domains trigger a notification to the registrar of record, who must notify the registrant and allow a 30-day cure period. If the domain remains non-compliant after the cure period, the registrar must place the domain on serverHold. Domains in redemption or pending-delete states are exempt from active compliance checks. On transfer to a new registrant, a new 90-day activation window begins, provided the domain has not already exhausted its cumulative non-compliance allowance. A domain may not remain non-compliant for more than 90 days in any rolling 12-month period, regardless of how many transfers occur; if a domain is still non-compliant at the time of its annual renewal, renewal is blocked until compliance is restored. The Registry Operator publishes a compliance dashboard and provides registrars with an API to query the compliance status of domains in their portfolio.

Why are the commitment(s) being proposed?

This commitment ensures that the .icp TLD serves its intended purpose: providing a namespace for applications hosted on the Internet Computer Protocol. Without such a commitment, .icp domains could be used for conventional web hosting unrelated to ICP, diluting the TLD's identity. What makes this commitment uniquely feasible is the ic-certificate verification mechanism, which provides a cryptographic, machine-verifiable proof of ICP hosting — unlike most registry voluntary commitments, compliance can be checked automatically and objectively without human judgment. The verification mechanism is fully transparent: the IC interface specification and HTTP Gateway Protocol Specification are publicly documented (https://docs.internetcomputer.org/references/http-gateway-protocol-spec), the response-verification library is open source (https://github.com/dfinity/response-verification), and the NNS root public key is a published, immutable value. Any independent party — including ICANN compliance staff, registrars, or third-party auditors — can verify ic-certificate headers without reliance on DFINITY infrastructure. This commitment aligns with DFINITY's mission to build open internet infrastructure and ensures the .icp TLD remains a trusted, purpose-driven namespace.

If the applying entity wishes to provide any additional information or supporting materials that the applying entity believes may be of interest to the public or relevant to the application, please include them here.

Answered with a document. Attachments are not published by ICANN.

By submitting this Application, the applying entity confirms that it is submitting this Application with a good faith (“bona fide”) intent to operate the gTLD for which it has applied, and that the applying entity has read and understands the provisions of Section 5.2.3.1 Prohibited Communications and Activities of the Applicant Guidebook regarding the New gTLD Program rules prohibiting certain communications and activities to prevent parties from privately resolving string contention among themselves.

true

By submitting this Application, the applying entity confirms that it has read and understands the provisions of Section 5.2.3.1 Prohibited Communications and Activities of the Applicant Guidebook regarding the New gTLD Program rules prohibiting certain communications and activities to prevent parties from privately resolving string contention among themselves.

true