Skip to main content

Continued Operations Instrument Guidelines Available for New gTLD Applicants

As part of the new gTLD program, all new gTLD applicants are required to provide a cost estimate for funding critical registry functions on an annual basis in case of registry failure.

Several community members and prospective applicants asked ICANN for further guidelines regarding the calculation of these estimated costs. After analyzing the costs provided from several potential providers who responded to the recent EBERO-RFI (Emergency Back End Registry Operator - Request for Information) (see:, ICANN is providing the cost guidance in the table below.

The numbers provided are based on data gleaned from the proposals received, and are for guidance only. None of the costs in the table are identical to the estimates provided by the potential providers. All applicants are expected to complete calculations according to their particular circumstances, and to provide rationale for their cost estimates commensurate with the technical, operational, and financial approach described in the application.

Also note that these are costs only for providing the five critical registry functions identified in this process. These cost guidelines are not representative of the costs needed for running all of the services associated with operating a gTLD.

Applicants should ensure that the financial instrument will cover the costs for the five critical registry functions for a period of three years using the applicant’s projections of domain registrations under management.

Continued Operations Instrument Guidance:

Projected Number of Domains Estimated 3 Year COI (USD)
10,000 $18,000
25,000 $40,000
50,000 $80,000
100,000 $140,000
250,000 $250,000
> 250,000 $300,000

Note: The minimum COI for any new gTLD should be US $18,000. The Maximum COI for any new gTLD need not be more than US $300,000.

Bank rating guidance

The financial instrument must be issued/held by a financial institution rated “A” or above (or the equivalent) by any of the following rating agencies: A.M. Best, Dominion Bond Rating Service, Egan-Jones, Fitch Ratings, Kroll Bond Rating Agency, Moody’s, Morningstar, Standard & Poors, and Japan Credit Rating Agency.

If applicant cannot access an “A” rated financial institution, but a branch or subsidiary exists in the applicant’s local jurisdiction then applicant may use any local institution with a similar or higher rating.

As a last resort applicants may use the highest-rated financial institution in their national jurisdiction, if accepted by ICANN.

Note: For any financial instruments that contemplate ICANN being a party, upon the written request of the applicant, ICANN may (but is not obligated to) execute such agreement prior to submission of the applicant's application if the agreement is on terms acceptable to ICANN. ICANN encourages applicant to deliver a written copy of any such agreement (only if it requires ICANN's signature) to ICANN as soon as possible to facilitate ICANN's review. If the financial instrument requires ICANN's signature, then the applicant will only receive 3 points for question 50 (for the instrument being "secured and in place") if ICANN executes the agreement prior to submission of the application. ICANN will determine, in its sole discretion, whether to execute and become a party to a financial instrument.

Why is the Continued Operations Instrument important?

As registrant protection is critical, new gTLD applications are required to provide evidence that the critical registry functions will continue to be performed even if the registry operator fails. The critical functions of a registry which must be supported even if an applicant’s business and/or funding fails are: (1) DNS resolution for registered domain names; (2) operation of the Shared Registration System; (3) provision of Whois service; (4) registry data escrow deposits; and (5) maintenance of a properly signed zone in accordance with DNSSEC requirements. This provides an opportunity for existing registrants in the TLD to maintain existing services dependent on registered domain names, and creates the ability for these registrants to plan for an extended transition where necessary.

ICANN’s core values and bylaws states that preserving and enhancing the operational stability, reliability, security, and global interoperability of the Internet should guide ICANN’s decisions and actions. The Continued Operations Instrument requirements are in pursuit of this principle and as a result of the development of ICANN’s Registry Continuity Framework.

Where can I find more information?

The current model proposed by ICANN is outlined in the Applicant Guidebook, in particular please refer to question 50 in the Evaluation Questions and Criteria set forth in Module 2, and Specification 8 of the Registry Agreement.

In April 2009, ICANN published the ICANN gTLD Registry Continuity Plan – This document depicts a gTLD Registry Continuity Framework developed in collaboration with experienced gTLD, ccTLD registries and members of the technical community.

In May 2010 ICANN published a New Top-Level Domain Explanatory Memorandum "gTLD Registry Transition Processes Model" (RyTP) - [PDF, 747 KB]. This document further elaborates on the concept of critical functions required for maintaining Top-Level Domain services and discusses the types of transitions between one Registry Operator and another.

Links to Relevant Information:

More Announcements
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."