Document:

EX-10.16

 Exhibit 10.16 

2013 Registrar Accreditation Agreement 
  

	1.	Registrar Accreditation Agreement 

  

	2.	Whois Accuracy Program Specification 

  

	3.	Registration Data Directory Service (Whois) Specification 

  

	4.	Consensus and Temporary Policy Specification 

  

	5.	Specification on Privacy and Proxy Registrations 

  

	6.	Data Retention Specification 

  

	7.	Registrar Information Specification 

  

	8.	Additional Registrar Operation Specification 

  

	9.	Registrants’ Benefits and Responsibilities 

  

	10.	Logo License Specification 

  

	11.	Compliance Certificate 

  

	12.	Transition Addendum 

			
	

	  	 Registrar

Accreditation

Agreement

 This REGISTRAR
ACCREDITATION AGREEMENT (this “Agreement”) is by and between the Internet Corporation for Assigned Names and Numbers, a California non-profit, public benefit corporation (“ICANN”), and GoDaddy.com, LLC, a Delaware Limited
Liability Company (“Registrar”), and shall be deemed made on 14 July 2013, at Los Angeles, California, USA. 
 1. DEFINITIONS. For
purposes of this Agreement, the following definitions shall apply: 
 1.1 “Account Holder” means the person or entity that is paying for the
Registered Name or otherwise controls the management of the registered name, when that person or entity is not the Registered Name Holder. 
 1.2
“Accredited” or “Accreditation” means to identify and set minimum standards for the performance of registration functions, to recognize persons or entities meeting those standards, and to enter into an accreditation agreement
that sets forth the rules and procedures applicable to the provision of Registrar Services. 
 1.3 “Affiliate” means a person or entity that,
directly or indirectly, through one or more intermediaries, Controls, is controlled by, or is under common control with, the person or entity specified. 

1.4 “Affiliated Registrar” is another Accredited registrar that is an Affiliate of Registrar. 

1.5 “Applicable Registrar Family” means, with respect to Affiliated Registrars, such Affiliated Registrar as a group. 

1.6 “Consensus Policy” has the meaning set forth in the Consensus Policies and Temporary Policies Specification attached hereto. 

1.7 “Control” (including the terms “controlled by” and “under common control with”) means the possession, directly or
indirectly, of the power to direct or cause the direction of the management or policies of a person or entity, whether through the ownership of securities, as trustee or executor, by serving as an employee or a member of a hoard of directors or
equivalent governing body, by contract, by credit arrangement or otherwise. 
 1.8 “DNS” refers to the Internet domain-name system. 

1.9 The “Effective Date” is 1 August 2013. 
 1.10
The “Expiration Date” is 31 July 2018. 

  
 1 

 1.11 “gTLD” or “gTLDs” refers to the top-level domain(s) of the DNS delegated by ICANN
pursuant to a registry agreement that is in full force and effect, other than any country code TLD (ccTLD) or internationalized domain name (IDN) country code TLD. 

1.12 “gTLD Zone-File Data” means all data contained in a DNS zone file for the registry, or for any subdomain for which Registry Services are
provided and that contains Registered Names, as provided to nameservers on the Internet. 
 1.13 “Illegal Activity” means conduct involving use of
a Registered Name sponsored by Registrar that is prohibited by applicable law and/or exploitation of Registrar’s domain name resolution or registration services in furtherance of conduct involving the use of a Registered Name sponsored by
Registrar that is prohibited by applicable law. 
 1.14 “Personal Data” refers to data about any identified or identifiable natural person. 

1.15 “Registered Name” refers to a domain name within the domain of a gTLD, whether consisting of two (2) or more (e.g., john.smith.name)
levels, about which a gTLD Registry Operator (or an Affiliate or subcontractor thereof engaged in providing Registry Services) maintains data in a Registry Database, arranges for such maintenance, or derives revenue from such maintenance. A name in
a Registry Database may be a Registered Name even though it does not appear in a zone file (e.g., a registered but inactive name) 
 1.16 “Registered
Name Holder” means the holder of a Registered Name. 
 1.17 The word “registrar,” when appearing without an initial capital letter, refers to
a person or entity that contracts with Registered Name Holders and with a Registry Operator and collects registration data about the Registered Name Holders and submits registration information for entry in the Registry Database. 

1.18 “Registrar Approval” means the receipt of either of the following approvals: 

1.18.1 The affirmative approval of Applicable Registrars accounting for 90% of the Total Registered Names Under Management by the Applicable
Registrars; provided that, for purposes of calculating the Total Registered Names Under Management by Applicable Registrars, the Total Registered Names Under Management by each Applicable Registrar Family shall not exceed the Total Registered Names
Under Management of the Applicable Registrar Family that is the fifth largest Applicable Registrar Family (measured by number of Registered Names Under Management), both for purposes of the numerator and the denominator; or 

1.18.2 The affirmative approval of 50% plus one of the Applicable Registrars that participate in the process to approve or disapprove (i.e.
vote for or against, but not abstain or otherwise fail to vote) a proposed amendment under Section 6, and the affirmative approval of Applicable Registrars accounting for 66.67% of the Total Registered Names Under Management by all
Applicable Registrars; provided that, for purposes of calculating the Total Registered Names Under Management by Applicable Registrars, the Total Registered Names Under Management by each 

  
 2 

 
Applicable Registrar Family shall not exceed the total Registered Names Under Management of the Applicable Registrar Family that is the fifth largest Applicable Registrar Family (measured by
number of Registered Names Under Management), both for purposes of the numerator and the denominator. An example of these calculations is set forth in Appendix 1 attached hereto. 

1.19 “Registrar Services” means the services subject to this Agreement provided by a registrar in connection with a gTLD, and includes contracting
with Registered Name Holders, collecting registration data about the Registered Name Holders, and submitting registration information for entry in the Registry Database. 

1.20 “Registry Data” means all Registry Database data maintained in electronic form, and shall include gTLD Zone-File Data, all data used to provide
Registry Services and submitted by registrars in electronic form, and all other data used to provide Registry Services concerning particular domain name registrations or nameservers maintained in electronic form in a Registry Database. 

1.21 “Registry Database” means a database comprised of data about one or more DNS domain names within the domain of a registry that is used to
generate either DNS resource records that are published authoritatively or responses to domain-name availability lookup requests or Whois queries, for some or all of those names. 

1.22 A “Registry Operator” is the person or entity then responsible, in accordance with an agreement between ICANN (or its assignee) and that person
or entity (those persons or entities) or, if that agreement is terminated or expires, in accordance with an agreement between the US Government and that person or entity (those persons or entities), for providing Registry Services for a specific
gTLD. 
 1.23 “Registry Services,” with respect to a particular gTLD, shall have the meaning defined in the agreement between ICANN and the
Registry Operator for that gTLD. 
 1.24 A “Reseller” is a person or entity that participates in Registrar’s distribution channel for domain
name registrations (a) pursuant to an agreement, arrangement or understanding with Registrar or (b) with Registrar’s actual knowledge, provides some or all Registrar Services, including collecting registration data about Registered
Name Holders, submitting that data to Registrar, or facilitating the entry of the registration agreement between the Registrar and the Registered Name Holder. 

1.25 “Restricted Amendment” means (i) an amendment of the Consensus Policies and Temporary Policies Specification or (ii) the term of this
Agreement as specified in Section 5.1, as such term may be extended pursuant to Section 5.2. 
 1.26 A Registered Name is “sponsored” by
the registrar that placed the record associated with that registration into the registry. Sponsorship of a registration may be changed at the express direction of the Registered Name Holder or, in the event a registrar loses Accreditation, in
accordance with then-current ICANN Specifications and Policies. 

  
 3 

 1.27 “Specifications and/or Policies” include Consensus Policies, Specifications (such as the Whois
Accuracy Program Specification) referenced in this Agreement, and any amendments, policies, procedures, or programs specifically contemplated by this Agreement or authorized by ICANN’s Bylaws. 

1.28 “Term of this Agreement” begins on the Effective Date and continues to the earlier of (a) the Expiration Date, or (b) termination of
this Agreement. 
 1.29 “Total Registered Names Under Management” means the total number of Registered Names sponsored by all Applicable
Registrars as reflected in the latest monthly reports submitted to ICANN by Registrars. 
 1.30 “Whois Accuracy Program Specification” means the
Whois Accuracy Program Specification attached hereto, as updated from time to time in accordance with this Agreement. 
 1.31 “Whois
Specification” means the Registration Data Directory Service (Whois) Specification attached hereto, as updated from time to time in accordance with this Agreement. 

1.32 “Working Group” means representatives of the Applicable Registrars and other members of the community that the Registrar Stakeholder Group
appoints, from time to time, to serve as a working group to consult on amendments to the Applicable Registrar Agreements (excluding bilateral amendments pursuant to Section 6.9). 

2. ICANN OBLIGATIONS. 
 2.1 Accreditation.
During the Term of this Agreement and subject to the terms and conditions of this Agreement, Registrar is hereby Accredited by ICANN to act as a registrar (including to insert and renew registration of Registered Names in the Registry Database) for
gTLDs. 
 2.2 Registrar Use of ICANN Name, Website and Trademarks. ICANN hereby grants to Registrar a non-exclusive, worldwide, royalty-free license
during the Term of this Agreement (a) to state that it is Accredited by ICANN as a registrar for gTLDs, and (b) to link to pages and documents within the ICANN web site. Subject to the terms and conditions set forth in the Logo License
Specification attached hereto, ICANN hereby grants to Registrar a non-exclusive, worldwide right and license to use the Trademarks defined in the Logo License Specification). No other use of ICANN’s name, website or Trademarks is licensed
hereby. This license may not be assigned or sublicensed by Registrar to any other party, including, without limitation, any Affiliate of Registrar or any Reseller. 

2.3 General Obligations of ICANN. With respect to all matters that impact the rights, obligations, or role of Registrar, ICANN shall during the Term of
this Agreement: 
 2.3.1 exercise its responsibilities in an open and transparent manner; 

  
 4 

 2.3.2 not unreasonably restrain competition and, to the extent feasible, promote and encourage
robust competition; 
 2.3.3 not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and not single
out Registrar for disparate treatment unless justified by substantial and reasonable cause; and 
 2.3.4 ensure, through its reconsideration
and independent review policies, adequate appeal procedures for Registrar, to the extent it is adversely affected by ICANN standards, policies, procedures or practices. 

2.4 Use of ICANN Accredited Registrars. In order to promote competition in the registration of domain names, and in recognition of the value that
ICANN-Accredited registrars bring to the Internet community, ICANN has ordinarily required gTLD registries under contract with ICANN to use ICANN-Accredited registrars, and ICANN will during the course of this agreement abide by any ICANN adopted
Specifications or Policies requiring the use of ICANN-Accredited registrars by gTLD registries. 
 3. REGISTRAR OBLIGATIONS. 

3.1 Obligations to Provide Registrar Services. During the Term of this Agreement, Registrar agrees that it will operate as a registrar for one or more
gTLDs in accordance with this Agreement. 
 3.2 Submission of Registered Name Holder Data to Registry. During the Term of this Agreement: 

3.2.1 As part of its registration of Registered Names in a gTLD, Registrar shall submit to, or shall place in the Registry Database operated
by, the Registry Operator for the gTLD the following data elements: 
 3.2.1.1 The name of the Registered Name being registered; 

3.2.1.2 The IP addresses of the primary nameserver and secondary nameserver(s) for the Registered Name; 

3.2.1.3 The corresponding names of those nameservers; 

3.2.1.4 Unless automatically generated by the registry system, the identity of the Registrar; 

3.2.1.5 Unless automatically generated by the registry system, the expiration date of the registration; and 

3.2.1.6 Any other data the Registry Operator requires be submitted to it. 

The agreement between the Registry Operator of a gTLD and Registrar may, if approved by ICANN in writing, state alternative required data
elements applicable 

  
 5 

 
to that gTLD, in which event, the alternative required data elements shall replace and supersede Subsections 3.2.1.1 through 3.2.1.6 stated above for all purposes under this Agreement but only
with respect to that particular gTLD. When seeking approval for alternative required data elements, the data elements set forth in Subsections 3.2.1.1 through 3.2.1.6 should be considered suggested minimum requirements. 

3.2.2 Within seven (7) days after receiving any updates from the Registered Name Holder to the data elements listed in Subsections
3.2.1.2, 3.1.2.3, and 3.2.1.6 for any Registered Name that Registrar sponsors, Registrar shall submit the updated data elements to, or shall place those elements in the Registry Database operated by, the relevant Registry Operator. 

3.2.3 In order to allow reconstitution of the Registry Database in the event of an otherwise unrecoverable technical failure or a change in the
designated Registry Operator, within ten (10) days of any such request by ICANN, Registrar shall submit an electronic database containing the data elements listed in Subsections 3.2.1.1 through 3.2.1.6 for all active records in the registry
sponsored by Registrar, in a format specified by ICANN, to the Registry Operator for the appropriate gTLD. 
 3.3 Public Access to Data on Registered
Names. During the Term of this Agreement: 
 3.3.1 At its expense, Registrar shall provide an interactive web page and, with respect to
any gTLD operating a “thin” registry, a port 43 Whois service (each accessible via both IPv4 and IPv6) providing free public query-based access to up-to-date (i.e., updated at least daily) data concerning all active Registered Names
sponsored by Registrar in any gTLD. Until otherwise specified by a Consensus Policy, such data shall consist of the following elements as contained in Registrar’s database: 

3.3.1.1 The name of the Registered Name; 

3.3.1.2 The names of the primary nameserver and secondary nameserver(s) for the Registered Name; 

3.3.1.3 The identity of Registrar (which may be provided through Registrar’s website); 

3.3.1.4 The original creation date of the registration; 

3.3.1.5 The expiration date of the registration; 

3.3.1.6 The name and postal address of the Registered Name Holder; 

3.3.1.7 The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the
Registered Name; and 

  
 6 

 3.3.1.8 The name, postal address, e-mail address, voice telephone number, and (where available)
fax number of the administrative contact for the Registered Name. 
 The agreement between the Registry Operator of a gTLD and Registrar may,
if approved by ICANN in writing, state alternative required data elements applicable to that gTLD, in which event the alternative required data elements shall replace and supersede Subsections 3.3.1.1 through 3.3.1.8 stated above for all purposes
under this Agreement but only with respect to that particular gTLD. 
 3.3.2 Upon receiving any updates to the data elements listed in
Subsections 3.3.1.2, 3.3.1.3, and 3.3.1.5 through 3.3.1.8 from the Registered Name Holder, Registrar shall promptly update its database used to provide the public access described in Subsection 3.3.1. 

3.3.3 Registrar may subcontract its obligation to provide the public access described in Subsection 3.3.1 and the updating described in
Subsection 3.3.2, provided that Registrar shall remain fully responsible for the proper provision of the access and updating. 
 3.3.4
Registrar shall abide by any Consensus Policy that requires registrars to cooperatively implement a distributed capability that provides query-based Whois search functionality across all registrars. If the Whois service implemented by registrars
does not in a reasonable time provide reasonably robust, reliable, and convenient access to accurate and up-to-date data, the Registrar shall abide by any Consensus Policy requiring Registrar, if reasonably determined by ICANN to be necessary
(considering such possibilities as remedial action by specific registrars), to supply data from Registrar’s database to facilitate the development of a centralized Whois database for the purpose of providing comprehensive Registrar Whois search
capability. 
 3.3.5 In providing query-based public access to registration data as required by Subsections 3.3.1 and 3.3.4, Registrar shall
not impose terms and conditions on use of the data provided, except as permitted by any Specification or Policy established by ICANN. Unless and until ICANN establishes a different Consensus Policy, Registrar shall permit use of data it provides in
response to queries for any lawful purposes except to: (a) allow, enable, or otherwise support the transmission by email, telephone, postal mail, facsimile or other means of mass unsolicited, commercial advertising or solicitations to entities
other than the data recipient’s own existing customers; or (b) enable high volume, automated, electronic processes that send queries or data to the systems of any Registry Operator or ICANN-Accredited registrar, except as reasonably
necessary to register domain names or modify existing registrations. 
 3.3.6 In the event that ICANN determines, following analysis of
economic data by an economists) retained by ICANN (which data has been made available to 

  
 7 

 
Registrar), that an individual or entity is able to exercise market power with respect to registrations or with respect to registration data used for development of value-added products and
services by third parties, Registrar shall provide third-party bulk access to the data subject to public access under Subsection 3.3.1 under the following terms and conditions: 

3.3.6.1 Registrar shall make a complete electronic copy of the data available at least one (1) time per week for download by third parties
who have entered into a bulk access agreement with Registrar. 
 3.3.6.2 Registrar may charge an annual fee, not to exceed US$10,000, for
such bulk access to the data. 
 3.3.6.3 Registrar’s access agreement shall require the third party to agree not to use the data to
allow, enable, or otherwise support any marketing activities, regardless of the medium used. Such media include but are not limited to e-mail, telephone, facsimile, postal mail, SMS, and wireless alerts. 

3.3.6.4 Registrar’s access agreement shall require the third party to agree not to use the data to enable high-volume, automated,
electronic processes that send queries or data to the systems of any Registry Operator or ICANN-Accredited registrar, except as reasonably necessary to register domain names or modify existing registrations. 

3.3.6.5 Registrar’s access agreement must require the third party to agree not to sell or redistribute the data except insofar as it has
been incorporated by the third party into a value-added product or service that does not permit the extraction of a substantial portion of the bulk data from the value-added product or service for use by other parties. 

3.3.7 To comply with applicable statutes and regulations and for other reasons, ICANN may adopt a Consensus Policy establishing limits
(a) on the Personal Data concerning Registered Names that Registrar may make available to the public through a public-access service described in this Subsection 3.3 and (b) on the manner in which Registrar may make such data available.
Registrar shall comply with any such Consensus Policy. 
 3.3.8 Registrar shall meet or exceed the requirements set forth in the Whois
Specification. 
 3.4 Retention of Registered Name Holder and Registration Data. 

3.4.1 For each Registered Name sponsored by Registrar within a gTLD, Registrar shall collect and securely maintain, in its own electronic
database, as updated from time to time: 

  
 8 

 3.4.1.1 the data specified in the Data Retention Specification attached hereto for the period
specified therein; 
 3.4.1.2 The data elements listed in Subsections 3.3.1.1 through 3.3.1.8; 

3.4.1.3 the name and (where available) postal address, e-mail address, voice telephone number, and fax number of the billing contact; 

3.4.1.4 any other Registry Data that Registrar has submitted to the Registry Operator or placed in the Registry Database under Subsection 3.2;
and 
 3.4.1.5 the name, postal address, e-mail address, and voice telephone number provided by the customer of any privacy service or
licensee of any proxy registration service, in each case, offered or made available by Registrar or its Affiliates in connection with each registration. Effective on the date that ICANN fully implements a Proxy Accreditation Program established in
accordance with Section 3.14, the obligations under this Section 3.4.1.5 will cease to apply as to any specific category of data (such as postal address) that is expressly required to be retained by another party in accordance with such
Proxy Accreditation Program. 
 3.4.2 During the Term of this Agreement and for two (2) years thereafter, Registrar (itself or by its
agent(s)) shall maintain the following records relating to its dealings with the Registry Operator(s) and Registered Name Holders: 
 3.4.2.1
In electronic form, the submission date and time, and the content, of all registration data (including updates) submitted in electronic form to the Registry Operator(s); 

3.4.2.2 In electronic, paper, or microfilm form, all written communications constituting registration applications, confirmations,
modifications, or terminations and related correspondence with Registered Name Holders, including registration contracts; and 
 3.4.2.3 In
electronic form, records of the accounts of all Registered Name Holders with Registrar. 
 3.4.3 During the Term of this Agreement and for
two (2) years thereafter, Registrar shall make the data, information and records specified in this Section 3.4 available for inspection and copying by ICANN upon reasonable notice. In addition, upon reasonable notice and request from
ICANN, Registrar shall deliver copies of such data, information and records to ICANN in respect to limited transactions or circumstances that may be the subject of a compliance-related inquiry; provided, however, that such obligation shall not apply
to requests for copies of the Registrar’s entire database or transaction history. Such copies are to be provided at Registrar’s expense. In responding to ICANN’s request for delivery of electronic data, information and records,
Registrar may submit such information in a format 

  
 9 

 
reasonably convenient to Registrar and acceptable to ICANN so as to minimize disruption to the Registrar’s business. In the event Registrar believes that the provision of any such data,
information or records to ICANN would violate applicable law or any legal proceedings, ICANN and Registrar agree to discuss in good faith whether appropriate limitations, protections, or alternative solutions can be identified to allow the
production of such data, information or records in complete or redacted form, as appropriate. ICANN shall not disclose the content of such data, information or records except as expressly required by applicable law, any legal proceeding or
Specification or Policy. 
 3.4.4 Notwithstanding any other requirement in this Agreement or the Data Retention Specification, Registrar
shall not be obligated to maintain records relating to a domain registration beginning on the date two (2) years following the domain registration’s deletion or transfer away to a different registrar. 

3.5 Rights in Data. Registrar disclaims all rights to exclusive ownership or use of the data elements listed in Subsections 3.2.1.1 through 3.2.1.3 for
all Registered Names submitted by Registrar to the Registry Database for, or sponsored by Registrar in, each gTLD for which it is Accredited. Registrar does not disclaim rights in the data elements listed in Subsections 3.2.1.4 through 3.2.1.6 and
Subsections 3.3.1.3 through 3.3.1.8 concerning active Registered Names sponsored by it in each gTLD for which it is Accredited, and agrees to grant non-exclusive, irrevocable, royalty-free licenses to make use of and disclose the data elements
listed in Subsections 3.2.1.4 through 3.2.1.6 and 3.3.1.3 through 3.3.1.8 for the purpose of providing a service or services (such as a Whois service under Subsection 3.3.4) providing interactive, query-based public access. Upon a change in
sponsorship from Registrar of any Registered Name in each gTLD for which it is Accredited, Registrar acknowledges that the registrar gaining sponsorship shall have the rights of an owner to the data elements listed in Subsections 3.2.1.4 through
3.2.1.6 and 3.3.1.3 through 3.3.1.8 concerning that Registered Name, with Registrar also retaining the rights of an owner in that data. Nothing in this Subsection prohibits Registrar from (1) restricting bulk public access to data elements in a
manner consistent with this Agreement and any Specifications or Policies or (2) transferring rights it claims in data elements subject to the provisions of this Subsection 3.5. 

3.6 Data Escrow. During the Term of this Agreement, on a schedule, under the terms, and in the format specified by ICANN, Registrar shall submit an
electronic copy of the data described in Subsections 3.4.1.2 through 3.4.1.5 to ICANN or, at Registrar’s election and at its expense, to a reputable escrow agent mutually approved by Registrar and ICANN, such approval also not to be
unreasonably withheld by either party. The data shall be held under an agreement among Registrar, ICANN, and the escrow agent (if any) providing that (1) the data shall be received and held in escrow, with no use other than verification that
the deposited data is complete, consistent, and in proper format, until released to ICANN; (2) the data shall be released from escrow upon expiration without renewal or termination of this Agreement; and (3) ICANN’s rights under the
escrow agreement shall be assigned with any assignment of this Agreement. The escrow shall provide that in the event the escrow is released under this Subsection, ICANN (or its assignee) shall have a non-exclusive,

  
 10 

 
irrevocable, royalty-free license to exercise (only for transitional purposes) or have exercised all rights necessary to provide Registrar Services. 

3.7 Business Dealings, Including with Registered Name Holders. 

3.7.1 In the event ICANN adopts a Specification or Policy that is supported by a consensus of ICANN-Accredited registrars as reflected in the
Registrar Stakeholder Group (or any successor group), establishing or approving a Code of Conduct for ICANN-Accredited registrars, Registrar shall abide by that Code of Conduct. 

3.7.2 Registrar shall abide by applicable laws and governmental regulations. 

3.7.3 Registrar shall not represent to any actual or potential Registered Name Holder that Registrar enjoys access to a registry for which
Registrar is Accredited that is superior to that of any other registrar Accredited for that registry. 
 3.7.4 Registrar shall not activate
any Registered Name unless and until it is satisfied that it has received a reasonable assurance of payment of its registration fee. For this purpose, a charge to a credit card, general commercial terms extended to creditworthy customers, or other
mechanism providing a similar level of assurance of payment shall be sufficient, provided that the obligation to pay becomes final and non-revocable by the Registered Name Holder upon activation of the registration. 

3.7.5 At the conclusion of the registration period, failure by or on behalf of the Registered Name Holder to consent that the registration be
renewed within the time specified in a second notice or reminder shall, in the absence of extenuating circumstances, result in cancellation of the registration by the end of the auto-renew grace period (although Registrar may choose to cancel the
name earlier). 
 3.7.5.1 Extenuating circumstances are defined as: UDRP action, valid court order, failure of a Registrar’s renewal
process (which does not include failure of a registrant to respond), the domain name is used by a nameserver that provides DNS service to third-parties (additional time may be required to migrate the records managed by the nameserver), the
registrant is subject to bankruptcy proceedings, payment dispute (where a registrant claims to have paid for a renewal, or a discrepancy in the amount paid), billing dispute (where a registrant disputes the amount on a bill), domain name subject to
litigation in a court of competent jurisdiction, or other circumstance as approved specifically by ICANN. 
 3.7.5.2 Where Registrar chooses,
under extenuating circumstances, to renew a domain name without the explicit consent of the registrant, the registrar must maintain a record of the extenuating circumstances associated with renewing that specific domain name for inspection by ICANN
consistent with clauses 3.4.2 and 3.4.3 of this registrar accreditation agreement. 

  
 11 

 3.7.5.3 In the absence of extenuating circumstances (as defined in Section 3.7.5.1 above), a
domain name must be deleted within 45 days of either the registrar or the registrant terminating a registration agreement. 
 3.7.5.4
Registrar shall provide notice to each new registrant describing the details of their deletion and auto-renewal policy including the expected time at which a non-renewed domain name would be deleted relative to the domain’s expiration date, or
a date range not to exceed ten (10) days in length. If a registrar makes any material changes to its deletion policy during the period of the registration agreement, it must make at least the same effort to inform the registrant of the changes
as it would to inform the registrant of other material changes to the registration agreement (as defined in clause 3.7.7 of the registrars accreditation agreement). 

3.7.5.5 If Registrar operates a website for domain name registration or renewal, details of Registrar’s deletion and auto-renewal policies
must be clearly displayed on the website. 
 3.7.5.6 If Registrar operates a website for domain registration or renewal, it should state,
both at the time of registration and in a clear place on its website, any fee charged for the recovery of a domain name during the Redemption Grace Period. 

3.7.5.7 In the event that a domain which is the subject of a UDRP dispute is deleted or expires during the course of the dispute, the
complainant in the UDRP dispute will have the option to renew or restore the name under the same commercial terms as the registrant. If the complainant renews or restores the name, the name will be placed in Registrar HOLD and Registrar LOCK status,
the WHOIS contact information for the registrant will be removed, and the WHOIS entry will indicate that the name is subject to dispute. If the complaint is terminated, or the UDRP dispute finds against the complainant, the name will be deleted
within 45 days. The registrant retains the right under the existing redemption grace period provisions to recover the name at any time during the Redemption Grace Period, and retains the right to renew the name before it is deleted. 

3.7.6 Registrar shall not insert or renew any Registered Name in any gTLD registry in a manner contrary to (i) any Consensus Policy
stating a list or specification of excluded Registered Names that is in effect at the time of insertion or renewal, or (ii) any list of names to be reserved from registration as required by the specific Registry Operator for which the Registrar
is providing Registrar Services. 
 3.7.7 Registrar shall require all Registered Name Holders to enter into an electronic or paper
registration agreement with Registrar including at least the provisions set forth in Subsections 3.7.7.1 through 3.7.7.12, and which agreement shall otherwise set forth the terms and conditions applicable to the registration of a

  
 12 

 
domain name sponsored by Registrar. The Registered Name Holder with whom Registrar enters into a registration agreement must be a person or legal entity other than the Registrar, provided that
Registrar may be the Registered Name Holder for domains registered for the purpose of conducting its Registrar Services, in which case the Registrar shall submit to the provisions set forth in Subsections 3.7.7.1 through 3.7.7.12 and shall be
responsible to ICANN for compliance with all obligations of the Registered Name Holder as set forth in this Agreement and Specifications and Policies. Registrar shall use commercially reasonable efforts to enforce compliance with the provisions of
the registration agreement between Registrar and any Registered Name Holder that relate to implementing the requirements of Subsections 3.7.7.1 through 3.7.7.12 or any Consensus Policy. 

3.7.7.1 The Registered Name Holder shall provide to Registrar accurate and reliable contact details and correct and update them within seven
(7) days of any change during the term of the Registered Name registration, including: the full name, postal address, e-mail address, voice telephone number, and fax number if available of the Registered Name Holder; name of authorized person
for contact purposes in the case of an Registered Name holder that is an organization, association, or corporation; and the data elements listed in Subsections 3.3.1.2, 3.3.1.7 and 3.3.1.8. 

3.7.7.2 A Registered Name Holder’s willful provision of inaccurate or unreliable information, its willful failure to update information
provided to Registrar within seven (7) days of any change, or its failure to respond for over fifteen (15) days to inquiries by Registrar concerning the accuracy of contact details associated with the Registered Name Holder’s
registration shall constitute a material breach of the Registered Name Holder-registrar contract and be a basis for suspension and/or cancellation of the Registered Name registration. 

3.7.7.3 Any Registered Name Holder that intends to license use of a domain name to a third party is nonetheless the Registered Name Holder of
record and is responsible for providing its own full contact information and for providing and updating accurate technical and administrative contact information adequate to facilitate timely resolution of any problems that arise in connection with
the Registered Name. A Registered Name Holder licensing use of a Registered Name according to this provision shall accept liability for harm caused by wrongful use of the Registered Name, unless it discloses the current contact information provided
by the licensee and the identity of the licensee within seven (7) days to a party providing the Registered Name Holder reasonable evidence of actionable harm. 

3.7.7.4 Registrar shall provide notice to each new or renewed Registered Name Holder stating: 

  
 13 

 3.7.7.4.1 The purposes for which any Personal Data collected from the applicant are intended;

 3.7.7.4.2 The intended recipients or categories of recipients of the data (including the Registry Operator and others who will receive
the data from Registry Operator); 
 3.7.7.4.3 Which data are obligatory and which data, if any, are voluntary; and 

3.7.7.4.4 How the Registered Name Holder or data subject can access and, if necessary, rectify the data held about them. 

3.7.7.5 The Registered Name Holder shall consent to the data processing referred to in Subsection 3.7.7.4. 

3.7.7.6 The Registered Name Holder shall represent that notice has been provided equivalent to that described in Subsection 3.7.7.4 to any
third-party individuals whose Personal Data are supplied to Registrar by the Registered Name Holder, and that the Registered Name Holder has obtained consent equivalent to that referred to in Subsection 3.7.7.5 of any such third-party individuals.

 3.7.7.7 Registrar shall agree that it will not process the Personal Data collected from the Registered Name Holder in a way incompatible
with the purposes and other limitations about which it has provided notice to the Registered Name Holder in accordance with Subsection 3.7.7.4 above. 

3.7.7.8 Registrar shall agree that it will take reasonable precautions to protect Personal Data from loss, misuse, unauthorized access or
disclosure, alteration, or destruction. 
 3.7.7.9 The Registered Name Holder shall represent that, to the best of the Registered Name
Holder’s knowledge and belief, neither the registration of the Registered Name nor the manner in which it is directly or indirectly used infringes the legal rights of any third party. 

3.7.7.10 For the adjudication of disputes concerning or arising from use of the Registered Name, the Registered Name Holder shall submit,
without prejudice to other potentially applicable jurisdictions, to the jurisdiction of the courts (1) of the Registered Name Holder’s domicile and (2) where Registrar is located. 

3.7.7.11 The Registered Name Holder shall agree that its registration of the Registered Name shall be subject to suspension, cancellation, or
transfer pursuant to any Specification or Policy, or pursuant to any registrar or registry procedure not inconsistent with any Specification or Policy, (1) to 

  
 14 

 
correct mistakes by Registrar or the Registry Operator in registering the name or (2) for the resolution of disputes concerning the Registered Name. 

3.7.7.12 The Registered Name Holder shall indemnify and hold harmless the Registry Operator and its directors, officers, employees, and agents
from and against any and all claims, damages, liabilities, costs, and expenses (including reasonable legal fees and expenses) arising out of or related to the Registered Name Holder’s domain name registration. 

3.7.8 Registrar shall comply with the obligations specified in the Whois Accuracy Program Specification. In addition, notwithstanding anything
in the Whois Accuracy Program Specification to the contrary, Registrar shall abide by any Consensus Policy requiring reasonable and commercially practicable (a) verification, at the time of registration, of contact information associated with a
Registered Name sponsored by Registrar or (b) periodic re-verification of such information. Registrar shall, upon notification by any person of an inaccuracy in the contact information associated with a Registered Name sponsored by Registrar,
take reasonable steps to investigate that claimed inaccuracy. In the event Registrar learns of inaccurate contact information associated with a Registered Name it sponsors, it shall take reasonable steps to correct that inaccuracy. 

3.7.9 Registrar shall abide by any Consensus Policy prohibiting or restricting warehousing of or speculation in domain names by registrars.

 3.7.10 Registrar shall publish on its website(s) and/or provide a link to the Registrants’ Benefits and Responsibilities
Specification attached hereto and shall not take any action inconsistent with the corresponding provisions of this Agreement or applicable law. 

3.7.11 Registrar shall make available a description of the customer service handling processes available to Registered Name Holders regarding
Registrar Services, including a description of the processes for submitting complaints and resolving disputes regarding the Registrar Services. 

3.7.12 Nothing in this Agreement prescribes or limits the amount Registrar may charge Registered Name Holders for registration of Registered
Names. 
 3.8 Domain-Name Dispute Resolution. During the Term of this Agreement, Registrar shall have in place a policy and procedures for resolution
of disputes concerning Registered Names. Until ICANN adopts an alternative Consensus Policy or other Specification or Policy with respect to the resolution of disputes concerning Registered Names, Registrar shall comply with the Uniform Domain Name
Dispute Resolution Policy (“UDRP”) identified on ICANN’s website (www.icann.org/general/consensus-policies.htm), as may be modified from time to time. Registrar shall also comply with the Uniform Rapid Suspension (“URS”)
procedure or its replacement, as well as with any other applicable dispute resolution procedure as required by a Registry Operator for which Registrar is providing Registrar Services. 

  
 15 

 3.9 Accreditation Fees. As a condition of Accreditation, Registrar shall pay Accreditation fees to ICANN.
These fees consist of yearly and variable fees. 
 3.9.1 Registrar shall pay ICANN a yearly Accreditation fee in an amount established by the
ICANN Board of Directors, in conformity with ICANN’s bylaws and articles of incorporation. This yearly Accreditation fee shall not exceed US$4,000. Payment of the yearly fee shall be due within thirty (30) days after invoice from ICANN,
provided that Registrar may elect to pay the yearly fee in four (4) equal quarterly installments. 
 3.9.2 Registrar shall pay the
variable Accreditation fees established by the ICANN Board of Directors, in conformity with ICANN’s bylaws and articles of incorporation, provided that in each case such fees are reasonably allocated among all registrars that contract with
ICANN and that any such fees must be expressly approved by registrars accounting, in the aggregate, for payment of two-thirds of all registrar-level fees. Registrar shall pay such fees in a timely manner for so long as all material terms of this
Agreement remain in full force and effect, and notwithstanding the pendency of any dispute between Registrar and ICANN. 
 3.9.3 For any
payments thirty (30) days or more overdue, Registrar shall pay interest on late payments at the rate of 1.5% per month or, if less, the maximum rate permitted by applicable law from later of the date of the invoice or the date the invoice
is sent pursuant to Section 7.6 of this Agreement. On reasonable notice given by ICANN to Registrar, accountings submitted by Registrar shall be subject to verification by an audit of Registrar’s books and records by an independent
third-party designated by ICANN that shall preserve the confidentiality of such books and records (other than its findings as to the accuracy of, and any necessary corrections to, the accountings). 

3.9.4 The Accreditation fees due under this Agreement are exclusive of tax. All taxes, duties, fees and other governmental charges of any kind
(including sales, turnover, services, use and value-added taxes) that are imposed by or under the authority of any government or any political subdivision thereof on the Accreditation fees for any services, software and/or hardware shall be borne by
Registrar and shall not be considered a part of, a deduction from, or an offset against such Accreditation fees. All payments due to ICANN shall be made without any deduction or withholding on account of any tax, duty, charge, or penalty except as
required by applicable law, in which case, the sum payable by Registrar from which such deduction or withholding is to be made shall be increased to the extent necessary to ensure that, after making such deduction or withholding, ICANN receives
(free from any liability with respect thereof) a net sum equal to the sum it would have received but for such deduction or withholding being required. 

3.10 Insurance. Registrar shall maintain in force commercial general liability insurance or similar liability insurance as specified by ICANN with
policy limits of at least US$500,000 

  
 16 

 
covering liabilities arising from Registrar’s registrar business during the Term of this Agreement. 

3.11 Obligations of Registrars under common controlling interest. Registrar shall be in breach of this Agreement if: 

3.11.1 ICANN terminates an Affiliated Registrar’s accreditation agreement with ICANN (an “Affiliate Termination”); 

3.11.2 Affiliated Registrar has not initiated arbitration challenging ICANN’s right to terminate the Affiliated Registrar’s
accreditation agreement under Section 5.8 of this Agreement, or has initiated such arbitration and has not prevailed; 
 3.11.3 the
Affiliate Termination was the result of misconduct that materially harmed consumers or the public interest; 
 3.11.4 a second Affiliated
Registrar has pursued, after the Affiliate Termination, the same course of conduct that resulted in the Affiliate Termination; and 
 3.11.5
ICANN has provided Registrar with written notice that it intends to assert the provisions of this Section 3.11 with respect to Registrar, which notice shall identify in reasonable detail the factual basis for such assertion, and Registrar has
failed to cure the impugned conduct within fifteen (15) days of such notice. 
 3.12 Obligations Related to Provision of Registrar Services by Third
Parties. Registrar is responsible for the provision of Registrar Services for all Registered Names that Registrar sponsors being performed in compliance with this Agreement, regardless of whether the Registrar Services are provided by Registrar
or a third party, including a Reseller. Registrar must enter into written agreements with all of its Resellers that enable Registrar to comply with and perform all of its obligations under this Agreement. In addition, Registrar must ensure that:

 3.12.1 Its Resellers do not display the ICANN or ICANN-Accredited Registrar logo, or otherwise represent themselves as Accredited by
ICANN, unless they have written permission from ICANN to do so. 
 3.12.2 Any registration agreement used by reseller shall include all
registration agreement provisions and notices required by the ICANN Registrar Accreditation Agreement and any ICANN Consensus Policies, and shall identify the sponsoring registrar or provide a means for identifying the sponsoring registrar, such as
a link to the InterNIC Whois lookup service. 
 3.12.3 Its Resellers identify the sponsoring registrar upon inquiry from the customer. 

3.12.4 Its Resellers comply with any ICANN-adopted Specification or Policy that establishes a program for accreditation of individuals or
entities who provide proxy 

  
 17 

 
and privacy registration services (a “Proxy Accreditation Program”). Among other features, the Proxy Accreditation Program may require that: (i) proxy and privacy registration
services may only be provided in respect of domain name registrations by individuals or entities Accredited by ICANN pursuant to such Proxy Accreditation Program; and (ii) Registrar shall prohibit Resellers from knowingly accepting
registrations from any provider of proxy and privacy registration services that is not Accredited by ICANN pursuant the Proxy Accreditation Program. Until such time as the Proxy Accreditation Program is established, Registrar shall require Resellers
to comply with the Specification on Privacy and Proxy Registrations attached hereto. 
 3.12.5 Its Resellers’ customers are provided
with a link to an ICANN webpage detailing registrant educational information, as detailed in subsection 3.16 below. 
 3.12.6 In the event
Registrar learns that a Reseller is causing Registrar to be in breach of any of the provisions of this Agreement, Registrar shall take reasonable steps to enforce its agreement with such Reseller so as to cure and prevent further instances of
non-compliance. 
 3.12.7 Its Resellers shall publish on their website(s) and/or provide a link to the Registrants’ Benefits and
Responsibilities Specification attached hereto and shall not take any action inconsistent with the corresponding provisions of this Agreement or applicable law. 

Registrar shall use commercially reasonable efforts to enforce compliance with the provisions of the agreement between Registrar and any Reseller that relate
to the provisions of Registrar Services. 
 3.13 Registrar Training. Registrar’s primary contact as identified in Subsection 7.6 below or
designee (so long as the designee is employed by Registrar or an Affiliated Registrar) shall complete a training course covering registrar obligations under ICANN policies and agreements. The course will be provided by ICANN at no expense to
Registrar, and shall be available in an online format. 
 3.14 Obligations Related to Proxy and Privacy Services. Registrar agrees to comply with any
ICANN-adopted Specification or Policy that establishes a Proxy Accreditation Program. Registrar also agrees to reasonably cooperate with ICANN in the development of such program. Until such time as the Proxy Accreditation Program is established,
Registrar agrees to comply with the Specification on Privacy and Proxy Registrations attached hereto. 
 3.15 Registrar Self-Assessment and Audits.
Registrar shall complete and deliver to ICANN on a schedule and in the form specified by ICANN from time to time in consultation with registrars a Registrar self-assessment. Registrar shall complete and deliver to ICANN within twenty (20) days
following the end of each calendar year, in a form specified by ICANN a certificate executed by the president, chief executive officer, chief financial officer or chief operating officer (or their equivalents) of Registrar certifying compliance with
the terms and conditions of this Agreement. ICANN may from time to time (not to exceed twice 

  
 18 

 
per calendar year) conduct, or engage a third party to conduct on its behalf, contractual compliance audits to assess compliance by Registrar with the terms and conditions of this Agreement. Any
audits pursuant to this Section 3.15 shall be tailored to achieve the purpose of assessing compliance, and ICANN will (a) give reasonable advance notice of any such audit, which notice shall specify in reasonable detail the categories of
documents, data and other information requested by ICANN, and (b) use commercially reasonable efforts to conduct such audit in such a manner as to not unreasonably disrupt the operations of Registrar. As part of such audit and upon request by
ICANN, Registrar shall timely provide all responsive documents, data and any other information necessary to demonstrate Registrar’s compliance with this Agreement. Upon no less than ten (10) days notice (unless otherwise agreed to by
Registrar), ICANN may, as part of any contractual compliance audit, conduct site visits during regular business hours to assess compliance by Registrar with the terms and conditions of this Agreement. ICANN shall not disclose Registrar confidential
information gathered through such audits except as required by applicable law, legal proceedings, or as expressly permitted by any Specification or Policy (including ICANN’s Documentary Information Disclosure Policy, as such policy may be
amended from time to time); provided, however, that, except as required by applicable law or legal proceedings, ICANN shall not release any information that Registrar has marked as, or has otherwise designated in writing to ICANN as, a
“confidential trade secret,” “confidential commercial information” or “confidential financial information” of Registrar. If any applicable law, legal proceeding or Specification or Policy permits such disclosure, ICANN
will provide Registrar no less than fifteen (15) days notice of its intent to disclose such information, unless such notice is prohibited by law or legal proceeding. Such notice shall include to whom and in what manner ICANN plans to disclose
such information. 
 3.16 Link to Registrant Educational Information. ICANN has published an educational webpage summarizing the terms of the
Registrar Accreditation Agreement and related Consensus Policies (as of the date of this Agreement, located at: http://www.icann.org/en/registrars/registrant-rights-responsibilities-en.htm). Registrar shall provide a link to such webpage on
any website it may operate for domain name registration or renewal clearly displayed to its Registered Name Holders at least as clearly as its links to policies or notifications required to be displayed under ICANN Consensus Policies. ICANN may, in
consultation with registrars, update the content and/or URL for this website. 
 3.17 Registrar Contact, Business Organization and Officer
Information. Registrar shall provide to ICANN and maintain accurate and current information as specified in the Registrar Information Specification to this Agreement. In addition, Registrar shall publish on each website through which Registrar
provides or offers Registrar Services the information specified as requiring such publication in the Registrar Information Specification. Registrar shall notify ICANN within five (5) days of any changes to such information and update
Registrar’s website(s) within twenty (20) days of any such changes. 
 3.18 Registrar’s Abuse Contact and Duty to Investigate Reports of
Abuse. 

  
 19 

 3.18.1 Registrar shall maintain an abuse contact to receive reports of abuse involving Registered
Names sponsored by Registrar, including reports of Illegal Activity. Registrar shall publish an email address to receive such reports on the home page of Registrar’s website (or in another standardized place that may be designated by ICANN from
time to time). Registrar shall take reasonable and prompt steps to investigate and respond appropriately to any reports of abuse. 
 3.18.2
Registrar shall establish and maintain a dedicated abuse point of contact, including a dedicated email address and telephone number that is monitored 24 hours a day, seven days a week, to receive reports of Illegal Activity by law enforcement,
consumer protection, quasi-governmental or other similar authorities designated from time to time by the national or territorial government of the jurisdiction in which the Registrar is established or maintains a physical office. Well-founded
reports of Illegal Activity submitted to these contacts must be reviewed within 24 hours by an individual who is empowered by Registrar to take necessary and appropriate actions in response to the report. In responding to any such reports, Registrar
will not be required to take any action in contravention of applicable law. 
 3.18.3 Registrar shall publish on its website a description of
its procedures for the receipt, handling, and tracking of abuse reports. Registrar shall document its receipt of and response to all such reports. Registrar shall maintain the records related to such reports for the shorter of two (2) years or
the longest period permitted by applicable law, and during such period, shall provide such records to ICANN upon reasonable notice. 
 3.19 Additional
Technical Specifications to Implement IPV6, DNSSEC and IDNs. Registrar shall comply with the Additional Registrar Operations Specification attached hereto. 

3.20 Notice of Bankruptcy, Convictions and Security Breaches. Registrar will give ICANN notice within seven (7) days of (i) the commencement
of any of the proceedings referenced in Section 5.5.8. (ii) the occurrence of any of the matters specified in Section 5.5.2 or Section 5.5.3 or (iii) any unauthorized access to or disclosure of registrant account information
or registration data. The notice required pursuant to Subsection (iii) shall include a detailed description of the type of unauthorized access, how it occurred, the number of registrants affected, and any action taken by Registrar in response.

 3.21 Obligations of Registrars Affiliated with Registry Operators. In the event Registrar is Affiliated with any Registry Operator or back-end
registry operator (an “Affiliated Relationship”) during the Term of this Agreement, Registrar shall comply with all ICANN Specifications and Policies that may be developed from time to time with respect to such Affiliated Relationships,
and will notify ICANN within thirty (30) days of the occurrence of the event that created the Affiliate relationship (e.g., the closing of any merger, acquisition or other transaction, or the execution of any agreement, in each case, giving
rise to such Affiliated Relationship). 

  
 20 

 3.22 Cooperation with Emergency Registry Service Providers. In the event that ICANN transitions the
operation of a registry for a gTLD in which Registrar sponsors Registered Names to an emergency registry service provider, Registrar shall cooperate in all reasonable respects with such emergency registry service provider, including by entering into
a registry-registrar agreement with such provider necessary to effect the transition and by providing all Registered Name Holder data reasonably requested by such emergency operator for the purpose of facilitating an efficient transition of the
registry for the gTLD. 
 4. PROCEDURES FOR ESTABLISHMENT OR REVISION OF SPECIFICATIONS AND POLICIES. 

4.1 Compliance with Consensus Policies and Temporary Policies. During the Term of this Agreement, Registrar shall comply with and implement all
Consensus Policies and Temporary Policies in existence as of the Effective Date found at http://www.icann.org/general/consensus-policies.htm, and as may in the future be developed and adopted in accordance with the ICANN Bylaws, provided such
future Consensus Policies and Temporary Policies are adopted in accordance with the procedures and relate to those topics and subject to those limitations set forth in the Consensus Policies and Temporary Policies Specification to this Agreement.

 5. TERM, TERMINATION AND DISPUTE RESOLUTION. 

5.1 Term of Agreement. This Agreement shall be effective on the Effective Date and shall have an initial term running until the Expiration Date, unless
sooner terminated. 
 5.2 Renewal. This Agreement and Registrar’s Accreditation will be renewed for successive periods of five (5) years
upon the Expiration Date and the expiration of each successive five-year term thereafter under the terms and conditions of this Agreement, unless: 

5.2.1 at the time of such renewal, Registrar no longer meets the ICANN registrar Accreditation criteria then in effect; 

5.2.2 Registrar is not in compliance with its obligations under this Agreement at the time of the Expiration Date or at the expiration of any
successive five (5) year term thereafter; 
 5.2.3 Registrar has been given notice by ICANN of three (3) or more material breaches
of this Agreement within the two (2) years preceding the Expiration Date or the date of expiration of any successive five (5) year term thereafter; or 

5.2.4 this Agreement has terminated prior to the Expiration Date or the expiration date of any successive five (5) year term thereafter.

 In the event Registrar intends to renew this Agreement pursuant to this Section 5.2, Registrar shall provide ICANN written notice thereof during the
period that is no more than 

  
 21 

 
ninety (90) days and no less than sixty (60) days prior to the Expiration Date and each successive five (5) year term thereafter. The provision of such notice shall not be a
condition to renewal hereunder. Pursuant to its customary practices (as may be modified by ICANN), ICANN will provide notice to Registrar of the Expiration Date and the date of expiration of any subsequent term hereunder. 

5.3 Right to Substitute Updated Agreement. In the event that, during the Term of this Agreement, ICANN adopts a revised form Registrar accreditation
agreement (the “Updated RAA”), Registrar (provided it has not received (i) a notice of breach that it has not cured or (ii) a notice of termination or suspension of this Agreement under this Section 5) may elect, by giving
ICANN written notice, to enter into the Updated RAA. In the event of such election, Registrar and ICANN shall as soon as practicable enter into the Updated RAA for the term specified in the Updated RAA, and this Agreement will be deemed terminated.

 5.4 Termination of Agreement by Registrar. This Agreement may be terminated before its expiration by Registrar by giving ICANN thirty
(30) days written notice. Upon such termination by Registrar, Registrar shall not be entitled to any refund of fees paid to ICANN pursuant to this Agreement 

5.5 Termination of Agreement by ICANN. This Agreement may be terminated before its expiration by ICANN in any of the following circumstances: 

5.5.1 There was a material misrepresentation, material inaccuracy, or materially misleading statement in Registrar’s application for
Accreditation or renewal of Accreditation or any material accompanying the application. 
 5.5.2 Registrar: 

5.5.2.1 is convicted by a court of competent jurisdiction of a felony or other serious offense related to financial activities, or is judged by
a court of competent jurisdiction to have: 
 5.5.2.1.1 committed fraud, 

5.5.2.1.2 committed a breach of fiduciary duty, or 

5.5.2.1.3 with actual knowledge (or through gross negligence) permitted Illegal Activity in the registration or use of domain names or in the
provision to Registrar by any Registered Name Holder of inaccurate Whois information; or 
 5.5.2.1.4 failed to comply with the terms of an
order issued by a court of competent jurisdiction relating to the use of domain names sponsored by the Registrar; 
 or is the subject of a
judicial determination that ICANN reasonably deems as the substantive equivalent of any of the foregoing; or 

  
 22 

 5.5.2.2 is disciplined by the government of its domicile for conduct involving dishonesty or
misuse of funds of others; or 
 5.5.2.3 is the subject of a non-interlocutory order issued by a court or arbitral tribunal, in each case of
competent jurisdiction, finding that Registrar has, directly or through an Affiliate, committed a specific violation(s) of applicable national law or governmental regulation relating to cybersquatting or its equivalent; or 

5.5.2.4 is found by ICANN, based on its review of the findings of arbitral tribunals, to have been engaged, either directly or through its
Affiliate, in a pattern and practice of trafficking in or use of domain names identical or confusingly similar to a trademark or service mark of a third party in which the Registered Name Holder has no rights or legitimate interest, which trademarks
have been registered and are being used in bad faith. 
 5.5.3 Registrar knowingly employs any officer that is convicted of a misdemeanor
related to financial activities or of any felony, or is judged by a court of competent jurisdiction to have committed fraud or breach of fiduciary duty, or is the subject of a judicial determination that ICANN reasonably deems as the substantive
equivalent of any of the foregoing and such officer is not terminated within thirty (30) days of Registrar’s knowledge of the foregoing; or any member of Registrar’s board of directors or similar governing body is convicted of a
misdemeanor related to financial activities or of any felony, or is judged by a court of competent jurisdiction to have committed fraud or breach of fiduciary duty, or is the subject of a judicial determination that ICANN reasonably deems as the
substantive equivalent of any of the foregoing and such member is not removed from Registrar’s board of directors or similar governing body within thirty (30) days of Registrar’s knowledge of the foregoing. 

5.5.4 Registrar fails to cure any breach of this Agreement within twenty-one (21) days after ICANN gives Registrar notice of the breach.

 5.5.5 Registrar fails to comply with a ruling granting specific performance under Sections 5.7 or 7.1. 

5.5.6 Registrar has been in fundamental and material breach of its obligations under this Agreement at least three (3) times within a
twelve (12) month period. 
 5.5.7 Registrar continues acting in a manner that ICANN has reasonably determined endangers the stability
or operational integrity of the Internet after receiving three (3) days notice of that determination. 
 5.5.8 (i) Registrar makes
an assignment for the benefit of creditors or similar act; (ii) attachment, garnishment or similar proceedings are commenced against Registrar, which proceedings are a material threat to Registrar’s ability to provide Registrar Services
for gTLDs, and are not dismissed within sixty (60) days of their 

  
 23 

 
commencement; (iii) a trustee, receiver, liquidator or equivalent is appointed in place of Registrar or maintains control over any of Registrar’s property; (iv) execution is levied
upon any property of Registrar, (v) proceedings are instituted by or against Registrar under any bankruptcy, insolvency, reorganization or other laws relating to the relief of debtors and such proceedings are not dismissed within thirty
(30) days of their commencement, or (vi) Registrar files for protection under the United States Bankruptcy Code, 11 U.S.C. Section 101 et seq., or a foreign equivalent or liquidates, dissolves or otherwise discontinues its operations.

 5.6 Termination Procedures. This Agreement may be terminated in circumstances described in Subsections 5.5.1 though 5.5.6 above only upon fifteen
(15) days written notice to Registrar (in the case of Subsection 5.5.4 occurring after Registrar’s failure to cure), with Registrar being given an opportunity during that time to initiate arbitration under Subsection 5.8 to determine the
appropriateness of termination under this Agreement. This Agreement may be terminated immediately upon notice to Registrar in circumstances described in Subsections 5.5.7 and 5.5.8. 

5.7 Suspension. 
 5.7.1 Upon the
occurrence of any of the circumstances set forth in Section 5.5, ICANN may, in ICANN’s sole discretion, upon delivery of a notice pursuant to Subsection 5.7.2, elect to suspend Registrar’s ability to create or sponsor new Registered
Names or initiate inbound transfers of Registered Names for any or all gTLDs for a period of up to a twelve (12) months following the effectiveness of such suspension. Suspension of a Registrar does not preclude ICANN’s ability to issue a
notice of termination in accordance with the notice requirements of Section 5.6. 
 5.7.2 Any suspension under Subsections 5.7.1 will be
effective upon fifteen (15) days written notice to Registrar, with Registrar being given an opportunity during that time to initiate arbitration under Subsection 5.8 to determine the appropriateness of suspension under this Agreement. 

5.7.3 Upon suspension, Registrar shall notify users, by posting a prominent notice on its web site, that it is unable to create or sponsor new
gTLD domain name registrations or initiate inbound transfers of Registered Names. Registrar’s notice shall include a link to the notice of suspension from ICANN. 

5.7.4 If Registrar acts in a manner that ICANN reasonably determines endangers the stability or operational integrity of the Internet and upon
notice does not immediately cure, ICANN may suspend this Agreement for five (5) working days pending ICANN’s application for more extended specific performance or injunctive relief under Subsection 7.1. Suspension of the Agreement under
this Subsection may, at ICANN’s sole discretion, preclude the Registrar from (i) providing Registration Services for gTLDs delegated by ICANN on or after the date of delivery of such notice to Registrar and (ii) creating or sponsoring
new Registered Names or 

  
 24 

 
initiating inbound transfers of Registered Names for any gTLDs. Registrar must also post the statement specified in Subsection 5.7.3. 

5.8 Resolution of Disputes Under this Agreement. Subject to the limitations set forth in Section 6 and Section 7.4, disputes arising under or
in connection with this Agreement, including (1) disputes arising from ICANN’s failure to renew Registrar’s Accreditation and (2) requests for specific performance, shall be resolved in a court of competent jurisdiction or, at
the election of either party, by an arbitration conducted as provided in this Subsection 5.8 pursuant to the International Arbitration Rules of the American Arbitration Association (“AAA”). The arbitration shall be conducted in English and
shall occur in Los Angeles County, California, USA. Except as set forth in Section 7.4.5, there shall be one (1) arbitrator agreed by the parties from a list of AAA arbitrators, or if parties do not agree on an arbitrator within fifteen
(15) days of the AAA request that the parties designate an arbitrator, the AAA shall choose and appoint an arbitrator, paying due regard to the arbitrator’s knowledge of the DNS. The parties shall bear the costs of the arbitration in equal
shares, subject to the right of the arbitrator to reallocate the costs in their award as provided in the AAA rules. The parties shall bear their own attorneys’ fees in connection with the arbitration, and the arbitrator may not reallocate the
attorneys’ fees in conjunction with their award. The arbitrator shall render its decision within ninety (90) days of the conclusion of the arbitration hearing. In the event Registrar initiates arbitration to contest the appropriateness of
termination of this Agreement by ICANN pursuant to Section 5.5 or suspension of Registrar by ICANN pursuant to Section 5.7.1, Registrar may at the same time request that the arbitration panel stay the termination or suspension until the
arbitration decision is rendered. The arbitration panel shall order a stay: (i) upon showing by Registrar that continued operations would not be harmful to consumers or the public interest, or (ii) upon appointment by the arbitration panel
of a qualified third party to manage the operations of the Registrar until the arbitration decision is rendered. In furtherance of sub-clause (ii) above, the arbitration panel is hereby granted all necessary authority to appoint a qualified
third-party to manage the operations of the Registrar upon the Registrar’s request and if the panel deems it appropriate. In selecting the third-party manager, the arbitration panel shall take into consideration, but shall not be bound by, any
expressed preferences of Registrar. Any order granting a request for a stay must be issued within fourteen (14) days after the filing of the arbitration. If an order granting a request for a stay is not issued within fourteen (14) days,
ICANN has the right to proceed with the termination of this Agreement pursuant to Section 5.5 or suspension of the Registrar pursuant to Section 5.7.1. In the event Registrar initiates arbitration to contest an Independent Review
Panel’s decision under Subsection 4.3.3 sustaining the ICANN Board of Director’s determination that a specification or policy is supported by consensus, Registrar may at the same time request that the arbitration panel stay the requirement
that it comply with the policy until the arbitration decision is rendered, and that request shall have the effect of staying the requirement until the decision or until the arbitration panel has granted an ICANN request for lifting of the stay. In
all litigation involving ICANN concerning this Agreement (whether in a case where arbitration has not been elected or to enforce an arbitration award), jurisdiction and exclusive venue for such litigation shall be in a court located in Los Angeles,
California, USA; however, the parties shall also have the right to enforce a judgment of such a court in any court of competent jurisdiction. For the 

  
 25 

 
purpose of aiding the arbitration and/or preserving the rights of the parties during the pendency of an arbitration, the parties shall have the right to seek temporary or preliminary injunctive
relief from the arbitration panel or in a court located in Los Angeles, California, USA, which shall not be a waiver of this arbitration agreement. 
 5.9
Limitations on Monetary Remedies for Violations of this Agreement. ICANN’s aggregate monetary liability for violations of this Agreement shall not exceed an amount equal to the Accreditation fees paid by Registrar to ICANN under
Subsection 3.9 of this Agreement during the preceding twelve-month period. Registrar’s monetary liability to ICANN for violations of this Agreement shall be limited to Accreditation fees owing to ICANN under this Agreement and, except in the
case of a good faith disagreement concerning the interpretation of this agreement, reasonable payment to ICANN for the reasonable and direct costs including attorney fees, staff time, and other related expenses associated with legitimate efforts to
enforce Registrar compliance with this agreement and costs incurred by ICANN to respond to or mitigate the negative consequences of such behavior for Registered Name Holders and the Internet community. In the event of repeated willful material
breaches of the agreement, Registrar shall be liable for sanctions of up to five (5) times ICANN’s enforcement costs, but otherwise in no event shall either party be liable for special, indirect, incidental, punitive, exemplary, or
consequential damages for any violation of this Agreement. 
 6. AMENDMENT AND WAIVER. 

6.1 If the ICANN Board of Directors determines that an amendment to this Agreement (including to the Specifications referred to herein, unless such
Specifications expressly do not permit amendment thereto) and all other registrar agreements between ICANN and the Applicable Registrars (the “Applicable Registrar Agreements”) is desirable (each, a “Special Amendment”), ICANN
may adopt a Special Amendment pursuant to the requirements of and process set forth in this Section 6; provided that a Special Amendment may not be a Restricted Amendment. 

6.2 Prior to submitting a Special Amendment for Registrar Approval, ICANN shall first consult in good faith with the Working Group regarding the form and
substance of such Special Amendment. The duration of such consultation shall be reasonably determined by ICANN based on the substance of the Special Amendment. Following such consultation, ICANN may propose the adoption of a Special Amendment by
publicly posting such amendment on its website for no less than thirty (30) calendar days (the “Posting Period”) and providing notice of such proposed amendment to the Applicable Registrars in accordance with Section 7.6. ICANN
will consider the public comments submitted on a Special Amendment during the Posting Period (including comments submitted by the Applicable Registrars). 

6.3 If, within one hundred eighty (180) calendar days following the expiration of the Posting Period (the “Approval Period”), the ICANN Board
of Directors approves a Special Amendment (which may be in a form different than submitted for public comment, but must address the subject matter of the Special Amendment posted for public comment, as

  
 26 

 
modified to reflect and/or address input from the Working Group and public comments), ICANN shall provide notice of, and submit, such Special Amendment for approval or disapproval by the
Applicable Registrars. If, during the sixty (60) calendar day period following the date ICANN provides such notice to the Applicable Registrars, such Special Amendment receives Registrar Approval, such Special Amendment shall be deemed approved
(an “Approved Amendment”) by the Applicable Registrars, and shall be effective and deemed an amendment to this Agreement on the date that is sixty (60) calendar days following the date ICANN provided notice of the approval of such
Approved Amendment to Registrar (the “Amendment Effective Date”). In the event that a Special Amendment does not receive Registrar Approval, the Special Amendment shall be deemed not approved by the Applicable Registrars (a “Rejected
Amendment”). A Rejected Amendment will have no effect on the terms and conditions of this Agreement, except as set forth below. 
 6.4 If the ICANN
Board of Directors reasonably determines that a Rejected Amendment falls within the subject matter categories set forth in Section 1.2 of the Consensus Policies and Temporary Policies Specification, the ICANN Board of Directors may adopt a
resolution (the date such resolution is adopted is referred to herein as the “Resolution Adoption Date”) requesting an Issue Report (as such term is defined in ICANN’s Bylaws) by the Generic Names Supporting Organization (the
“GNSO”) regarding the substance of such Rejected Amendment. The policy development process undertaken by the GNSO pursuant to such requested Issue Report is referred to herein as a “PDP.” If such PDP results in a Final Report
supported by a GNSO Supermajority (as defined in ICANN’s Bylaws) that either (i) recommends adoption of the Rejected Amendment as Consensus Policy or (ii) recommends against adoption of the Rejected Amendment as Consensus Policy, and,
in the case of (i) above, the Board adopts such Consensus Policy, Registrar shall comply with its obligations pursuant to Section 4 of this Agreement. In either case, ICANN will abandon the Rejected Amendment and it will have no effect on
the terms and conditions of this Agreement. Notwithstanding the foregoing provisions of this Section 6.4, the ICANN Board of Directors shall not be required to initiate a PDP with respect to a Rejected Amendment if, at any time in the twelve
(12) month period preceding the submission of such Rejected Amendment for Registrar Approval pursuant to Section 6.3, the subject matter of such Rejected Amendment was the subject of a concluded or otherwise abandoned or terminated PDP
that did not result in a GNSO Supermajority recommendation. 
 6.5 If (i) a Rejected Amendment does not fall within the subject matter categories set
forth in Section 1.2 of the Consensus Policies and Temporary Policies Specification, (ii) the subject matter of a Rejected Amendment was, at any time in the twelve (12) month period preceding the submission of such Rejected Amendment
for Registrar Approval pursuant to Section 6.3, the subject of a concluded or otherwise abandoned or terminated PDP that did not result in a GNSO Supermajority recommendation, or (iii) a PDP does not result in a Final Report supported by a
GNSO Supermajority that either (a) recommends adoption of the Rejected Amendment as Consensus Policy or (b) recommends against adoption of the Rejected Amendment as Consensus Policy (or such PDP has otherwise been abandoned or terminated
for any reason), then, in any such case, such Rejected Amendment may still be adopted and become effective in the manner described below. In order for the Rejected Amendment to be adopted, the following requirements must be satisfied: 

  
 27 

 6.5.1 the subject matter of the Rejected Amendment must be within the scope of ICANN’s
mission and consistent with a balanced application of its core values (as described in ICANN’s Bylaws); 
 6.5.2 the Rejected Amendment
must be justified by a Substantial and Compelling Reason in the Public Interest, must be likely to promote such interest, taking into account competing public and private interests that are likely to be affected by the Rejected Amendment, and must
be narrowly tailored and no broader than reasonably necessary to address such Substantial and Compelling Reason in the Public Interest; 

6.5.3 to the extent the Rejected Amendment prohibits or requires conduct or activities, imposes material costs on the Applicable Registrars,
and/or materially reduces public access to domain name services, the Rejected Amendment must be the least restrictive means reasonably available to address the Substantial and Compelling Reason in the Public Interest; 

6.5.4 the ICANN Board of Directors must submit the Rejected Amendment, along with a written explanation of the reasoning related to its
determination that the Rejected Amendment meets the requirements set out in subclauses (i) through (iii) above, for public comment for a period of no less than thirty (30) calendar days; and 

6.5.5 following such public comment period, the ICANN Board of Directors must (i) engage in consultation (or direct ICANN management to
engage in consultation) with the Working Group, subject matter experts, members of the GNSO, relevant advisory committees and other interested stakeholders with respect to such Rejected Amendment for a period of no less than sixty (60) calendar
days; and (ii) following such consultation, reapprove the Rejected Amendment (which may be in a form different than submitted for Registrar Approval, but must address the subject matter of the Rejected Amendment, as modified to reflect and/or
address input from the Working Group and public comments) by the affirmative vote of at least two-thirds of the members of the ICANN Board of Directors eligible to vote on such matter, taking into account any ICANN policy affecting such eligibility,
including ICANN’s Conflict of Interest Policy (a “Board Amendment”). 
 Such Board Amendment shall, subject to Section 6.6, be deemed an
Approved Amendment, and shall be effective and deemed an amendment to this Agreement on the date that is sixty (60) calendar days following the date ICANN provided notice of the approval of such Board Amendment to Registrar (which effective
date shall be deemed the Amendment Effective Date hereunder). Notwithstanding the foregoing, a Board Amendment may not amend the registrar fees charged by ICANN hereunder, or amend this Section 6. 

6.6 Notwithstanding the provisions of Section 6.5, a Board Amendment shall not be deemed an Approved Amendment if, during the thirty (30) calendar
day period following the approval by the ICANN Board of Directors of the Board Amendment, the Working Group, on the behalf of the Applicable Registrars, submits to the ICANN Board of Directors 

  
 28 

 
an alternative to the Board Amendment (an “Alternative Amendment”) that meets the following requirements: 

6.6.1 sets forth the precise text proposed by the Working Group to amend this Agreement in lieu of the Board Amendment; 

6.6.2 addresses the Substantial and Compelling Reason in the Public Interest identified by the ICANN Board of Directors as the justification
for the Board Amendment; and 
 6.6.3 compared to the Board Amendment is: (a) more narrowly tailored to address such Substantial and
Compelling Reason in the Public Interest, and (b) to the extent the Alternative Amendment prohibits or requires conduct or activities, imposes material costs on Affected Registrars, or materially reduces access to domain name services, is a
less restrictive means to address the Substantial and Compelling Reason in the Public Interest. 
 Any proposed amendment that does not meet the
requirements of subclauses 6.6.1 through 6.6.3 in the immediately preceding sentence shall not be considered an Alternative Amendment hereunder and therefore shall not supersede or delay the effectiveness of the Board Amendment. If, following the
submission of the Alternative Amendment to the ICANN Board of Directors, the Alternative Amendment receives Registrar Approval, the Alternative Amendment shall supersede the Board Amendment and shall be deemed an Approved Amendment hereunder (and
shall be effective and deemed an amendment to this Agreement on the date that is sixty (60) calendar days following the date ICANN provided notice of the approval of such Alternative Amendment to Registrar, which effective date shall deemed the
Amendment Effective Date hereunder), unless, within a period of sixty (60) calendar days following the date that the Working Group notifies the ICANN Board of Directors of Registrar Approval of such Alternative Amendment (during which time
ICANN shall engage with the Working Group with respect to the Alternative Amendment), the ICANN Board of Directors by the affirmative vote of at least two-thirds of the members of the ICANN Board of Directors eligible to vote on such matter, taking
into account any ICANN policy affecting such eligibility, including ICANN’s Conflict of Interest Policy, rejects the Alternative Amendment. If (A) the Alternative Amendment does not receive Registrar Approval within thirty (30) days
of submission of such Alternative Amendment to the Applicable Registrars (and the Working Group shall notify ICANN of the date of such submission), or (B) the ICANN Board of Directors rejects the Alternative Amendment by such two-thirds vote,
the Board Amendment (and not the Alternative Amendment) shall be effective and deemed an amendment to this Agreement on the date that is sixty (60) calendar days following the date ICANN provided notice to Registrar (which effective date shall
deemed the Amendment Effective Date hereunder). If the ICANN Board of Directors rejects an Alternative Amendment, the board shall publish a written rationale setting forth its analysis of the criteria set forth in Sections 6.6.1 through 6.6.3. The
ability of the ICANN Board of Directors to reject an Alternative Amendment hereunder does not relieve the Board of the obligation to ensure that any Board Amendment meets the criteria set forth in Section 6.5.1 through 6.5.5. 

  
 29 

 6.7 In the event that Registrar believes an Approved Amendment does not meet the substantive requirements set out
in this Section 6 or has been adopted in contravention of any of the procedural provisions of this Section 6, Registrar may challenge the adoption of such Special Amendment pursuant to the dispute resolution provisions set forth in
Section 5.8, except that such arbitration shall be conducted by a three-person arbitration panel. Any such challenge must be brought within sixty (60) calendar days following the date ICANN provided notice to Registrar of the Approved
Amendment, and ICANN may consolidate all challenges brought by registrars (including Registrar) into a single proceeding. The Approved Amendment will be deemed not to have amended this Agreement during the pendency of the dispute resolution process.

 6.8 Registrar may apply in writing to ICANN for an exemption from the Approved Amendment (each such request submitted by Registrar hereunder, an
“Exemption Request”) during the thirty (30) calendar day period following the date ICANN provided notice to Registrar of such Approved Amendment. 

6.8.1 Each Exemption Request will set forth the basis for such request and provide detailed support for an exemption from the Approved
Amendment. An Exemption Request may also include a detailed description and support for any alternatives to, or a variation of, the Approved Amendment proposed by such Registrar. 

6.8.2 An Exemption Request may only be granted upon a clear and convincing showing by Registrar that compliance with the Approved Amendment
conflicts with applicable laws or would have a material adverse effect on the long-term financial condition or results of operations of Registrar. No Exemption Request will be granted if ICANN determines, in its reasonable discretion, that granting
such Exemption Request would be materially harmful to registrants or result in the denial of a direct benefit to registrants. 
 6.8.3 Within
ninety (90) calendar days of ICANN’s receipt of an Exemption Request, ICANN shall either approve (which approval may be conditioned or consist of alternatives to or a variation of the Approved Amendment) or deny the Exemption Request in
writing, during which time the Approved Amendment will not amend this Agreement. 
 6.8.4 If the Exemption Request is approved by ICANN, the
Approved Amendment will not amend this Agreement; provided, that any conditions, alternatives or variations of the Approved Amendment required by ICANN shall be effective and, to the extent applicable, will amend this Agreement as of the Amendment
Effective Date. If such Exemption Request is denied by ICANN, the Approved Amendment will amend this Agreement as of the Amendment Effective Date (or, if such date has passed, such Approved Amendment shall be deemed effective immediately on the date
of such denial), provided that Registrar may, within thirty (30) calendar days following receipt of ICANN’s determination, appeal ICANN’s decision to deny the Exemption Request pursuant to the dispute resolution procedures set forth
in Section 5.8. 

  
 30 

 6.8.5 The Approved Amendment will be deemed not to have amended this Agreement during the
pendency of the dispute resolution process. For avoidance of doubt, only Exemption Requests submitted by Registrar that are approved by ICANN pursuant to this Article 6 or through an arbitration decision pursuant to Section 5.8 shall exempt
Registrar from any Approved Amendment, and no Exemption Request granted to any other Applicable Registrar (whether by ICANN or through arbitration), shall have any effect under this Agreement or exempt Registrar from any Approved Amendment. 

6.9 Except as set forth in Section 4, Subsection 5.3, this Section 6, Section 7.4 and as otherwise set forth in this Agreement and the
Specifications hereto, no amendment, supplement or modification of this Agreement or any provision hereof shall be binding unless executed in writing by both parties, and nothing in this Section 6 or Section 7.4 shall restrict ICANN and
Registrar from entering into bilateral amendments and modifications to this Agreement negotiated solely between the two parties. No waiver of any provision of this Agreement shall be binding unless evidenced by a writing signed by the party waiving
compliance with such provision. No waiver of any of the provisions of this Agreement or failure to enforce any of the provisions hereof shall be deemed or shall constitute a waiver of any other provision hereof, nor shall any such waiver constitute
a continuing waiver unless otherwise expressly provided. For the avoidance of doubt, nothing in this Section 6 or Section 7.4 shall be deemed to limit Registrar’s obligation to comply with Section 4. 

6.10 Notwithstanding anything in this Section 6 to the contrary, (a) if Registrar provides evidence to ICANN’s reasonable satisfaction that the
Approved Amendment would materially increase the cost of providing Registrar Services, then ICANN will allow up to one-hundred eighty (180) calendar days for the Approved Amendment to become effective with respect to Registrar, and (b) no
Approved Amendment adopted pursuant to Section 6 shall become effective with respect to Registrar if Registrar provides ICANN with an irrevocable notice of termination pursuant to Section 5.4. 

7. MISCELLANEOUS PROVISIONS. 
 7.1 Specific
Performance. While this Agreement is in effect, either party may seek specific performance of any provision of this Agreement in the manner provided in Section 5.8, provided the party seeking such performance is not in material breach of
its obligations. 
 7.2 Handling by ICANN of Registrar-Supplied Data. Before receiving any Personal Data from Registrar, ICANN shall specify to
Registrar in writing the purposes for and conditions under which ICANN intends to use the Personal Data. ICANN may from time to time provide Registrar with a revised specification of such purposes and conditions, which specification shall become
effective no fewer than thirty (30) days after it is provided to Registrar. ICANN shall not use Personal Data provided by Registrar for a purpose or under conditions inconsistent with the specification in effect when the Personal Data was
provided. ICANN shall take reasonable steps to avoid uses of the Personal Data by third parties inconsistent with the specification. 

  
 31 

 7.3 Assignment; Change of Ownership or Management. 

7.3.1 Except as set forth in this Section 7.3.1, either party may assign or transfer this Agreement only with the prior written consent of
the other party, which shall not be unreasonably withheld. If ICANN fails to expressly provide or withhold its consent to any requested assignment (an “Assignment Request”) of this Agreement by Registrar within thirty (30) calendar
days of ICANN’s receipt of notice of such Assignment Request (or, if ICANN has requested additional information from Registrar in connection with its review of such request, sixty (60) calendar days of the receipt of all requested written
information regarding such request) from Registrar, ICANN shall be deemed to have consented to such requested assignment. Notwithstanding the foregoing, (i) ICANN may assign this Agreement without the consent of Registrar upon approval of the
ICANN Board of Directors in conjunction with a reorganization, reconstitution or re-incorporation of ICANN upon such assignee’s express assumption of the terms and conditions of this Agreement, (ii) Registrar may assign this Agreement
without the consent of ICANN to a wholly-owned subsidiary of Registrar upon such subsidiary’s express assumption of the terms and conditions of this Agreement, and (iii) ICANN shall be deemed to have consented to an Assignment Request in
which the assignee associated with such Assignment Request is a party to a Registrar Accreditation Agreement with ICANN on the terms set forth in this Agreement (provided that such assignee is then in compliance with the terms and conditions of such
Registrar Accreditation Agreement in all material respects), unless ICANN provides to Registrar a written objection to such Assignment Request within ten (10) calendar days of ICANN’s receipt of notice of such Assignment Request pursuant
to this Section 7.3.1. 
 7.3.2 To the extent that an entity acquires a Controlling interest in Registrar’s stock, assets or
business, Registrar shall provide ICANN notice within seven (7) days of such an acquisition. Such notification shall include a statement that affirms that Registrar meets the Specification or Policy on Accreditation criteria then in effect, and
is in compliance with its obligations under this Agreement. Within thirty (30) days of such notification, ICANN may request additional information from the Registrar establishing compliance with this Agreement, in which case Registrar must
supply the requested information within fifteen (15) days. Any disputes concerning Registrar’s continued Accreditation shall be resolved pursuant to Section 5.8. 

7.4 Negotiation Process. 
 7.4.1 If either
the Chief Executive Officer of ICANN (“CEO”) or the Chairperson of the Registrar Stakeholder Group (“Chair”) desires to discuss any revision(s) to this Agreement, the CEO or Chair, as applicable, shall provide written notice to
the other person, which shall set forth in reasonable detail the proposed revisions to this Agreement (a “Negotiation Notice”). Notwithstanding the foregoing, neither the CEO nor the Chair may (i) propose revisions to this Agreement
that modify any Consensus Policy then existing, (ii) propose revisions to this Agreement pursuant to this Section 

  
 32 

 
7.4 on or before June 30, 2014, or (iii) propose revisions or submit a Negotiation Notice more than once during any twelve month period beginning on July 1, 2014. 

7.4.2 Following receipt of the Negotiation Notice by either the CEO or the Chair, ICANN and the Working Group shall consult in good faith
negotiations regarding the form and substance of the proposed revisions to this Agreement, which shall be in the form of a proposed amendment to this Agreement (the “Proposed Revisions”), for a period of at least ninety (90) calendar
days (unless a resolution is earlier reached) and attempt to reach a mutually acceptable agreement relating to the Proposed Revisions (the “Discussion Period”). 

7.4.3 If, following the conclusion of the Discussion Period, an agreement is reached on the Proposed Revisions, ICANN shall post the mutually
agreed Proposed Revisions on its website for public comment for no less than thirty (30) calendar days (the “Posting Period”) and provide notice of such revisions to all Applicable Registrars in accordance with Section 7.6. ICANN
and the Working Group will consider the public comments submitted on the Proposed Revisions during the Posting Period (including comments submitted by the Applicable Registrars). Following the conclusion of the Posting Period, the Proposed Revisions
shall be submitted for Registrar Approval and approval by the ICANN Board of Directors. If such approvals are obtained, the Proposed Revisions shall be deemed an Approved Amendment by the Applicable Registrars and ICANN, and shall be effective and
deemed an amendment to this Agreement upon sixty (60) calendar days notice from ICANN to Registrar. 
 7.4.4 If, following the
conclusion of the Discussion Period, an agreement is not reached between ICANN and the Working Group on the Proposed Revisions, either the CEO or the Chair may provide the other person written notice (the “Mediation Notice”) requiring each
party to attempt to resolve the disagreements related to the Proposed Revisions through impartial, facilitative (non-evaluative) mediation in accordance with the terms and conditions set forth below. In the event that a Mediation Notice is provided,
ICANN and the Working Group shall, within fifteen (15) calendar days thereof, simultaneously post the text of their desired version of the Proposed Revisions and a position paper with respect thereto on ICANN’s website. 

7.4.4.1 The mediation shall be conducted by a single mediator selected by the parties. If the parties cannot agree on a mediator within fifteen
(15) calendar days following receipt by the CEO or Chair, as applicable, of the Mediation Notice, the parties will promptly select a mutually acceptable mediation provider entity, which entity shall, as soon as practicable following such
entity’s selection, designate a mediator, who is a licensed attorney with general knowledge of contract law and, to the extent necessary to mediate the particular dispute, general knowledge of the domain name system. Any mediator must confirm
in writing that he or she is not, and will not become during the term of the mediation, an employee, partner, executive officer, director, or security holder of ICANN or an Applicable Registrar. If such

  
 33 

 
confirmation is not provided by the appointed mediator, then a replacement mediator shall be appointed pursuant to this Section 7.4.4.1. 

7.4.4.2 The mediator shall conduct the mediation in accordance with the rules and procedures for facilitative mediation that he or she
determines following consultation with the parties. The parties shall discuss the dispute in good faith and attempt, with the mediator’s assistance, to reach an amicable resolution of the dispute. 

7.4.4.3 Each party shall bear its own costs in the mediation. The parties shall share equally the fees and expenses of the mediator. 

7.4.4.4 If an agreement is reached during the mediation, ICANN shall post the mutually agreed Proposed Revisions on its website for the Posting
Period and provide notice to all Applicable Registrars in accordance with Section 7.6. ICANN and the Working Group will consider the public comments submitted on the agreed Proposed Revisions during the Posting Period (including comments
submitted by the Applicable Registrars). Following the conclusion of the Posting Period, the Proposed Revisions shall be submitted for Registrar Approval and approval by the ICANN Hoard of Directors. If such approvals are obtained, the Proposed
Revisions shall be deemed an Approved Amendment by the Applicable Registrars and ICANN, and shall be effective and deemed an amendment to this Agreement upon sixty (60) days notice from ICANN to Registrar. 

7.4.4.5 If the parties have not resolved the dispute for any reason by the date that is ninety (90) calendar days following receipt by the
CEO or Chair, as applicable, of the Mediation Notice, the mediation shall automatically terminate (unless extended by agreement of the parties). The mediator shall deliver to the parties a definition of the issues that could be considered in future
arbitration, if invoked. Those issues are subject to the limitations set forth in Section 7.4.5.2 below. 
 7.4.5 If, following
mediation, ICANN and the Working Group have not reached an agreement on the Proposed Revisions, either the CEO or the Chair may provide the other person written notice (an “Arbitration Notice”) requiring ICANN and the Applicable Registry
Operators to resolve the dispute through binding arbitration in accordance with the arbitration provisions of Section 5.8, subject to the requirements and limitations of this Section 7.4.5. 

7.4.5.1 If an Arbitration Notice is sent, the mediator’s definition of issues, along with the Proposed Revisions (be those from ICANN,
Registrars or both) shall be posted for public comment on ICANN’s website for a period of no less than thirty (30) calendar days. ICANN and the Working Group will consider the public comments submitted on the Proposed Revisions during the
Posting Period (including comments submitted by the Applicable Registrars), 

  
 34 

 
and information regarding such comments and consideration shall be provided to the a three (3) person arbitrator panel. Each party may modify its Proposed Revisions before and after the
Posting Period. The arbitration proceeding may not commence prior to the closing of such public comment. period, and ICANN may consolidate all challenges brought by registrars (including Registrar) into a single proceeding. Except as set forth in
this Section 7.4.5.1, the arbitration shall be conducted pursuant to Section 5.8. 
 7.4.5.2 No dispute regarding the Proposed
Revisions may be submitted for arbitration to the extent the subject matter of the Proposed Revisions (i) relates to Consensus Policy, (ii) falls within the subject matter categories set forth in Section 1.2 of the Consensus Policies
and Temporary Policies Specification , or (iii) seeks to amend any of the following provisions or Specifications of this Agreement: Sections 2, 4 and 6; subsections 3.1, 3.2, 3.3, 3.4, 3.5, 3.7, 3.8, 3.9, 3.14, 3.19, 3.21, 5.1, 5.2 or 5.3; and
the Consensus Policies and Temporary Policies Specification, Data Retention Specification, WHOIS Accuracy Program Specification, Registration Data Directory Service (WHOIS) Specification or the Additional Registrar Operation Specification. 

7.4.5.3 The mediator will brief the arbitrator panel regarding ICANN and the Working Group’s respective proposals relating to the Proposed
Revisions. 
 7.4.5.4 No amendment to this Agreement relating to the Proposed Revisions may be submitted for arbitration by either the
Working Group or ICANN, unless, in the case of the Working Group, the proposed amendment has received Registrar Approval and, in the case of ICANN, the proposed amendment has been approved by the ICANN Board of Directors. 

7.4.5.5 In order for the arbitrator panel to approve either ICANN or the Working Group’s proposed amendment relating to the Proposed
Revisions, the arbitrator panel must conclude that such proposed amendment is consistent with a balanced application of ICANN’s core values (as described in ICANN’s Bylaws) and reasonable in light of the balancing of the costs and benefits
to the business interests of the Applicable Registrars and ICANN (as applicable), and the public benefit sought to be achieved by the Proposed Revisions as set forth in such amendment. If the arbitrator panel concludes that either ICANN or the
Working Group’s proposed amendment relating to the Proposed Revisions meets the foregoing standard, such amendment shall be effective and deemed an amendment to this Agreement upon sixty (60) calendar days notice from ICANN to Registrar
and deemed an Approved Amendment hereunder. 
 7.4.6 With respect to an Approved Amendment relating to an amendment proposed by ICANN,
Registrar may apply in writing to ICANN for an exemption from such amendment pursuant to the provisions of Section 6.8. 

  
 35 

 7.4.7 Notwithstanding anything in this Section 7.4 to the contrary, (a) if Registrar
provides evidence to ICANN’s reasonable satisfaction that the Approved Amendment would materially increase the cost of providing Registrar Services, then ICANN will allow up to one-hundred eighty (180) calendar days for the Approved
Amendment to become effective with respect to Registrar, and (b) no Approved Amendment adopted pursuant to Section 7.4 shall become effective with respect to Registrar if Registrar provides ICANN with an irrevocable notice of termination
pursuant to Section 5.4. 
 7.5 No Third-Party Beneficiaries. This Agreement shall not be construed to create any obligation by either ICANN or
Registrar to any non-party to this Agreement, including any Registered Name Holder. 
 7.6 Notices and Designations. Except as provided in
Section 4.4 and Section 6, all notices to be given under this Agreement shall be given in writing at the address of the appropriate party as set forth below, unless that party has given a notice of change of address in writing. Each party
shall notify the other party within thirty (30) days of any change to its contact information. Any written notice required by this Agreement shall be deemed to have been properly given when delivered in person, when sent by electronic facsimile
with receipt of confirmation of delivery, when scheduled for delivery by internationally recognized courier service, or when delivered by electronic means followed by an affirmative confirmation of receipt by the recipient’s facsimile machine
or email server. For any notice of a new Specification or Policy established in accordance with this Agreement Registrar shall be afforded a reasonable period of time after notice of the establishment of such Specification or Policy is e-mailed to
Registrar and posted on the ICANN website in which to comply with that specification, policy or program, taking into account any urgency involved. Notices and designations by ICANN under this Agreement shall be effective when written notice of them
is deemed given to Registrar. 
 If to ICANN, addressed to: 

Attention: Registrar Accreditation Notices 

Internet Corporation for Assigned Names and Numbers 

12025 Waterfront Drive, Suite 300 

Los Angeles, California 90094-2536 USA 

Telephone: +1 310 823-9358 

Facsimile: + 1 310 823-8649 
 If
to Registrar, addressed to: 
 Attention: James Bladel 

GoDaddy.com, LLC 
 14455 North
Hayden Road, Suite 219 
 Scottsdale, Arizona 85260 

  
 36 

 Registrar Website URL: http://www.godaddy.com/ 

Telephone: +1 319 899 1776 

Facsimile: +1 480 247 4084 

e-mail: icannpolicy@godaddy.com 
 7.7 Dates
and Times. All dates and times relevant to this Agreement or its performance shall be computed based on the date and time observed in Los Angeles, California, USA. 

7.8 Language. All notices, designations, and Specifications or Policies made under this Agreement shall be in the English language. 

7.9 Counterparts. This Agreement may be executed in one or more counterparts, each of which shall be deemed an original, but all of which together
shall constitute one and the same instrument. 
 7.10 Entire Agreement. Except to the extent (a) expressly provided in a written agreement
executed by both parties concurrently herewith or (b) of written assurances provided by Registrar to ICANN in connection with its Accreditation, this Agreement (including the specifications, which form part of it) constitutes the entire
agreement of the parties pertaining to the Accreditation of Registrar and supersedes all prior agreements, understandings, negotiations and discussions, whether oral or written, between the parties on that subject. 

7.11 Severability. If one or more provisions of this Agreement are held to be unenforceable under applicable law, the parties agree to renegotiate such
provision in good faith. In the event that the parties cannot reach a mutually agreeable and enforceable replacement for such provision, then (a) such provision shall be excluded from this Agreement; (b) the balance of this Agreement shall
be interpreted as if such provision were so excluded; and (c) the balance of this Agreement shall be enforceable in accordance with its terms. 

[signature page follows] 

  
 37 

 IN WITNESS WHEREOF, the parties hereto have caused this Agreement to be executed in duplicate by their duly
authorized representatives. 
  

									
	ICANN	  		  	GoDaddy.com, LLC
					
	By:	  	 /s/ Akram Atallah
	  		  	By:	  	 /s/ Nima Kelly

	Name:	  	 Akram Atallah
	  		  	Name:	  	 Nima Kelly

	Title:	  	 President, GDD
	  		  	Title:	  	 General Counsel

  
 38 

 WHOIS ACCURACY PROGRAM SPECIFICATION 

Registrar shall implement and comply with the requirements set forth in this Specification, as well as any commercially practical updates to this
Specification that are developed by ICANN and the Registrar Stakeholder Group during the Term of the Registrar Accreditation Agreement. 
  

	1.	Except as provided for in Section 3 below, within fifteen (15) days of (1) the registration of a Registered Name sponsored by Registrar, (2) the transfer of the sponsorship of a Registered Name to
Registrar, or (3) any change in the Registered Name Holder with respect to any Registered Name sponsored by Registrar, Registrar will, with respect to both Whois information and the corresponding customer account holder contact information
related to such Registered Name: 

  

	 	a.	Validate the presence of data for all fields required under Subsection 3.3.1 of the Agreement in a proper format for the applicable country or territory. 

 

	 	b.	Validate that all email addresses are in the proper format according to RFC 5322 (or its successors). 

  

	 	c.	Validate that telephone numbers are in the proper format according to the ITU-T E.164 notation for international telephone numbers (or its equivalents or successors). 

 

	 	d.	Validate that postal addresses are in a proper format for the applicable country or territory as defined in UPU Postal addressing format templates, the S42 address templates (as they may be updated) or other standard
formats. 

  

	 	e.	Validate that all postal address fields are consistent across fields (for example: street exists in city, city exists in state/province, city matches postal code) where such information is technically and commercially
feasible for the applicable country or territory. 

  

	 	f.	Verify: 

  

	 	i.	the email address of the Registered Name Holder (and, if different, the Account Holder) by sending an email requiring an affirmative response through a tool-based authentication method such as providing a unique code
that must be returned in a manner designated by the Registrar, or 

  

	 	ii.	 the telephone number of the Registered Name Holder (and, if different, the Account Holder) by either (A) calling or sending an SMS to the
Registered Name Holder’s telephone number providing a unique code that must be returned in a manner designated by the Registrar, or (B) calling the Registered Name Holder’s telephone number and requiring the Registered Name Holder to
provide a unique code that was sent to the Registered Name Holder via web, email or postal mail. 

  
 39 

	 	
In either case, if Registrar does not receive an affirmative response from the Registered Name Holder, Registrar shall either verify the applicable contact information manually or suspend the
registration, until such time as Registrar has verified the applicable contact information. If Registrar does not receive an affirmative response from the Account Holder, Registrar shall verify the applicable contact information manually, but is not
required to suspend any registration. 

  

	2.	Except as provided in Section 3 below, within fifteen (15) calendar days after receiving any changes to contact information in Whois or the corresponding customer account contact information related to any
Registered Name sponsored by Registrar (whether or not Registrar was previously required to perform the validation and verification requirements set forth in this Specification in respect of such Registered Name), Registrar will validate and, to the
extent required by Section 1, verify the changed fields in the manner specified in Section 1 above. If Registrar does not receive an affirmative response from the Registered Name Holder providing the required verification, Registrar shall
either verify the applicable contact information manually or suspend the registration, until such time as Registrar has verified the applicable contact information. If Registrar does not receive an affirmative response from the Account Holder,
Registrar shall verify the applicable contact information manually, but is not required to suspend any registration. 

  

	3.	Except as set forth in paragraph 4 below, Registrar is not required to perform the above validation and verification procedures in Section 1(a) through 1(f) above, if Registrar has already successfully completed
the validation and verification procedures on the identical contact information and is not in possession of facts or knowledge of circumstances that suggest that the information is no longer valid. 

 

	4.	If Registrar has any information suggesting that the contact Information specified in Section 1(a) through 1(f) above is incorrect (such as Registrar receiving a bounced email notification or non-delivery
notification message in connection with compliance with ICANN’s Whois Data Reminder Policy or otherwise) for any Registered Name sponsored by Registrar (whether or not Registrar was previously required to perform the validation and verification
requirements set forth in this Specification in respect of such Registered Name), Registrar must verify or re-verify, as applicable, the email address(es) as described in Section 1.f (for example by requiring an affirmative response to a Whois
Data Reminder Policy notice). If, within fifteen (15) calendar days after receiving any such information, Registrar does not receive an affirmative response from the Registered Name Holder providing the required verification, Registrar shall
either verify the applicable contact information manually or suspend the registration, until such time as Registrar has verified the applicable contact information. If, within fifteen (15) calendar days after receiving any such information,
Registrar does not receive an affirmative response from the customer paying for the Registered Name, if applicable, providing the required verification, Registrar shall verify the applicable contact information manually, but is not required to
suspend any registration. 

  
 40 

	5.	Upon the occurrence of a Registered Name Holder’s willful provision of inaccurate or unreliable WHOIS information, its willful failure promptly to update information provided to Registrar, or its failure to respond
for over fifteen (15) calendar days to inquiries by Registrar concerning the accuracy of contact details associated with the Registered Name Holder’s registration, Registrar shall either terminate or suspend the Registered Name
Holder’s Registered Name or place such registration on clientHold and clientTransferProhibited, until such time as Registrar has validated the information provided by the Registered Name Holder. 

 

	6.	The terms and conditions of this Specification shall be reviewed by ICANN in consultation with the Registrar Stakeholder Group on or about the first anniversary of the date that the form of this Agreement is first
executed by a registrar. 

  

	7.	Nothing within this Specification shall be deemed to require Registrar to perform verification or validation of any customer account holder information where the customer account holder does not have any Registered
Names under sponsorship of Registrar. 

  
 41 

 REGISTRATION DATA DIRECTORY SERVICE (WHOIS) 

SPECIFICATION 
  

	1.	Registration Data Directory Services. Until ICANN requires a different protocol, Registrar will operate a WHOIS service available via port 43 in accordance with RFC 3912, and a web-based Directory Service
providing free public query-based access to at least the elements set forth in Section 3.3.1.1 through 3.3.1.8 of the Registrar Accreditation Agreement in the format set forth in Section 1.4 of this Specification. ICANN reserves the right
to specify alternative formats and protocols, and upon such specification, the Registrar will implement such alternative specification as soon as reasonably practicable. 

Following the publication by the IETF of a Proposed Standard, Draft Standard or Internet Standard and any revisions thereto (as specified in
RFC 2026) relating to the web-based directory service as specified in the IETF Web Extensible Internet Registration Data Service working group, Registrar shall implement the directory service specified in any such standard (or any revision thereto)
no later than 135 days after such implementation is requested by ICANN. Registrar shall implement internationalized registration data publication guidelines according to the specification published by ICANN following the work of the ICANN
Internationalized Registration Data Working Group (IRD-WG) and its subsequent efforts, no later than 135 days after it is approved by the ICANN Board. 
  

	1.1.	The format of responses shall follow a semi-free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registrar, and of the user querying the database. 

 

	1.2.	Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value. 

 

	1.3.	For fields where more than one value exists, multiple numbered key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be
considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together. 

 

	1.4.	Domain Name Data: 

  

	1.4.1	Query format: whois –h whois.example-registrar.tld EXAMPLE.TLD 

  

	1.4.2	Response format: 

 The format of responses shall contain all the elements and follow a semi-free text
format outline below. Additional data elements can be added at the end of the text format outlined below. The data element may, at the option of Registrar, be followed by a blank line and a 

  
 42 

 
legal disclaimer specifying the rights of Registrar, and of the user querying the database (provided that any such legal disclaimer must be preceded by such blank line). 

Domain Name: EXAMPLE.TLD 

Registry Domain ID: D1234567-TLD 

Registrar WHOIS Server: whois.example-registrar.tld 

Registrar URL: http://www.example-registrar.tld 

Updated Date: 2009-05-29T20:13:00Z 

Creation Date: 2000-10-08T00:45:00Z 

Registrar Registration Expiration Date: 2010-10-08T00:44:59Z 

Registrar: EXAMPLE REGISTRAR LLC 

Registrar IANA ID: 5555555 

Registrar Abuse Contact Email: email@registrar.tld 

Registrar Abuse Contact Phone: +1.1235551234 

Reseller: EXAMPLE RESELLER1 

Domain Status: clientDeleteProhibited2 

Domain Status: clientRenewProhibited 

Domain Status: clientTransferProhibited 

Registry Registrant ID: 53 72808-ERL3 

Registrant Name: EXAMPLE REGISTRANT4 

Registrant Organization: EXAMPLE ORGANIZATION 

Registrant Street: 123 EXAMPLE STREET 

Registrant City: ANYTOWN 

Registrant State/Province: AP5 

Registrant Postal Code: A1A1A16 

Registrant Country: AA 

Registrant Phone: +1.5555551212 

Registrant Phone Ext: 12347 

Registrant Fax: +1.5555551213 

Registrant Fax Ext: 4321 

Registrant Email: EMAIL@EXAMPLE.TLD 

Registry Admin ID: 5372809-ERL8 

Admin Name: EXAMPLE REGISTRANT ADMINISTRATIVE 

Admin Organization: EXAMPLE REGISTRANT ORGANIZATION 

Admin Street: 123 EXAMPLE STREET 

Admin City: ANYTOWN 
  

	1 	Data element may be deleted, provided that lithe data element is used, it must appear at this location. 

	2 	Note: all applicable statuses must be displayed in the Whois output. 

	3 	May be left blank if not available from Registry. 

	4 	For the Registrant, Admin and Tech contact fields requiring a “Name” or “Organization”, the output must include either the name or organization (or both, if available). 

	5 	All “State/Province” fields may be left blank if not available. 

	6 	All “Postal Code” fields may be left blank if not available. 

	7 	All “Phone Ext”, “Fax” and “Fax Ext” fields may be left blank if not available. 

	8 	May be left blank if not available from Registry. 

  
 43 

 Admin State/Province: AP 

Admin Postal Code: A1A1A1 

Admin Country: AA 
 Admin Phone:
+1.5555551212 
 Admin Phone Ext: 1234 

Admin Fax: +1.5555551213 
 Admin
Fax Ext: 1234 
 Admin Email: EMAIL@EXAMPLE.TLD 

Registry Tech ID: 5372811-ERL9 

Tech Name: EXAMPLE REGISTRANT TECHNICAL 

Tech Organization: EXAMPLE REGISTRANT LLC 

Tech Street: 123 EXAMPLE STREET 

Tech City: ANYTOWN 
 Tech
State/Province: AP 
 Tech Postal Code: A1A1A1 

Tech Country: AA 
 Tech Phone:
+1.1235551234 
 Tech Phone Ext: 1234 

Tech Fax: +1.5555551213 
 Tech
Fax Ext: 93 
 Tech Email: EMAIL@EXAMPLE.TLD 

Name Server: NS01.EXAMPLE-REGISTRAR.TLD10 

Name Server: NS02.EXAMPLE-REGISTRAR.TLD 

DNSSEC: signedDelegation 
 URL
of the ICANN WHOIS Data Problem Reporting System: 
 http://wdprs.internic.net/ 

>>> Last update of WFIOIS database: 2009-05-29T20:15:00Z 
  

	1.5.	The format of the following data fields: domain status, individual and organizational names, address, street, city, state/province, postal code, country, telephone and fax numbers, email addresses, date and times must
conform to the mappings specified in EPP RFCs 5730-5734 (or its successors), and IPv6 addresses format should conform to RFC 5952 (or its successor), so that the display of this information (or values returned in WHOIS responses) can be uniformly
processed and understood. 

  

	2.	Service Level Agreement for Registration Data Directory Services (RDDS) 

  

	2.1.	Definitions 

  

	 	•	 	IP address. Refers to IPv4 or IPv6 addresses without making any distinction between the two. When there is need to make a distinction, IPv4 or IPv6 is used. 

 
  

	9 	May be left blank if not available from Registry. 

	10 	All associated nameservers must be listed. 

  
 44 

	 	•	 	Probes. Network hosts used to perform tests (see below) that are located at various global locations. 

  

	 	•	 	RDDS. Registration Data Directory Services refers to the collective of WHOIS and Web based WHOIS services. 

  

	 	•	 	RTT. Round-Trip Time or RTT refers to the time measured from the sending of the first bit of the first packet of the sequence of packets needed to make a request until the reception of the last bit of the
last packet of the sequence needed to receive the response. If the client does not receive the whole sequence of packets needed to consider the response as received, the request will be considered unanswered. 

 

	 	•	 	SLR. Service Level Requirement is the level of service expected for a certain parameter being measured in a Service Level Agreement (SLA). 

 

	2.2.	Service Level Agreement Matrix 

  

					
	 	 	 Parameter
	 	 SLR (monthly basis)

			
	 RDDS
	 	RDDS availability	 	less than or equal to 864 min of downtime
			
		 	RDDS query RTT	 	less than or equal to 4000 ms, for at least 95% of the queries
			
		 	RDDS update time	 	less than or equal to 60 min, for at least 95% of the probes

 Registrar is encouraged to do maintenance for the different services at the times and dates of statistically lower traffic for
each service. Since substantial downtime is already incorporated in the availability metric, planned outages or similar; any downtime, be it for maintenance or due to system failures, will be noted simply as downtime and counted for SLA purposes.

  

	2.2.1	RDDS availability. Refers to the ability of all the RDDS services for the Registrar to respond to queries from an Internet user with appropriate data from the relevant registrar system. If 51% or more of the RDDS
testing probes see any of the RDDS services as unavailable during a given time, the RDDS will be considered unavailable. 

  

	2.2.2	WHOIS query RTT. Refers to the RTT of the sequence of packets from the start of the TCP connection to its end, including the reception of the WHOIS response. If the RTT is 5-times or more the
corresponding SLR, the RTT will be considered undefined. 

  

	2.2.3	Web-based-WHOIS query RTT. Refers to the RTT of the sequence of packets from the start of the TCP connection to its end, including the reception of the HTTP response for only one HTTP request. If
Registrar implements a multiple-step process to get to the information, only the last step shall be measured. If the RTT is 5-times or more the corresponding SLR, the RTT will be considered undefined. 

  
 45 

	2.2.4	RDDS query RTT. Refers to the collective of “WHOIS query RTT” and “Web-based- WHOIS query RTT”. 

 

	2.2.5	RDDS update time. Refers to the time measured from the receipt of an EPP confirmation to a transform command on a domain name, host or contact, up until the servers of the RDDS services reflect the changes made.

  

	2.2.6	RDDS test. Means one query sent to a particular “IP address” of one of the servers of one of the RDDS services. Queries shall be about existing objects in the registrar system and the responses
must contain the corresponding information otherwise the query will be considered unanswered. Queries with an RTT 5 times higher than the corresponding SLR will be considered as unanswered. The possible results to an RDDS test are: a number
in milliseconds corresponding to the RTT or undefined/unanswered. 

  

	2.2.7	Measuring RDDS parameters. Every 5 minutes, RDDS probes will select one IP address from all the public-DNS registered “IP addresses” of the servers for each RDDS service of the Registrar being
monitored and make an “RDDS test” to each one. If an “RDDS test” result is undefined/unanswered, the corresponding RDDS service will be considered as unavailable from that probe until it is time to make a new test.

  

	2.2.8	Collating the results from RDDS probes. The minimum number of active testing probes to consider a measurement valid is 10 at any given measurement period, otherwise the measurements will be discarded and will be
considered inconclusive; during this situation no fault will be flagged against the SLRs. 

  

	2.2.9	Placement of RDDS probes. Probes for measuring RDDS parameters shall be placed inside the networks with the most users across the different geographic regions; care shall be taken not to deploy probes behind high
propagation-delay links, such as satellite links. 

  

	2.3.	Covenants of Performance Measurement 

 Registrar shall not interfere with measurement Probes,
including any form of preferential treatment of the requests for the monitored services. Registrar shall respond to the measurement tests described in this Specification as it would do with any other request from Internet users (for RDDS). 

  
 46 

 CONSENSUS POLICIES AND TEMPORARY POLICIES 

SPECIFICATION 
  

	1.	Consensus Policies. 

  

	1.1.	“Consensus Policies” are those policies established (1) pursuant to the procedure set forth in ICANN’s Bylaws and due process, and (2) covering those topics listed in
Section 1.2 of this document. The Consensus Policy development process and procedure set forth in ICANN’s Bylaws may be revised from time to time in accordance with the process set forth therein. 

 

	1.2.	Consensus Policies and the procedures by which they are developed shall be designed to produce, to the extent possible, a consensus of Internet stakeholders, including registrars. Consensus Policies shall relate to one
or more of the following: 

  

	 	1.2.1.	issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, security and/or stability of the Internet, Registrar Services, Registry Services, or the Domain Name System
(“DNS”); 

  

	 	1.2.2.	functional and performance specifications for the provision of Registrar Services; 

  

	 	1.2.3.	registrar policies reasonably necessary to implement Consensus Policies relating to a gTLD registry; 

  

	 	1.2.4.	resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names, but including where such policies take into account use of the domain names); or 

 

	 	1.2.5.	restrictions on cross-ownership of registry operators and registrars or Resellers and regulations and restrictions with respect to registrar and registry operations and the use of registry and registrar data in the
event that a registry operator and a registrar or Reseller are affiliated. 

  

	1.3.	Such categories of issues referred to in Section 1.2 shall include, without limitation: 

  

	 	1.3.1.	principles for allocation of registered names in a TLD (e.g., first-come/first-served, timely renewal, holding period after expiration); 

 

	 	1.3.2.	prohibitions on warehousing of or speculation in domain names by registries or registrars; 

  

	 	1.3.3.	reservation of registered names in a TLD that may not be registered initially or that may not be renewed due to reasons reasonably related to (i) avoidance of confusion among or misleading of users,
(ii) intellectual property, or (iii) the technical management of the DNS or the Internet (e.g., establishment of reservations of names from registration); 

  
 47 

	 	1.3.4.	maintenance of and access to accurate and up-to-date information concerning Registered Names and name servers; 

  

	 	1.3.5.	procedures to avoid disruptions of domain name registrations due to suspension or termination of operations by a registry operator or a registrar, including procedures for allocation of responsibility among continuing
registrars of the Registered Names sponsored in a TLD by a registrar losing accreditation; and 

  

	 	1.3.6.	the transfer of registration data upon a change in registrar sponsoring one or more Registered Names. 

  

	1.4.	In addition to the other limitations on Consensus Policies, they shall not: 

  

	 	1.4.1.	prescribe or limit the price of Registrar Services; 

  

	 	1.4.2.	modify the limitations on Temporary Policies (defined below) or Consensus Policies; 

  

	 	1.4.3.	modify the provisions in the Registrar Accreditation Agreement regarding terms or conditions for the renewal, termination or amendment of the Registrar Accreditation Agreement or fees paid by Registrar to ICANN; or

  

	 	1.4.4.	modify ICANN’s obligations to not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and to not single out Registrar for disparate treatment unless justified by
substantial and reasonable cause, and exercise its responsibilities in an open and transparent manner. 

  

	2.	Temporary Policies. Registrar shall comply with and implement all specifications or policies established by the ICANN Board of Directors (the “Board”) on a temporary basis, if adopted by
the Board by a vote of at least two-thirds of its members, so long as the Board reasonably determines that such modifications or amendments are justified and that immediate temporary establishment of a specification or policy on the subject is
necessary to maintain the stability or security of Registrar Services, Registry Services or the DNS or the Internet (“Temporary Policies”). 

 

	2.1.	Such proposed specification or policy shall be as narrowly tailored as feasible to achieve those objectives. In establishing any Temporary Policy, the Board shall state the period of time for which the Temporary Policy
is adopted and shall immediately implement the Consensus Policy development process set forth in ICANN’s Bylaws. 

  

	 	2.1.1.	ICANN shall also issue an advisory statement containing a detailed explanation of its reasons for adopting the Temporary Policy and why the Board believes such Temporary Policy should receive the consensus support of
Internet stakeholders. 

  

	 	2.1.2.	 If the period of time for which the Temporary Policy is adopted exceeds 90 days, the Board shall reaffirm its temporary adoption every 90 days for a
total 

  
 48 

	 	
period not to exceed one year, in order to maintain such Temporary Policy in effect until such time as it becomes a Consensus Policy. If the one year period expires or, if during such one year
period, the Temporary Policy does not become a Consensus Policy and is not reaffirmed by the Board, Registrar shall no longer be required to comply with or implement such Temporary Policy. 

 

	3.	Notice and Conflicts. Registrar shall be afforded a reasonable period of time following notice of the establishment of a Consensus Policy or Temporary Policy in which to comply with such policy or specification,
taking into account any urgency involved. In the event of a conflict between Registrar Services and Consensus Policies or any Temporary Policy, the Consensus Polices or Temporary Policy shall control, but only with respect to subject matter in
conflict. For the avoidance of doubt, Consensus Policies that meet the requirements of this Specification may supplement or supersede provisions of the agreements between Registrar and ICANN, but only to the extent that such Consensus Policies
relate to the matters set forth in Section 1.2 and 1.3 of this Specification. 

  
 49 

 SPECIFICATION ON PRIVACY AND PROXY REGISTRATIONS 

Until the earlier to occur of (i) January 1, 2017, and (ii) the date ICANN establishes and implements a Privacy and Proxy Accreditation Program
as referenced in Section 3.14 of the Registrar Accreditation Agreement, Registrar agrees to comply, and to require its Affiliates and Resellers to comply, with the terms of this Specification, provided that ICANN and the Working Group may
mutually agree to extend the term of this Specification. This Specification may not be modified by ICANN or Registrar. 
  

	 	1.	Definitions. For the purposes of this Specification, the following definitions shall apply. 

  

	 	1.1	“P/P Customer” means, regardless of the terminology used by the P/P Provider, the licensee, customer, beneficial user, beneficiary, or other recipient of Privacy Services and Proxy Services. 

 

	 	1.2	“Privacy Service” is a service by which a Registered Name is registered to its beneficial user as the Registered Name Holder, but for which alternative, reliable contact information is provided by the P/P
Provider for display of the Registered Name Holder’s contact information in the Registration Data Service (Whois) or equivalent services. 

  

	 	1.3	“Proxy Service” is a service through which a Registered Name Holder licenses use of a Registered Name to the P/P Customer in order to provide the P/P Customer use of the domain name, and the Registered Name
Holder’s contact information is displayed in the Registration Data Service (Whois) or equivalent services rather than the P/P Customer’s contact information. 

 

	 	1.4	“P/P Provider” or “Service Provider” is the provider or Privacy /Proxy Services, including Registrar and its Affiliates, as applicable. 

 

	 	2.	Obligations of Registrar. For any Proxy Service or Privacy Service offered by the Registrar or Its Affiliates, including any of Registrar’s or its Affiliates’ P/P services distributed through Resellers,
and used in connection with Registered Names Sponsored by the Registrar, the Registrar and its Affiliates must require all P/P Providers to follow the requirements described in this Specification and to abide by the terms and procedures published
pursuant to this Specification. 

  

	 	2.1	Disclosure of Service Terms. P/P Provider shall publish the terms and conditions of its service (including pricing), on its website and/or Registrar’s website. 

 

	 	2.2	Abuse/Infringement Point of Contact. P/P Provider shall publish a point of contact for third parties wishing to report abuse or infringement of trademarks (or other rights). 

  
 50 

	 	2.3	Disclosure of Identity of P/P Provider. P/P Provider shall publish its business contact information on its website and/or Registrar’s website. 

 

	 	2.4	Terms of service and description of procedures. The P/P Provider shall publish on its website and/or Registrar’s website a copy of the P/P Provider service agreement and description of P/P Provider’s
procedures for handling the following: 

  

	 	2.4.1	The process or facilities to report abuse of a domain name registration managed by the P/P Provider; 

  

	 	2.4.2	The process or facilities to report infringement of trademarks or other rights of third parties; 

  

	 	2.4.3	The circumstances under which the P/P Provider will relay communications from third parties to the P/P Customer; 

  

	 	2.4.4	The circumstances under which the P/P Provider will terminate service to the P/P Customer: 

  

	 	2.4.5	The circumstances under which the P/P Provider will reveal and/or publish in the Registration Data Service (Whois) or equivalent service the P/P Customer’s identity and/or contact data; and 

 

	 	2.4.6	A description of the support services offered by P/P Providers to P/P Customers, and how to access those services. 

  

	 	2.5	Escrow of P/P Customer Information. Registrar shall include P/P Customer contact information in its Registration Data Escrow deposits required by Section 3.6 of the Agreement. P/P Customer Information
escrowed pursuant to this Section 2.5 of this Specification may only be accessed by ICANN in the event of the termination of the Agreement or in the event Registrar ceases business operations. 

 

	 	3.	Exemptions. Registrar is under no obligation to comply with the requirements of this specification if it can be shown that: 

  

	 	3.1	Registered Name Holder employed the services of a P/P Provider that is not provided by Registrar, or any of its Affiliates; 

  

	 	3.2	Registered Name Holder licensed a Registered Name to another party (i.e., is acting as a Proxy Service) without Registrar’s knowledge; or 

 

	 	3.3	Registered Name Holder has used P/P Provider contact data without subscribing to the service or accepting the P/P Provider terms and conditions. 

  
 51 

 DATA RETENTION SPECIFICATION 

 

	1.	During the Term of this Agreement, for each Registered Name sponsored by Registrar within a gTLD, Registrar shall collect and securely maintain in its own electronic database (as updated from time to time) the data
specified below: 

  

	 	1.1.	Registrar shall collect the following information from registrants at the time of registration of a domain name (a “Registration”) and shall maintain that information for the duration of Registrar’s
sponsorship of the Registration and for a period of two additional years thereafter: 

  

	 	1.1.1.	First and last name or full legal name of registrant; 

  

	 	1.1.2.	First and last name or, in the event registrant is a legal person, the title of the registrant’s administrative contact, technical contact, and billing contact; 

 

	 	1.1.3.	Postal address of registrant, administrative contact, technical contact, and billing contact; 

  

	 	1.1.4.	Email address of registrant, administrative contact, technical contact, and billing contact; 

  

	 	1.1.5.	Telephone contact for registrant, administrative contact, technical contact, and billing contact; 

  

	 	1.1.6.	WHOIS information, as set forth in the WHOIS Specification; 

  

	 	1.1.7.	Types of domain name services purchased for use in connection with the Registration; and 

  

	 	1.1.8.	To the extent collected by Registrar, “card on file,” current period third party transaction number, or other recurring payment data. 

 

	 	1.2.	Registrar shall collect the following information and maintain that information for no less than one hundred and eighty (180) days following the relevant Interaction: 

 

	 	1.2.1.	Information regarding the means and source of payment reasonably necessary for the Registrar to process the Registration transaction, or a transaction number provided by a third party payment processor;

  

	 	1.2.2.	 Log files, billing records and, to the extent collection and maintenance of such records is commercially practicable or consistent with industry-wide
generally accepted standard practices within the industries in which Registrar operates, other records containing communications source and destination information, including, depending on the method of transmission and without limitation:
(1) Source IP address, HTTP headers, (2) the telephone, text, or fax number; and (3) email address, Skype handle, 

  
 52 

	 	
or instant messaging identifier, associated with communications between Registrar and the registrant about the Registration; and 

 

	 	1.2.3.	Log files and, to the extent collection and maintenance of such records is commercially practicable or consistent with industry-wide generally accepted standard practices within the industries in which Registrar
operates, other records associated with the Registration containing dates, times, and time zones of communications and sessions, including initial registration. 

  

	2.	lf, based on the receipt of either (i) a written legal opinion from a nationally recognized law firm in the applicable jurisdiction that states that the collection and/or retention of any data element specified
herein by Registrar is reasonably likely to violate applicable law (the “Opinion”) or (ii) a ruling of, or written guidance from, a governmental body of competent jurisdiction providing that compliance with the data collection and/or
retention requirements of this Specification violates applicable law, Registrar determines in good faith that the collection and/or retention of any data element specified in this Specification violates applicable law, Registrar may provide written
notice of such determination to ICANN and request a waiver from compliance with specific terms and conditions of this Specification (a “Waiver Request”). Such written notice shall: (i) specify the relevant applicable law, the
allegedly offending data collection and retention elements, the manner in which the collection and/or retention of such data violates applicable law, and a reasonable description of such determination and any other facts and circumstances related
thereto, (ii) be accompanied by a copy of the Opinion and governmental ruling or guidance, as applicable, and (iii) be accompanied by any documentation received by Registrar from any governmental authority, in each case, related to such
determination, and such other documentation reasonably requested by ICANN. Following receipt of such notice, ICANN and Registrar shall discuss the matter in good faith in an effort to reach a mutually acceptable resolution of the matter. Until such
time as ICANN’s Procedure for Handling Whois Conflicts with Privacy Law is modified to include conflicts relating to the requirements of this Specification and if ICANN agrees with Registrar’s determination, ICANN’s office of general
counsel may temporarily or permanently suspend compliance and enforcement of the affected provisions of this Specification and grant the Waiver Request. Prior to granting any exemption hereunder, ICANN will post its determination on its website for
a period of thirty (30) calendar days. Following such modification of ICANN’s Procedure for Handling Whois Conflicts with Privacy Law, all Waiver Requests (whether granted or denied) shall be resolved pursuant to such modified procedures.

  

	3.	 If (i) ICANN has previously waived compliance with the requirements of any requirement of this Data Retention Specification in response to a
Waiver Request from a registrar that is located in the same jurisdiction as Registrar and (ii) Registrar is subject to the same applicable law that gave rise to ICANN’s agreement to grant such waiver, Registrar may request that ICANN grant
a similar waiver, which request shall be approved by ICANN, unless ICANN provides Registrar with a reasonable justification 

  
 53 

	 	
for not approving such request, in which case Registrar may thereafter make a Waiver Request pursuant to Section 2 of this Data Retention Specification. 

 

	4.	Any modification of this Data Retention Specification to address violations of applicable law shall only apply during the period of time that the specific provisions of the applicable law giving rise to such violations
remain in effect. If the applicable law is repealed or modified (or preempted) in a manner that would no longer prohibit the collection and/or retention of data and information as originally specified in this Data Retention Specification, Registrar
agrees that the original version of this Specification apply to the maximum extent permitted by such modified applicable law. 

  
 54 

 REGISTRAR INFORMATION SPECIFICATION 

Registrar shall provide to ICANN the information specified below, which shall be maintained in accordance with Section 3.17 of the Agreement. With regard
to information identified below, ICANN will hold such information pursuant to the disclosure requirements set forth in Section 3.15 of the agreement. 

General Information 
 1. Full legal name of Registrar.

 2. Legal form of the Registrar (e.g., LLC, Corporation, Government Body, Intergovernmental Organization, etc.). 

3. The jurisdiction in which the Registrar’s business is registered for legal and financial purposes. 

4. The Registrar’s business registration number and the name of the authority that issued this number. 

5. Every business name and/or trade name used by the Registrar. 

6. Provide current documentation demonstrating that the Registrar entity is legally established and in good standing. For proof of establishment, provide
charter documents or other equivalent document (e.g., membership agreement) of the entity. If the Registrar is a government body or organization, provide a certified copy of the relevant statute, governmental decision or other instrument under which
the government body or organization has been established. With respect to an entity other than a government body or organization, where no such certificates or documents are available in the Registrar’s jurisdiction, an affidavit drafted and
signed by a notary public or a legal practitioner duly qualified in the courts of the Registrar’s jurisdiction, declaring that the organization is established and in good standing, must be provided. 

7. Correspondence address for the Registrar.* This address will be used for contractual purposes, and the Registrar must be able to accept notices and service
of legal process at this address. No Post Office boxes are allowed. 
 8. Primary phone number where the Registrar can be reached for contractual purposes.

 9. Primary Fax number where the Registrar can be reached for contractual purposes. 

10. Primary Email address where the Registrar can be reached for contractual purposes. 

11. If the location or address of Registrar’s principal place of business is different from the address provided in 7, provide details including address,
phone number, fax number and email address.* Provide ICANN with current documentation demonstrating that the Registrar is legally entitled to do business in the principal place of business. 

  
 55 

 12. Any other addresses where the Registrar will be operated or managed, if different from either its principal
place of business or correspondence address provided above. (If so, please explain.) Provide ICANN with current documentation demonstrating that the Registrar is legally entitled to do business in each location identified. 

13. Primary contact name: 
 Title 

Address 
 Phone number 

Fax number 
 Email address 

14. URL and Location of Port 43 WHOIS server. 
 Ownership,
Directors and Officers Information 
 15. Full name, contact information, and position of any persons or entitles owning at least 5% of the ownership
interest in Registrar’s current business entity. For each person listed, please specify such person’s percentage ownership. 
 16. Full name,
contact information, and position or all directors of the Registrar. 
 17. Full name, contact information, and position of all officers of the Registrar.*
(Officer names and positions must be publicly displayed.) 
 18. Full name, contact information, and position or all senior management and other key
personnel overseeing the provision of Registrar Services. 
 19. For every person or entity mentioned in the answers to questions 15 to 18, indicate if that
person or entity: 
 a) within the past ten years, has been convicted of a felony or of a misdemeanor related to financial activities, or has
been judged by a court to have committed fraud or breach of fiduciary duty, or has been the subject of a judicial determination that is similar or related to any of these; 

b) within the past ten years, has been disciplined by any government or industry regulatory body for conduct involving dishonesty or misuse of
funds of others; 
 c) is currently involved in any judicial or regulatory proceeding that could result in a conviction, judgment,
determination, or discipline of the type specified in items 19(a) or 19(b); or 
 d) is the subject of a disqualification imposed by
ICANN. 
 Provide details if any of the above events in (a)-(d) have occurred. 

  
 56 

 20. List all Affiliated Registrars, if any, and briefly describe the Affiliation. 

21. For any entities listed in item 20, must provide information required in items 1-14 above. 

22. List the ultimate parent entity of the Registrar, if applicable.* 

Other 
 23. Does the Registrar or any of its Affiliates
offer any Privacy Service or Proxy Service (as such terms on defined in the Specification on Privacy and Proxy Registrations)? If yes, list the entities or individuals providing the Privacy Service or Proxy Service. 

24. For any entities listed in item 20, provide Information required in 1-14 above. 

25. Does the Registrar utilize or benefit from the services of Resellers? 

26. If yes, provide a list of all such Resellers known to Registrar. The information specified in this item 26 shall be made available to ICANN upon request.
At such time as ICANN develops a secure method for the receipt and retention of such information, such information shall thereafter be provided to ICANN in accordance with Section 3.17 of the Agreement. 

 

	*	Items marked with “*” must also be published on Registrar’s website. 

  
 57 

 ADDITIONAL REGISTRAR OPERATION SPECIFICATION 

This Specification may be modified by ICANN from time to time after consultation with the Registrar Stakeholder Group (or its successor), provided that such
updates are commercially practical with respect to the registrar industry, taken as a whole. 
  

	1.	DNSSEC 

 Registrar must allow its customers to use DNSSEC upon request by relaying orders
to add, remove or change public key material (e.g., DNSKEY or DS resource records) on behalf of customers to the Registries that support DNSSEC. Such requests shall be accepted and processed in a secure manner and according to industry best
practices. Registrars shall accept any public key algorithm and digest type that is supported by the TLD of interest and appears in the registries posted at: <http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xml>
and <http://www.iana.org/assignments/ds-rr-types/ds-rr-types.xml>. All such requests shall be transmitted to registries using the EPP extensions specified in RFC 5910 or its successors. 

 

	2.	IPv6 

 To the extent that Registrar offers registrants the ability to register nameserver
addresses, Registrar must allow both IPv4 addresses and IPv6 addresses to be specified. 
  

	3.	IDN 

 If the Registrar offers Internationalized Domain Name (“IDN”)
registrations, all new registrations must comply with RFCs 5890, 5891, 5892, 5893 and their successors. Registrar shall also comply with the IDN Guidelines at http://www.icann.org/en/topics/idn/implementation-guidelines.htm which may be
amended, modified, or superseded from time to time. Registrar must use the IDN tables published by the relevant registry. 

  
 58 

 Registrants’ Benefits and Responsibilities 

Domain Name Registrants’ Rights 
  

	1.	Your domain name registration and any privacy/proxy services you may use in conjunction with it must be subject to a Registration Agreement with an ICANN Accredited Registrar. 

 

	 	•	 	You are entitled to review this Registration Agreement at any time, and download a copy for your records. 

  

	2.	You are entitled to accurate and accessible information about: 

  

	 	•	 	The identity or your ICANN Accredited Registrar: 

  

	 	•	 	The identity of any proxy or privacy service provider affiliated with your Registrar; 

  

	 	•	 	Your Registrar’s terms and conditions, including pricing information, applicable to domain name registrations; 

  

	 	•	 	The terms and conditions, including pricing information, applicable to any privacy services offered by your Registrar; 

  

	 	•	 	The customer support services offered by your Registrar and the privacy services provider, and how to access them; 

  

	 	•	 	How to raise concerns and resolve disputes with your Registrar and any privacy services offered by them; and 

  

	 	•	 	Instructions that explain your Registrar’s processes for registering, managing, transferring, renewing, and restoring your domain name registrations, including through any proxy or privacy services made available
by your Registrar. 

  

	3.	You shall not be subject to false advertising or deceptive practices by your Registrar or though any proxy or privacy services made available by your Registrar. This includes deceptive notices, hidden fees, and any
practices that are illegal under the consumer protection law of your residence. 

 Domain Name Registrants’
Responsibilities: 
  

	1.	You must comply with the terms and conditions posted by your Registrar, including applicable policies from your Registrar, the Registry and ICANN. 

 

	2.	You must review your Registrar’s current Registration Agreement, along with any updates. 

  
 59 

	3.	You will assume sole responsibility for the registration and use of your domain name. 

  

	4.	You must provide accurate information for publication in directories such as WHOIS, and promptly update this to reflect any changes. 

 

	5.	You must respond to inquiries from your Registrar within fifteen (15) days, and keep your Registrar account data current. If you choose to have your domain name registration renew automatically, you must also keep
your payment information current. 

  
 60 

 LOGO LICENSE SPECIFICATION 

The Internet Corporation for Assigned Names and Numbers, a California non-profit, public benefit corporation (“ICANN”), and GoDaddy.com, LLC, a
Delaware Limited Liability Company (“Registrar”) have entered into a Registrar Accreditation Agreement (“Registrar Accreditation Agreement”), of which this appendix (“Logo License Specification”) is a part. Definitions
in the Registrar Accreditation Agreement apply in this Logo License Specification. 
 Registrar wishes to acquire from ICANN, and ICANN wishes to grant to
Registrar, a license to use the trademarks listed below the signature block of this Logo License Specification (“Trademarks”) in connection with Registrar’s role as an ICANN-accredited registrar. Pursuant to and subject to the
Registrar Accreditation Agreement, Registrar and ICANN hereby agree as follows: 
 LICENSE 

1. Grant of License. ICANN grants to Registrar a non-exclusive, worldwide right and license to use the Trademarks, during the term of this specification and
solely in connection with the provision and marketing of Registrar Services in order to indicate that Registrar is accredited as a registrar of domain names by ICANN. Except as provided in this subsection and Subsection 2.2 of the Registrar
Accreditation Agreement, Registrar shall not use the Trademarks, any term, phrase, or design which is confusingly similar to the Trademarks or any portion of the Trademarks in any manner whatsoever. 

2. Ownership &Trademarks. Any and all rights in the Trademarks that may be acquired by Registrar shall inure to the benefit of, and are hereby assigned
to, ICANN. Registrar shall not assert ownership of the Trademarks or any associated goodwill. 
 3. No Sublicense. Registrar shall not sublicense any
of its rights under this specification to any other person or entity (including any of Registrar’s resellers) without the prior written approval of ICANN. 

REGISTRATION AND ENFORCEMENT 
 1. Registration. Registration and
any other form of protection for the Trademarks shall only be obtained by ICANN in its name and at its expense. 
 2. Enforcement. Registrar shall promptly
notify ICANN of any actual or suspected infringement of the Trademarks by third parties, including Registrar’s resellers or affiliates. ICANN shall have the sole discretion to initiate and maintain any legal proceedings against such third
parties; Registrar shall not take any such actions without the prior written approval of ICANN; and ICANN shall retain any and all recoveries from such actions. 

3. Further Assurances. Registrar agrees to execute such other documents and to take all such actions as ICANN may request to effect the terms of this
specification, including providing such materials (for example URLs and samples of any promotional materials bearing the Trademarks), cooperation, and assistance as may be reasonably required to 

  
 61 

 
assist ICANN in obtaining, maintaining, and enforcing trademark registration(s) and any other form of protection for the Trademarks. 

TERM AND TERMINATION 
 This Logo License Specification shall be
effective from the date it is signed below by both parties until the Expiration Date, unless this specification or the Registrar Accreditation Agreement is earlier terminated. Each party shall have the right to terminate this specification at any
time by giving the other party written notice. Upon expiration or termination of this specification, Registrar shall immediately discontinue use of the Trademarks. 

IN WITNESS WHEREOF, the parties have caused this Logo License Specification to be executed by their duly authorized representatives. 

 

									
	ICANN	 		 	GoDaddy.com, LLC
					
	By:	 	  /s/ Akram Atallah
	 		 	By:	 	  /s/ Nima Kelly

		 		 		 		 	Name: Nima Kelly
		 		 		 		 	Title: General Counsel
					
		 		 		 		 	Date: Jul. 18, 2013

 TRADEMARKS: 
 1. ICANN
Accredited Registrar 
 2. 
  
 

 

  
 62 

 COMPLIANCE CERTIFICATE 

            , 20         

Pursuant to Section 3.15 of Registrar Accreditation Agreement (the “Agreement”), dated
            , 20        , by and between the Internet Corporation for Assigned Names and Numbers, a California non-profit, public benefit corporation
(“ICANN”), and GoDaddy.com, LLC, a Delaware Limited Liability Company (“Registrar”), the undersigned certifies, in his/her capacity as an offer of the Registrar and not in his/her individual capacity, on behalf of Registrar as
follows: 
 The undersigned is the
                                        (Must be
one of the following: Chief Executive Officer, President, Chief Operating Officer, Chief Financial Officer, or the functional equivalent, therof) of Registrar. 

Registrar has in place processes and procedures intended to establish, maintain, review, test, and modify registrar policies and procedures
reasonably designed to achieve compliance with the Agreement. 
 To the best of the undersigned’s knowledge and belief, Registrar has
performed and complied with all covenants, agreements, obligations and conditions contained in the Agreement that are required to be performed or complied with by it for the calendar year 20        . 

The undersigned signs this certificate as of the date indicated under the title. 

 

			
	GoDaddy.com, LLC
		
	By:	 	  

		 	Name:
		 	Title:

  
 63 

 TRANSITION ADDENDUM TO REGISTRAR ACCREDIATION AGREEMENT 

This Transition Addendum (this “Addendum”) to the Registrar Accreditation Agreement (the “Agreement”) by and between the Internet
Corporation for Assigned Names and Numbers, a California non-profit, public benefit corporation (“ICANN”), and GoDaddy.com, LLC, a Delaware Limited Liability Company (“Registrar”), is dated as of
            , 2013. 
 WHEREAS, ICANN and Registrar entered into the Agreement as of the
date hereof; and 
 WHERES, ICANN acknowledges that implementation by Registrar of certain operational provisions of the Agreement is not possible on
the date hereof and will require a reasonable grace period. 
 NOW THEREFORE, the parties agree as follows: 

1. ICANN will not enforce the following provisions and specification of the Agreement until January 1, 2014: Sections 3.4.1.1, 3.4.1.5, 3.7.10, 3.7.11,
3.12.4, 3.12.7, 3.14, 3.18 and 3.19 of the Agreement; the first sentence of Section 3.7.8 of the Agreement; the WHOIS Accuracy Specification; the Data Retention Specification; and the service level agreements set forth in Section 2.2 of
the Registration Data Directory Service (WHOIS) Specification (collectively, the “Transition Provisions”). 
 2. In Addition, if immediately prior
to the execution of this Addendum Registrar was party to the form of registrar accreditation agreement adopted by ICANN in 2009 (the “2009 RAA”), Registrar may use it existing form of registrant registration agreement until January 1,
2014, provided that such agreement complies with Section 3.7.7 of the 2009 RAA. 
 3. For the calendar year ended December 31, 2013, any
certification required pursuant to Section 3.15 shall not require certification as to compliance with the Transitional Provisions and may acknowledge the permissible use of the registrant registration agreement under Section 2 hereof. 

4. Notwithstanding the foregoing, Registrar agrees to use commercially reasonable efforts to comply with the obligations set forth in the Transition
Provisions and transition to a registrant registration agreement that complies with the terms of the Agreement prior to January 1, 2014. 
 5.
Registrar must be fully compliant with the Transitional Provisions and Section 3.7.7 of the Agreement as of January 1, 2014, at which date this Addendum shall automatically terminate without action by any party, except as it relates to
Section 4 hereof. 
 6. ICANN and the Registrar WHOis Validation Working Group (as defined below) will work together to identify and specify an
appropriate set of tools to enable Registrar to complete the across field validation specified in Section (1e) of the Whois Accuracy Program Specification to the Agreement (the “Across Field Validation”). When such tools are

  
 64 

 
mutually agreed between ICANN and the Registrar Whois Validation Working Group, ICANN shall provide Registrar written notice of such agreement (which notice shall specify and describe the agreed
upon tools). Effective on the one hundred eightieth (180th) calendar day following delivery of such notice by ICANN, Registrar shall comply with the obligation specified in Section 1(e) of the Whois Accuracy Program. Until such time, ICANN
will not enforce compliance with such obligations. 
 For purposes of this Section 6, the Registrar Whois Validation Working Group shall be deemed to
have agreed to such Across Field Validation tools when Approval (as defined below) of the then serving members of the group is obtained through a vote of the group (which vote may be conducted through any verifiable means determined by the group,
included through electronic means). 
 The “Registrar Whois Validation Working Group” means that existing working group whose membership has been
tasked with identifying and specifying a set of tools to enable registrars to complete the Across Field Validation. The membership of the Registrar Whois Validation Working Group shall be made up on volunteering representatives of ICANN-accredited
registrars, and shall initially consist of members currently serving on the existing working group. 
 “Approval” is obtained following a vote of
the Registrar Whois Validation Working Group, if the votes cast in favor of adoption of the proposed Across Field Validation tools by the then serving members of the group are at least two-thirds of the votes cast by such members, with abstentions
or non-votes not being counted as either votes in favor against adoption of such tools. For purposes of the vote of the group as references above, (i) only persons appointed by an ICANN-accredited registrar shall be deemed members of the group
and eligible to cast a vote as described above and (ii) no ICANN-accredited registrar nor group of Affiliated Registrar represented in the Registrar Whois Validation Working Group shall have more than one vote. 

7. Except as set forth in this Addendum, the Agreement shall be in full force and effect, enforceable by the parties in accordance with its terms 

[signature page follows] 

  
 65 

 IN WITNESS WHEREOF, the parties hereto have caused this Addendum to be executed in duplicate by their duly
authorized representatives. 
  

									
	ICANN	 		 	GoDaddy.com, LLC
					
	By:	 	 /s/ Akram Atallah
	 		 	By:	 	 /s/ Nima Kelly

	Name:	 	Akram Atallah	 		 	Name:	 	Nima Kelly
	Title:	 	President, GDD	 		 	Title:	 	General Counsel

  
 66EX-10.17

 Exhibit 10.17 

.COM Registry-Registrar Agreement 

(July 5, 2012) 
 This
Registry-Registrar Agreement (the “Agreement”) is entered into by and between VeriSign, Inc., a Delaware corporation, with a place of business located at 12061 Bluemont Way, Reston, VA 20190, and its wholly owned subsidiaries, including
VeriSign Information Services, Inc. (“VIS”) and VeriSign Naming and Directory Services LLC (“VNDS LLC”) (collectively, “Verisign”), and GoDaddy.com, LLC, a Delaware Corporation, with its principal place of business
located at 14455 North Hayden Rd., Suite 219, Scottsdale , AZ 85260, United States (“Registrar”), through their authorized representatives, and takes effect on the date executed by the final Party (the “Effective Date”). Verisign
and Registrar may be referred to individually as a “Party” and collectively as the “Parties.” 
 WHEREAS, multiple registrars provide
Internet domain name registration services within the .COM top-level domain wherein Verisign operates and maintains certain TLD servers and zone files; 

WHEREAS, Registrar wishes to register second-level domain names in the multiple registrar system for the .COM TLD. 

NOW, THEREFORE, for and in consideration of the mutual promises, benefits and covenants contained herein and for other good and valuable consideration, the
receipt, adequacy and sufficiency of which are hereby acknowledged, Verisign and Registrar, intending to be legally bound, hereby agree as follows: 
  

	1.	DEFINITIONS 

 1.1. “Confidential Information” means all information and materials
including, without limitation, computer software, data, information, databases, protocols, reference implementation and documentation, and functional and interface specifications, provided by the disclosing party to the receiving party and marked or
otherwise identified as Confidential, provided that if a communication is oral, the Disclosing Party will notify the Receiving Party in writing within 15 days of the disclosure. 

1.2. “DNS” refers to the Internet domain name system. 1.3. 

1.3. “EPP” means the Extensible Provisioning Protocol. 1.4. 

1.4. “ICANN” refers to the Internet Corporation for Assigned Names and Numbers. 1.5. 

1.5. “IP” means Internet Protocol. 

1.6. The “Licensed Product” refers to the intellectual property required to access the Supported Protocol, and to the APIs, and software,
collectively. 
 1.7. “Personal Data” refers to data about any identified or identifiable natural person. 

 1.8. “Registered Name” refers to a domain name within the domain of the Registry TLD, whether
consisting of two or more (e.g., john.smith.name) levels, about which Verisign or an affiliate engaged in providing registry services maintains data in a registry database, arranges for such maintenance, or derives revenue from such maintenance. A
name in a registry database may be a Registered Name even though it does not appear in a TLD zone file (e.g., a registered but inactive name). 

1.9. “Registry TLD” means the .COM TLD. 

1.10. “Supported Protocol” means Verisign’s implementation of EPP, or any successor protocols, supported by the System. 

1.11. The “System” refers to the multiple registrar system operated by Verisign for registration of Registered Names in the Registry TLD.

 1.12. A “TLD” is a top-level domain of the DNS. 
  

	2.	OBLIGATIONS OF THE PARTIES 

 2.1. System Operation and Access. Throughout the term of this
Agreement, Verisign shall operate the System and provide Registrar with access to the System to transmit domain name registration information for the Registry TLD to the System. Nothing in this Agreement entitles Registrar to enforce any agreement
between Verisign and ICANN. 
 2.2. Maintenance of Registrations Sponsored by Registrar. Subject to the provisions of this Agreement, ICANN
requirements, and Verisign requirements, including, without limitation, those authorized by ICANN, Verisign shall maintain the registrations of Registered Names sponsored by Registrar in the System during the term for which Registrar has paid the
fees required by Subsection 5.1. 
 2.3. Distribution of EPP, APIs and Software. No later than three (3) business days after the
Effective Date of this Agreement, Verisign shall make available to Registrar (i) full documentation of the Supported Protocol, (ii) “C” and/or “Java” application program interfaces (“APIs”) to the Supported
Protocol with documentation, and (iii) reference client software (“Software”) that will allow Registrar to develop its system to register second-level domain names through the System for the Registry TLD. If Verisign elects to modify
or upgrade the APIs and/or Supported Protocol, Verisign shall provide updated APIs to the Supported Protocol with documentation and updated Software to Registrar promptly as such updates become available. 

2.4. Registrar Responsibility for Customer Support. Registrar shall provide (i) support to accept orders for registration, cancellation,
modification, renewal, deletion or transfer of Registered Names and (ii) customer service (including domain name record support) and billing and technical support to Registered Name Holders. Registrar shall, consistent with ICANN policy,
provide to Registered Name Holders emergency contact or 24/7 support information for critical situations such as domain name hijacking. 

  
 -2- 

 2.5. Data Submission Requirements. As part of its registration and sponsorship of Registered Names in the
Registry TLD, Registrar shall submit complete data as required by technical specifications of the System that are made available to Registrar from time to time. Registrar shall submit any corrections or updates from a Registered Name Holder relating
to the registration information for a Registered Name to Verisign in a timely manner. 
 2.6. License. Registrar grants Verisign as Registry a
non-exclusive, royalty-free, nontransferable worldwide limited license to the data elements consisting of the Registered Name, the IP addresses of nameservers, the identity of the registering registrar, and other data required or permitted by
technical specifications of the Registry System as made available to Registrar by Verisign from time to time, for propagation of and the provision of authorized access to the TLD zone files or as otherwise required or permitted by Verisign’s
Registry Agreement with ICANN concerning the operation of the Registry TLD, as may be amended from time to time. 
 2.7. Registrar’s Registration
Agreement and Domain Name Dispute Policy. Registrar shall have in effect an electronic or paper registration agreement with the Registered Name Holder which may be amended from time to time by Registrar, provided a copy is made available to
Verisign. Registrar shall provide a copy of Registrar’s registration agreement upon request for same by Verisign. Registrar shall include in its registration agreement those terms required by this Agreement and other terms that are consistent
with Registrar’s obligations to Verisign under this Agreement. Registrar shall employ in its domain name registration business the Uniform Domain Name Dispute Resolution Policy and the Inter-Registrar Transfer Policy, each as adopted by the
ICANN Board on 26 August 1999 and 7 November 2008 and as each may be amended from time to time. In its registration agreement with each Registered Name Holder, Registrar shall require such Registered Name Holder to: 

 

	 	(a)	acknowledge and agree that Verisign reserves the right to deny, cancel or transfer any registration or transaction, or place any domain name(s) on registry lock, hold or similar status, as it deems necessary, in its
unlimited and sole discretion: (1) to comply with specifications adopted by any industry group generally recognized as authoritative with respect to the Internet (e.g., RFCs), (2) to correct mistakes made by Verisign or any Registrar in
connection with a domain name registration, or (3) for the non-payment of fees to Verisign; and 

  

	 	(b)	indemnify, defend and hold harmless Verisign and its subcontractors, and its and their directors, officers, employees, agents, and affiliates from and against any and all claims, damages, liabilities, costs and
expenses, including reasonable legal fees and expenses arising out of or relating to, for any reason whatsoever, the Registered Name Holder’s domain name registration. The registration agreement shall further require that this indemnification
obligation survive the termination or expiration of the registration agreement. 

 2.8. Secure Connection. Registrar agrees to develop
and employ in its domain name registration business all necessary technology and restrictions to ensure that its connection to the System is secure. All data exchanged between Registrar’s system and the System shall be protected to avoid
unintended disclosure of information. Registrar shall employ commercially reasonable measures to 

  
 -3- 

 
prevent its access to the Registry System granted hereunder from being used to (i) allow, enable, or otherwise support the transmission by e-mail, telephone, or facsimile of mass
unsolicited, commercial advertising or solicitations to entities other than its own existing customers; or (ii) enable high volume, automated, electronic processes that send queries or data to the systems of Verisign, any other registry
operated under an agreement with ICANN, or any ICANN-accredited registrar, except as reasonably necessary to register domain names or modify existing registrations. 

Each EPP session shall be authenticated and encrypted using two-way secure socket layer (“SSL”) protocol. Registrar agrees to authenticate every EPP
client connection with the System using both an X.509 server certificate issued by a commercial Certification Authority identified by the Registry and its Registrar password, which it shall disclose only to its employees with a need to know.
Registrar agrees to notify Registry within four (4) hours of learning that its Registrar password has been compromised in any way or if its server certificate has been revoked by the issuing Certification Authority or compromised in any way.

 Upon prior written notification to Registrar, Verisign may require other industry standard security provisions, practices or technology to ensure that
the Registry System is secure and stable, which Verisign may adopt from time to time in its sole and complete discretion. 
 2.8.1. Handling of Personal
Data. Verisign shall notify Registrar of the purposes for which Personal Data submitted to Verisign by Registrar is collected, the intended recipients (or categories of recipients) of such Personal Data, and the mechanism for access to and
correction of such Personal Data. Verisign shall take reasonable steps to protect Personal Data from loss, misuse, unauthorized disclosure, alteration or destruction. Verisign shall not use or authorize the use of Personal Data in a way that is
incompatible with the notice provided to registrars. Verisign may from time to time use the demographic data collected for statistical analysis, provided that this analysis will not disclose individual Personal Data and provided that such use is
compatible with the notice provided to registrars regarding the purpose and procedures for such use. 
 2.8.2. Authorization Codes. Registrar
shall not provide identical Registrar-generated authorization <authinfo> codes for domain names registered by different registrants with the same Registrar. Verisign in its sole discretion may choose to modify <authinfo> codes for a
given domain and shall notify the sponsoring registrar of such modifications via EPP compliant mechanisms (i.e., EPP<poll> or EPP<domain:Info>). Documentation of these mechanisms shall be made available to Registrar by Verisign. The
Registrar shall provide the Registered Name Holder with timely access to the authorization code along with the ability to modify the authorization code within five (5) calendar days. 

2.9. Domain Name Lookup Capability. Registrar agrees to employ in its domain name registration business Verisign’s registry domain name lookup
capability to determine if a requested domain name is available or currently unavailable for registration. Registrar also agrees, at its expense, to provide an interactive web page and a port 43 Whois service providing free public query-based access
to up-to-date (i.e., updated at least daily) data concerning all active Registered Names sponsored by Registrar for the Registry TLD. The data accessible shall consist of elements that are designated from time to time according to an ICANN adopted
specification or policy or the Registrar Accreditation Agreement between Registrar and ICANN. 

  
 -4- 

 2.10. Transfer of Sponsorship of Registrations. Registrar agrees to implement transfers of Registered Name
registrations from another registrar to Registrar and vice versa pursuant to the Inter-Registrar Transfer Policy as may be amended from time to time by ICANN (the “Transfer Policy”). 

2.11. Time. Registrar agrees that in the event of any dispute concerning the time of the entry of a domain name registration into the registry
database, the time shown in the Verisign records shall control. 
 2.12. Compliance with Operational Requirements. Registrar shall comply with each
of the following requirements, and further shall include in its registration agreement with each Registered Name Holder, as applicable, an obligation for such Registered Name Holder to comply with each of the following requirements: 

 

	 	(a)	ICANN standards, policies, procedures, and practices for which Verisign has monitoring responsibility in accordance with the Registry Agreement or other arrangement with ICANN; and 

 

	 	(b)	Operational standards, policies, procedures, and practices for the Registry TLD established from time to time by Verisign in a non- arbitrary manner and applicable to all registrars (“Operational
Requirements”), including affiliates of Verisign, and consistent with Verisign’s Registry Agreement with ICANN, as applicable, upon Verisign’s notification to Registrar of the establishment of those terms and conditions.

 2.13. Resolution of Technical Problems or Breach of Agreement. Registrar agrees to employ necessary employees, contractors, or
agents with sufficient technical training and experience to respond to and fix all technical problems concerning the use of the Supported Protocol, the APIs and the systems of Verisign in conjunction with Registrar’s systems. Registrar agrees
that in the event of significant degradation of the System or other emergency, or upon Registrar’s violation of Operational Requirements or breach of this Agreement, Verisign may, in its sole discretion, temporarily suspend or restrict access
to the System. Such temporary suspensions or restrictions shall be applied in a nonarbitrary manner and shall apply fairly to any registrar similarly situated. 

2.14. Prohibited Doman Name Registrations. In Addition to complying with ICANN standards, policies, procedures, and practices limiting domain names
that may be registered, Registrar agrees to comply with applicable statutes and regulations limiting the domain names that may be registered. 
 2.15.
ICANN Requirements. Verisign’s obligations hereunder are subject to modification at any time as the result of ICANN-mandated requirements and consensus policies. Notwithstanding anything in this Agreement to the contrary, Registrar shall
comply with any such ICANN requirements in accordance with the timeline defined by ICANN. 
 2.16. Accredited Registrar. During the term of
this Agreement, Registrar shall maintain in full force and effect its accreditation by ICANN as a registrar for the Registry TLD. 

  
 -5- 

	3.	LICENSE 

 3.1. License Grant. Subject to the terms and conditions of this Agreement, Verisign
hereby grants Registrar and Registrar accepts a non-exclusive, royalty-free, nontransferable, worldwide limited license to use for the term and purposes of this Agreement the Licensed Product, as well as updates and redesigns thereof, to provide
domain name registration services in the Registry TLD only and for no other purpose. The Licensed Product, as well as updates and redesigns thereof, will enable Registrar to register domain names in the Registry TLD with the Registry on behalf of
its Registered Name Holders. Registrar, using the Licensed Product, as well as updates and redesigns thereof, will be able to invoke the following operations on the System: (i) check the availability of a domain name, (ii) register a
domain name, (iii) re-register a domain name, (iv) cancel the registration of a domain name it has registered, (v) update the nameservers of a domain name, (vi) transfer a domain name from another registrar to itself with proper
authorization, (vii) query a domain name registration record, (viii) register a nameserver, (ix) update the IP addresses of a nameserver, (x) delete a nameserver, (xi) query a nameserver, and (xii) establish and end an
authenticated session. 
 3.2. Limitations on Use. Notwithstanding any other provisions in this Agreement, except with the written consent of
Verisign, Registrar shall not: (i) sublicense the Licensed Product or otherwise permit any use of the Licensed Product by or for the benefit of any party other than Registrar, (ii) publish, distribute or permit disclosure of the Licensed
Product other than to employees, contractors, and agents of Registrar for use in Registrar’s domain name registration business, (iii) decompile, reverse engineer, copy or re-engineer the Licensed Product for any unauthorized purpose,
(iv) use or permit use of the Licensed Product in violation of any federal, state or local rule, regulation or law, or for any unlawful purpose. Registrar agrees to employ the necessary measures to prevent its access to the System granted
hereunder from being used to (i) allow, enable, or otherwise support the transmission by e-mail, telephone, or facsimile of mass unsolicited, commercial advertising or solicitations to entities other than Registrar’s customers; or
(ii) enable high volume, automated, electronic processes that send queries or data to the systems of Verisign or any ICANN-Accredited Registrar, except as reasonably necessary to register domain names or modify existing registrations. 

3.3. Changes to Licensed Materials. Verisign may from time to time replace or make modifications to the Licensed Product licensed hereunder. Verisign
will provide Registrar with at least ninety (90) days notice prior to the implementation of any material changes to the Supported Protocol, APIs or software licensed hereunder. 

 

	4.	SUPPORT SERVICES 

 4.1. Engineering Support. Verisign agrees to provide Registrar with reasonable
engineering telephone support (between the hours of 9 a.m. to 5 p.m. EST or at such other times as may be mutually agreed upon) to address engineering issues arising in connection with Registrar’s use of the System. 

4.2. Customer Service Support. During the term of this Agreement, Verisign will provide reasonable telephone, web based and e-mail customer service
support to Registrar, not Registered Name Holder or prospective customers of Registrar, for nontechnical issues solely relating to the 

  
 -6- 

 
System and its operation. Verisign will provide Registrar with a telephone number and e-mail address for such support during implementation of the Supported Protocol, APIs and Software.
First-level telephone support will be available on a 7-day/24-hour basis. 
  

	5.	FEES 

 5.1. Registration Fees. 

 

	 	(a)	Registrar agrees to pay Verisign the non-refundable fees set forth in Exhibit A for initial and renewal registrations and other incidental and ancillary services provided by Verisign (collectively, the
“Registration Fees”). 

  

	 	(b)	Verisign reserves the right to adjust the Registration Fees, provided that any price increase shall be made only upon six (6) months prior notice to Registrar (by e-mail, hand, by registered mail, or by courier or
express delivery service), and provided that such adjustments are consistent with Verisign’s Registry Agreement with ICANN. 

  

	 	(c)	Registrars shall provide Verisign a payment security comprised of an irrevocable letter of credit or cash deposit (the “Payment Security”). The amount of the Payment Security establishes Registrar’s
credit limit in the Verisign System and should be based on anticipated monthly level of registrations and other billable transactions. Registrar agrees to modify its Payment Security to support increases in billable transaction volumes as required
by the Verisign credit and billing policies. Verisign will invoice Registrar monthly in arrears for each month’s Registration Fees. All Registration Fees are due immediately upon receipt of Verisign’s monthly invoices. In order to satisfy
any outstanding account balances, Verisign may draw upon the Registrar’s Payment Security. If this occurs, Registrar agrees to replenish Payment Security to the pre-draw level immediately upon completion of draw. If Registrar’s Payment
Security is depleted, registration of domain names for the Registrar will be suspended and new registrations will not be accepted until the Payment Security is replenished. 

 

	 	(d)	The Registration Fees due under this Agreement are exclusive of tax. All taxes, duties, fees and other governmental charges of any kind (including sales, turnover, services, use and value-added taxes, but excluding
taxes based on the net income of Verisign) which are imposed by or under the authority of any government or any political subdivision thereof on the fees for any services, software and/or hardware shall be borne by Registrar and shall not be
considered a part of, a deduction from or an offset against such Registration Fees. All payments due to Verisign shall be made without any deduction or withholding on account of any tax, duty, charge or penalty except as required by law, in which
case, the sum payable by Registrar from which such deduction or withholding is to be made shall be increased to the extent necessary to ensure that, after making such deduction or withholding, Verisign receives and retains (free from any liability
with respect thereof) a net sum equal to the sum it would have received but for such deduction or withholding being required. 

  
 -7- 

 5.2. Change in Registrar Sponsoring Domain Name. Registrar may assume sponsorship of a Registered Name
Holder’s existing domain name registration from another registrar by following the Transfer Policy. 
  

	 	(a)	For each transfer of the sponsorship of a domain-name registration under the Transfer Policy, Registrar agrees to pay Verisign the renewal registration fee associated with a one-year extension, as set forth above. The
losing registrar’s Registration Fees will not be refunded as a result of any such transfer. 

  

	 	(b)	For a transfer approved by ICANN under Part B of the Transfer Policy, Registrar agrees to pay Verisign US $0 (for transfers of 50,000 names or fewer) or US $50,000 (for transfers of more than 50,000 names).

 Fees under this Section 5.2 shall be due immediately upon receipt of Verisign’s invoice pursuant to the Payment Security. 

5.3. Charges for ICANN Fees. Registrar agrees to pay to Verisign, within five (5) days of the date when due, any variable registry-level fees paid
by Verisign to ICANN, which fees shall be secured by the Payment Security. The fee will consist of two components; each component will be calculated by ICANN for each registrar: 

 

	 	(a)	The transactional component of the Variable Registry-Level Fee shall be specified by ICANN in accordance with the budget adopted by the ICANN Board of Directors for each fiscal year but shall not exceed the amount set
forth in the Registry Agreement. 

  

	 	(b)	The per-registrar component of the Variable Registry-Level Fee shall be specified by ICANN in accordance with the budget adopted by the ICANN Board of Directors for each fiscal year, but the sum of the per registrar
fees calculated for all registrars shall not exceed the total Per-Registrar Variable funding established pursuant to the approved ICANN Budget. 

5.4. Non-Payment of Fees. Timely payment of fees owing under this Section 5 is a material condition of performance under this Agreement. In the
event that Registrar fails to pay its fees within five (5) days of the date when due, Verisign may: (i) stop accepting new initial or renewal registrations from Registrar; (ii) delete the domain names associated with invoices not paid
in full from the Registry database; (iii) give written notice of termination of this Agreement pursuant to Section 6.1(b) below; and (iv) pursue any other remedy under this Agreement. 

 

	6.	MISCELLANEOUS 

 6.1. Term of Agreement and Termination. 

 

	 	(a)	 Term of the Agreement; Revisions. The duties and obligations of the Parties under this Agreement shall apply from the Effective Date through
and including the last day of the calendar month sixty (60) months from the Effective Date (the “Initial Term”). Upon conclusion of the Initial Term, all provisions of this Agreement will automatically renew for successive five
(5) year renewal periods until the Agreement 

  
 -8- 

	 	
has been terminated as provided herein, Registrar elects not to renew, or Verisign ceases to operate the registry for the Registry TLD. In the event that revisions to Verisign’s
Registry-Registrar Agreement are approved or adopted by ICANN, Registrar shall have thirty (30) days from the date of notice of any such revision to review, comment on, and execute an amendment substituting the revised agreement in place of
this Agreement, or Registrar may, at its option exercised within such thirty (30) day period, terminate this Agreement immediately by giving written notice to Verisign; provided, however, that in the event Verisign does not receive such
executed amendment or notice of termination from Registrar within such thirty (30) day period of the date of the notice, Registrar shall be deemed to have executed such amendment as of the thirty-first (31st) day after the date of the
notice. 

  

	 	(b)	Termination For Cause. In the event that either Party materially breaches any term of this Agreement including any of its representations and warranties hereunder and such breach is not substantially cured within
thirty (30) calendar days after written notice thereof is given by the other Party, then the non-breaching Party may, by giving written notice thereof to the other Party, terminate this Agreement as of the date specified in such notice of
termination. 

  

	 	(c)	Termination at Option of Registrar. Registrar may terminate this Agreement at any time by giving Verisign thirty (30) days notice of termination. 

 

	 	(d)	Termination Upon Loss of Registrar’s Accreditation. This Agreement shall terminate immediately in the event Registrar’s accreditation for the Registry TLD by ICANN, or its successor, is terminated or
expires without renewal. 

  

	 	(e)	Termination in the Event that Successor Registry Operator is Named. This Agreement shall terminate in the event that the U.S. Department of Commerce or ICANN, as appropriate, designates another entity to operate
the registry for the Registry TLD. 

  

	 	(f)	Termination in the Event of Bankruptcy. Either Party may terminate this Agreement if the other Party is adjudged insolvent or bankrupt, or if proceedings are instituted by or against a Party seeking relief,
reorganization or arrangement under any laws relating to insolvency, or seeking any assignment for the benefit of creditors, or seeking the appointment of a receiver, liquidator or trustee of a Party’s property or assets or the liquidation,
dissolution or winding up of a Party’s business. 

  

	 	(g)	 Effect of Termination. Upon expiration or termination of this Agreement, Verisign will, to the extent it has the authority to do so,
complete the registration of all domain names processed by Registrar prior to the date of such expiration or termination, provided that Registrar’s payments to Verisign for Registration Fees are current and timely. Immediately upon any
expiration or termination of this Agreement, Registrar shall (i) transfer its sponsorship of Registered Name registrations to another licensed registrar(s) of the Registry, in compliance with Part B of the Transfer Policy, or any other
procedures established or approved by the U.S. Department of Commerce or 

  
 -9- 

	 	
ICANN, as appropriate, and (ii) either return to Verisign or certify to Verisign the destruction of all Confidential Information it has received under this Agreement. In the event of
termination, Verisign reserves the right to immediately contact any and all Registered Name Holders to facilitate the orderly and stable transition of Registered Name Holders to other ICANN-accredited registrars. All fees owing to Verisign shall
become immediately due and payable. 

  

	 	(h)	Survival. In the event of termination of this Agreement, the following shall survive: (i) Sections 2.6 (License), 2.7 (Registrar’s Registration Agreement and Domain Name Dispute Policy), 2.8.1
(Handling of Personal Data), 6.1(g) (Effect of Termination), 6.1(h) (Survival), 6.2 (No Third Party Beneficiaries; Relationship of the Parties), 6.6 (Attorneys’ Fees), 6.7 (Dispute Resolution; Choice of Law; Venue), 6.8 (Notices), 6.10 (Use of
Confidential Information), 6.11 (Delays or Omissions; Waivers), 6.12 (Limitation of Liability), 6.13 (Construction), 6.14 (Intellectual Property), 6.15(c) (Disclaimer of Warranties), 6.16 (Indemnification), and 6.17 (Entire Agreement; Severability);
(ii) the Registered Name Holder’s obligations to indemnify, defend, and hold harmless Verisign, as stated in Section 2.7(a)(6); and (iii) Registrar’s payment obligations as set forth in Section 5 with respect to fees
incurred during the term of this Agreement. Neither Party shall be liable to the other for damages of any sort resulting solely from terminating this Agreement in accordance with its terms but each Party shall be liable for any damage arising from
any breach by it of this Agreement. 

 6.2. No Third Party Beneficiaries; Relationship of the Parties. This Agreement does not provide
and shall not be construed to provide third parties (i.e., non-parties to this Agreement), including any Registered Name Holder, with any remedy, claim, cause of action or privilege. Nothing in this Agreement shall be construed as creating an
employer-employee or agency relationship, a partnership or a joint venture between the Parties. 
 6.3. Force Majeure. Neither Party shall be
responsible for any failure to perform any obligation (other than payment obligations) or provide service hereunder because of any Act of God, strike, work stoppage, governmental acts or directives, war, riot or civil commotion, equipment or
facilities shortages which are being experienced by providers of telecommunications services generally, or other similar force beyond such Party’s reasonable control. 

6.4. Further Assurances. Each Party hereto shall execute and/or cause to be delivered to each other Party hereto such instruments and other documents,
and shall take such other actions, as such other Party may reasonably request for the purpose of carrying out or evidencing any of the transactions contemplated by this Agreement. 

6.5. Amendment in Writing. Except as otherwise provided in this Agreement, any amendment or supplement to this Agreement shall be in writing and duly
executed by both Parties. Any new services approved by ICANN and purchased by Registrar will be subject to such terms and conditions as may be established by Verisign through an appendix to this Agreement or such other agreement executed by
Registrar and Verisign. 

  
 -10- 

 6.6. Attorneys’ Fees. If any legal action or other legal proceeding (including arbitration) relating
to the performance under this Agreement or the enforcement of any provision of this Agreement is brought against either Party hereto, the prevailing Party shall be entitled to recover reasonable attorneys’ fees, costs and disbursements (in
addition to any other relief to which the prevailing Party may be entitled). 
 6.7. Dispute Resolution; Choice of Law; Venue. The Parties shall
attempt to resolve any disputes between them prior to resorting to litigation. This Agreement is to be construed in accordance with and governed by the internal laws of the Commonwealth of Virginia, United States of America without giving effect to
any choice of law rule that would cause the application of the laws of any jurisdiction other than the internal laws of the Commonwealth of Virginia to the rights and duties of the Parties. Any legal action or other legal proceeding relating to this
Agreement or the enforcement of any provision of this Agreement shall be brought or otherwise commenced in any state or federal court located in the eastern district of the Commonwealth of Virginia. Each Party to this Agreement expressly and
irrevocably consents and submits to the jurisdiction and venue of each state and federal court located in the eastern district of the Commonwealth of Virginia (and each appellate court located in the Commonwealth of Virginia) in connection with any
such legal proceeding. 
 6.8. Notices. Any notice or other communication required or permitted to be delivered to any Party under this Agreement
shall be in writing and shall be deemed properly delivered, given and received when delivered (by hand, by registered mail, by courier or express delivery service, by e-mail or by telecopier during business hours) to the address or telecopier number
set forth beneath the name of such Party below, unless Party has given a notice of a change of address in writing: 
 if to Registrar: 

 

			
		  	Current Address
	Customer Name	  	GoDaddy.com, LLC
	Attention	  	General Counsel
	Physical Address	  	14455 N. Hayden Road - Suite 219
	City	  	Scottsdale
	State	  	Arizona
	Postal	  	85260
	Country	  	United States
	Telephone Number	  	480.505.8800
	Facsimile Number	  	480.624.2546
	E-Mail	  	legal@godaddy.com

  
 -11- 

 with a COPY to: 
  

			
		  	Current Address
	Customer Name	  	GoDaddy.com, LLC
	Attention	  	
	Physical Address	  	
	City	  	
	State	  	
	Postal	  	
	Country	  	
	Telephone Number	  	
	Facsimile Number	  	
	E-Mail	  	

 if to Verisign: 

Vice President, VNDS LLC c/o VeriSign, Inc. 
 12061 Bluemont Way

 Reston, VA 20190 
 Telephone: +1 703 948 3200 

Facsimile: +1 703 948 3977 
 E-Mail: TBP 

with copies to: 
 VeriSign, Inc. 

12061 Bluemont Way 
 Reston, VA 20190 

Telephone: +1 703 948 3200 
 Facsimile: +1 703 948 3977 

E-Mail: cao@verisign-grs.com 
 - and - 

General Counsel 
 VeriSign, Inc. 

12061 Bluemont Way 
 Reston, VA 20190 

Telephone: +1 703 948 3200 
 Facsimile: +1 703 450 7492 

E-Mail: legal-east@verisign.com 

  
 -12- 

 if to VNDS LLC only: 

Managing Director, VNDS LLC do 
 VeriSign, Inc. 

12061 Bluemont Way 
 Reston, VA 20190 

Telephone: +1 703 948 3200 
 Facsimile: +1 703 948 3977 

E-Mail: TBP 
 with copies to: 

(1) VeriSign, Inc.; and 
 (2) General Counsel, VeriSign, Inc.

 (addresses above) 
 If to VIS only: 

Managing Director, VIS c/o VeriSign, Inc. 
 12061 Bluemont Way

 Reston, VA 20190 
 Telephone: +1 703 948 3200 

Facsimile: +1 703 948 3977 
 E-Mail: TBP 

with copies to: 
 (1) VeriSign, Inc.; and 

(2) General Counsel, VeriSign, Inc. 
 (addresses above) 

6.9. Assignment/Sublicense. Except as otherwise expressly provided herein, the provisions of this Agreement shall inure to the benefit of and be
binding upon, the successors and permitted assigns of the Parties hereto. Registrar shall not assign, sublicense or transfer its rights or obligations under this Agreement to any third person without the prior written consent of Verisign. Verisign
may assign its rights or obligations under this Agreement to an affiliate without the consent of Registrar. 
 6.9.1. Assignment in Connection with
Assignment of Agreement with ICANN. In the event that Verisign’s Registry Agreement with ICANN for the Registry TLD is validly assigned, Verisign’s rights under this Agreement shall be automatically assigned to the assignee of the
Registry Agreement, provided that the assignee assumes the duties of Verisign under this Agreement. In the event that Registrar’s accreditation agreement with ICANN for the Registry TLD is validly assigned, Registrar’s rights under this
Agreement shall be automatically assigned to the assignee of the accreditation agreement, provided that the subsequent registrar assumes the duties of Registrar under this Agreement. 

  
 -13- 

 6.10. Use of Confidential Information. During the term of this Agreement, each Party (the “Disclosing
Party”) may disclose its Confidential Information to the other Party (the “Receiving Party”). Each Party’s use and disclosure of Confidential Information disclosed hereunder are subject to the following terms and conditions: 

 

	 	(a)	The Receiving Party shall treat as strictly confidential, and use all reasonable efforts to preserve the secrecy and confidentiality of, all Confidential Information of the Disclosing Party, including implementing
reasonable physical security measures and operating procedures. 

  

	 	(b)	The Receiving Party agrees that it will use any Confidential Information of the Disclosing Party solely for the purpose of exercising its right or performing its obligations under this Agreement and for no other
purposes whatsoever. 

  

	 	(c)	The Receiving Party shall make no disclosures whatsoever of any Confidential Information of the Disclosing Party to others; provided, however, that if the Receiving Party is a corporation, partnership, or similar
entity, disclosure is permitted to the Receiving Party’s officers, employees, contractors and agents who have a demonstrable need to know such Confidential Information, provided the Receiving Party shall advise such personnel of the
confidential nature of the Confidential Information and take reasonable steps to maintain the confidentiality thereof. 

  

	 	(d)	The Receiving Party shall not modify or remove any confidentiality legends and/or copyright notices appearing on any Confidential Information of the Disclosing Party. 

 

	 	(e)	The Receiving Party agrees not to prepare any derivative works based on the Confidential Information. 

  

	 	(f)	Notwithstanding the foregoing, this Subsection 6.10 imposes no obligation upon the parties with respect to information that (i) is disclosed in the absence of a confidentiality agreement and such disclosure was
agreed to by the Disclosing Party in writing prior to such disclosure; or (ii) is or has entered the public domain through no fault of the Receiving Party; or (iii) is known by the Receiving Party prior to the time of disclosure; or
(iv) is independently developed by the Receiving Party without use of the Confidential Information; or (v) is made generally available by the Disclosing Party without restriction on disclosure, or (vi) is required to be disclosed by
law, regulation or court order; provided, that in the event the Receiving Party is required by law, regulation or court order to disclose any of Disclosing Party’s Confidential Information, Receiving Party will promptly notify Disclosing Party
in writing prior to making any such disclosure in order to facilitate Disclosing Party seeking a protective order or other appropriate remedy from the proper authority, at the Disclosing Party’s expense. Receiving Party agrees to cooperate with
Disclosing Party in seeking such order or other remedy. Receiving Party further agrees that if Disclosing Party is not successful in precluding the requesting legal body from requiring the disclosure of the Confidential Information, it will furnish
only that portion of the Confidential Information that is legally required. 

  
 -14- 

 6.11. Delays or Omissions; Waivers. No failure on the part of either Party to exercise any power, right,
privilege or remedy under this Agreement, and no delay on the part of either Party in exercising any power, right, privilege or remedy under this Agreement, shall operate as a waiver of such power, right, privilege or remedy; and no single or
partial exercise or waiver of any such power, right, privilege or remedy shall preclude any other or further exercise thereof or of any other power, right, privilege or remedy. No Party shall be deemed to have waived any claim arising out of this
Agreement, or any power, right, privilege or remedy under this Agreement, unless the waiver of such claim, power, right, privilege or remedy is expressly set forth in a written instrument duly executed and delivered on behalf of such Party; and any
such waiver shall not be applicable or have any effect except in the specific instance in which it is given. 
 6.12. Limitation of Liability. IN NO
EVENT WILL VERISIGN BE LIABLE TO REGISTRAR FOR ANY SPECIAL, INDIRECT, INCIDENTAL, PUNITIVE, EXEMPLARY OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES RESULTING FROM LOSS OF PROFITS, ARISING OUT OF OR IN CONNECTION WITH THIS AGREEMENT, EVEN IF VERISIGN HAS
BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.IN NO EVENT SHALL THE MAXIMUM AGGREGATE LIABILITY OF THE PARTIES EXCEED THE LESSER OF (I) THE TOTAL AMOUNT PAID TO VERISIGN UNDER THE TERMS OF THIS AGREEMENT FOR THE IMMEDIATELY PRECEDING TWELVE
(12) MONTH PERIOD, OR (ii) $500,000 USD. 
 6.13. Construction. The Parties agree that any rule of construction to the effect that
ambiguities are to be resolved against the drafting Party shall not be applied in the construction or interpretation of this Agreement. 
 6.14.
Intellectual Property. Subject to Section 2.6 above, each Party will continue to independently own its intellectual property, including all patents, trademarks, trade names, service marks, copyrights, trade secrets, proprietary processes
and all other forms of intellectual property. 
 6.15. Representations and Warranties 

 

	 	(a)	Registrar. Registrar represents and warrants that: (1) it is a corporation duly incorporated, validly existing and in good standing under the law of the State of Delaware, (2) it has all requisite
corporate power and authority to execute, deliver and perform its obligations under this Agreement, (3) it is, and during the term of this Agreement will continue to be, accredited by ICANN or its successor, pursuant to an accreditation
agreement dated after May 21, 2009 (4) the execution, performance and delivery of this Agreement has been duly authorized by Registrar, and (5) no further approval, authorization or consent of any governmental or regulatory authority
is required to be obtained or made by Registrar in order for it to enter into and perform its obligations under this Agreement. 

  

	 	(b)	 Verisign. Verisign represents and warrants that: (1) it is a corporation duly incorporated, validly existing and in good standing under
the laws of the State of Delaware, (2) it has all requisite corporate power and authority to execute, deliver and perform its obligations under this Agreement, (3) the execution, performance and

  
 -15- 

	 	
delivery of this Agreement has been duly authorized by Verisign, and (4) no further approval, authorization or consent of any governmental or regulatory authority is required to be obtained
or made by Verisign in order for it to enter into and perform its obligations under this Agreement. 

  

	 	(c)	Disclaimer of Warranties. The EPP, APIs and Software are provided “as-is” and without any warranty of any kind. VERISIGN EXPRESSLY DISCLAIMS ALL WARRANTIES AND/OR CONDITIONS, EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY OR SATISFACTORY QUALITY AND FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. VERISIGN DOES NOT WARRANT THAT THE FUNCTIONS CONTAINED IN
THE EPP, APIs OR SOFTWARE WILL MEET REGISTRAR’S REQUIREMENTS, OR THAT THE OPERATION OF THE EPP, APIs OR SOFTWARE WILL BE UNINTERRUPTED OR ERROR-FREE, OR THAT DEFECTS IN THE EPP, APIs OR SOFTWARE WILL BE CORRECTED. FURTHERMORE, VERISIGN DOES NOT
WARRANT NOR MAKE ANY REPRESENTATIONS REGARDING THE USE OR THE RESULTS OF THE EPP, APIs, SOFTWARE OR RELATED DOCUMENTATION IN TERMS OF THEIR CORRECTNESS, ACCURACY, RELIABILITY, OR OTHERWISE. SHOULD THE EPP, APIs OR SOFTWARE PROVE DEFECTIVE, REGISTRAR
ASSUMES THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION OF REGISTRAR’S OWN SYSTEMS AND SOFTWARE. 

 6.16.
Indemnification. Registrar, at its own expense and within thirty (30) days of presentation of a demand by Verisign under this paragraph, will indemnify, defend and hold harmless Verisign and its employees, directors, officers,
representatives, agents and affiliates, against any claim, suit, action, or other proceeding brought against Verisign or any affiliate of Verisign based on or arising from any claim or alleged claim (i) relating to any product or service of
Registrar; (ii) relating to any agreement, including Registrar’s dispute policy, with any Registered Name Holder of Registrar; or (iii) relating to Registrar’s domain name registration business, including, but not limited to,
Registrar’s advertising, domain name application process, systems and other processes, fees charged, billing practices and customer service; provided, however, that in any such case: (a) Verisign provides Registrar with prompt notice of
any such claim, and (b) upon Registrar’s written request, Verisign will provide to Registrar all available information and assistance reasonably necessary for Registrar to defend such claim, provided that Registrar reimburses Verisign for
its actual and reasonable costs. Verisign shall have the right to control the defense of Verisign to any claim or in litigation, through counsel of its choice, whose fees shall be subject to indemnification as provided herein. Registrar will not
enter into any settlement or compromise of any such indemnifiable claim without Verisign’s prior written consent, which consent shall not be unreasonably withheld. Registrar will pay any and all costs, damages, and expenses, including, but not
limited to, reasonable attorneys’ fees and costs awarded against or otherwise incurred by Verisign in connection with or arising from any such indemnifiable claim, suit, action or proceeding. 

6.17. Entire Agreement; Severability. This Agreement, which includes Exhibits A and B, constitutes the entire agreement between the Parties concerning
the subject matter hereof and 

  
 -16- 

 
supersedes any prior agreements, representations, statements, negotiations, understandings, proposals or undertakings, oral or written, with respect to the subject matter expressly set forth
herein. If any provision of this Agreement shall be held to be illegal, invalid or unenforceable, each Party agrees that such provision shall be enforced to the maximum extent permissible so as to effect the intent of the Parties, and the validity,
legality and enforceability of the remaining provisions of this Agreement shall not in any way be affected or impaired thereby. If necessary to effect the intent of the Parties, the Parties shall negotiate in good faith to amend this Agreement to
replace the unenforceable language with enforceable language that reflects such intent as closely as possible. 
 6.18. Service Level Agreement.
Appendix 10, as may be amended from time to time, of the Registry Agreement shall be incorporated into this Agreement and attached hereto as Exhibit B. 

  
 -17- 

 IN WITNESS WHEREOF, the Parties hereto have executed this Agreement as of the Effective Date. 

Verisign 
  

			
	By:
		
	Name:	 	 /s/ Pat Kane

	Title:	 	Senior VP and GM, Naming Services
	Date:	 	Aug 31, 2012
	
	Registrar
	
	GoDaddy.com, LLC
		
	By:	 	
		
	Name:	 	 /s/ Nima Jacobs Kelly

	Title:	 	Acting General Counsel
	Date:	 	Aug 31, 2012

 Exhibit A 

REGISTRATION FEES 
  

	 	1.	Domain-Name Initial Registration Fee 

 Registrar agrees to pay US $7.85 per annual increment of an
initial domain name registration, or such other amount as may be established in accordance with Section 5.1(b) above. 
  

	 	2.	Domain-Name Renewal Fee 

 Registrar agrees to pay US $7.85 per annual increment of a domain name
registration renewal, or such other amount as may be established in accordance with Section 5.1(b) above. 
  

	 	3.	Domain Name Transfer 

 Registrar agrees to pay US $7.85 per domain name that is transferred to Registrar
from another ICANN-Accredited Registrar, or such other amount as may be established in accordance with Section 5.1(b) above. 
  

	 	4.	EPP Update to Restore a Name 

 Registrar agrees to pay US $40.00 per use of the EPP Update command to
restore a domain name, or such other amount as may be established in accordance with Section 5.1(b) above. 
  

	 	5.	Sync 

 Registrar agrees to pay US $2.00, plus $1.00 per month of the sync, for each use of the Supported
Protocol Sync command, or such other amount as may be established in accordance with Section 5.1(b) above. 

 Exhibit B 

Service Level Agreement (Appendix 10) 

VeriSign, Inc. (“VNDS”) strives to provide a world-class level of service to its customers. This Service Level Agreement provides metrics and
remedies to measure performance of the .com TLD registry operated by VNDS and to provide accredited and licensed Registrars with credits for certain substandard performance by VNDS. 

A) DEFINITIONS: 
 1) Monthly Timeframe shall mean each
single calendar month beginning and ending at 0000 Greenwich Mean Time (GMT). 
 2) Planned Outage shall mean the periodic pre-announced occurrences when
the SRS will be taken out of service for maintenance or care. Planned Outages will be scheduled only during the following window period of time each week, 0100 to 0900 GMT on Sunday (the “Planned Outage Period”). This Planned Outage Period
may be changed from time to time by VNDS, in its sole discretion, upon prior notice to each Registrar. Planned Outages will not exceed 4 hours per calendar week beginning at 12:00 am GMT Monday nor total more than 8 hours/per month. Notwithstanding
the foregoing, each year VNDS may incur 2 additional Planned Outages of up to 12 hrs in duration during the Planned Outage Period for major systems or software upgrades (“Extended Planned Outages”). These Extended Planned Outages represent
total allowed Planned Outages for the month. 
 3) Shared Registration System (“SRS”) Availability shall mean when the SRS is operational. By
definition, this does not include Planned Outages or Extended Planned Outages. 
 4) SRS Unavailability shall mean when, as a result of a failure of systems
within VNDS’ control, the Registrar is unable to either: 
 a) establish a session with the SRS gateway which shall be defined as: 

1) successfully complete a TCP session start, 

2) successfully complete the SSL authentication handshake, and 

3) successfully complete the registry registrar protocol (“RRP”) or extensible provisioning protocol (“EPP”) session
command. 
 b) execute a 3 second average round trip for 95% of the RRP or EPP check domain commands and/or less than 5 second average round
trip for 95% of the RRP add or EPP create domain commands, from the SRS Gateway, through the SRS system, back to the SRS Gateway as measured during each Monthly Timeframe. 

 5) Unplanned Outage Time shall mean all of the following: 

a) the amount of time recorded between a trouble ticket first being opened by VNDS in response to a Registrar’s claim of SRS
Unavailability for that Registrar through the time when the Registrar and VNDS agree the SRS Unavailability has been resolved with a final fix or a temporary work around, and the trouble ticket has been closed. This will be considered SRS
Unavailability only for those individual Registrars impacted by the outage. 
 b) the amount of time recorded between a trouble ticket first
being opened by VNDS in the event of SRS Unavailability that affects all Registrars through the time when VNDS resolves the problem with a final fix or a temporary work around, and the trouble ticket has been closed. 

c) the amount of time that Planned Outage time exceeds the limits established in A.2 above. 

d) the amount of time that Planned Outage time occurs outside the window of time established in A.2 above. 

6) Monthly Unplanned Outage Time shall be the sum of minutes of all Unplanned Outage Time during the Monthly Timeframe. Each minute of Unplanned Outage Time
subtracts from the available Monthly Planned Outage Time up to 4 hours. 
 7) WHOIS Service shall mean the Whois server running on port 43 of
whois.crsnic.net and whois.verisign-grs.net. 
 8) Global Top Level Domain (“GTLD”) Name Server shall mean any GTLD Name Server under SLD
GTLD-SERVERS.NET (e.g. A.GTLD-SERVERS.NET). 
 B) RESPONSIBILITIES OF THE PARTIES 

1) Registrar must report each occurrence of alleged SRS Unavailability to VNDS customer service help desk in the manner required by VNDS (i.e., e-mail, fax,
telephone) in order for an occurrence to be treated as SRS Unavailability for purposes of the SLA. 
 2) In the event that all Registrars are affected by
SRS Unavailability, VNDS is responsible for opening a blanket trouble ticket and immediately notifying all Registrars of the trouble ticket number and details. 

3) Both Registrar and VNDS agree to use reasonable commercial good faith efforts to establish the cause of any alleged SRS Unavailability. If it is mutually
determined to be a VNDS problem, the issue will become part of the Unplanned Outage Time. 
 4) VNDS will perform monitoring from at least two external
locations as a means to verify that a) sessions can effectively be established and b) all RRP or EPP commands can be successfully completed. 

  
 -2- 

 5) Registrar must inform VNDS any time its estimated volume of transactions (excluding check domain commands),
will exceed Registrar’s previous month’s volume by more than 25%. In the event that Registrar fails to inform VNDS of a forecasted increase of volume of transactions of 25% or more and the Registrar’s volume increases 25% or more over
the previous month, and should the total volume of transactions added by VNDS for all Registrars for that month exceed VNDS’ actual volume of the previous month’s transactions by more than 20%, then Registrar will not be eligible for any
SLA credits (as defined in section C) in that Monthly Timeframe. The Registrar shall provide such forecast at least 30 days prior to the first day of the next month. In addition, VNDS agrees to provide monthly transaction summary reports. 

6) VNDS will notify Registrar of Planned Outages outside the Planned Outage Period at least 7 days in advance of such Planned Outage. In addition, VNDS will
use reasonable commercial good faith efforts to maintain an accurate 30-day advance schedule of possible upcoming Planned Outages. 
 7) VNDS will update
the WHOIS Service once per day beginning at 1200 GMT. VNDS will notify Registrars in advance when changes to the WHOIS Service update schedule occur. 
 8)
VNDS will allow external monitoring of the SRS via an acceptable means to both parties. 
 9) VNDS will initiate the zone file transfer process at least
twice daily at scheduled intervals. VNDS will notify Registrar in advance when changes to the schedule occur. VNDS will notify Registrars regarding any scheduled maintenance and unavailability of the GTLD ROOT-SERVERs. 

10) VNDS will use commercial reasonable efforts to restore the critical systems of the SRS within 24 hours in the event of a force majeure and restore full
system functionality within 48 hours. Outages due to a force majeure will not be considered SRS Unavailability. 
 11) VNDS will publish weekly system
performance and availability reports. These reports will include average round trip for the RRP or EPP Check and Add Domain commands for all Registrars as well as a summary of SRS Availability for the previous week. 

12) VNDS will provide a 99.4% SRS Availability during each Monthly Timeframe. 

C) CREDITS: 
 1) If SRS Availability is less than 99.4% in
any Monthly Timeframe, VNDS will provide a credit to affected Registrar(s) who have complied with Sections B.1 and B.5 above as follows: 

(i) In the case of SRS Unavailability as described in A.4.b, a credit will be given for the combined % total RRP or EPP add and check commands
that fall below the 95% performance threshold established in A.4.b. For each affected Registrar, this will be calculated by multiplying the % below 95% by Registrar’s monthly Add Domain volume x the average initial registration price charged to
that Registrar during the month. The maximum credit to each Registrar shall not exceed 5% of the Registrar’s total monthly Add Domain volume x that average registration price. 

(ii) In the case of SRS Unavailability as described in A.4.a, and following the Monthly Timeframe when the Unplanned Outage began, VNDS will
provide a credit to Registrar by 

  
 -3- 

 
multiplying Registrar’s monthly Add Domain volume x the average initial registration price charged to that Registrar during the month and multiplying that product by the percentage of time
that the Monthly Unplanned Outage Time exceeded 0.6% of the minutes in the Monthly Timeframe. The maximum credit to each Registrar under this subparagraph shall not exceed 10% of the Registrar’s total monthly Add Domain volume x that average
registration price. 
 Under no circumstances shall credits be applied when the availability problems are caused by network providers and/or the systems of
individual Registrars. 
 D) MISCELLANEOUS: 
 1) As an
addendum to the Registry-Registrar Agreement (RRA), no provision in this addendum is intended to replace any term or condition in the RRA. 
 2) Dispute
Resolution will be handled per RRA Section 6.7. 
 3) Any interruption of SRS service that occurs, as a direct result of RRA Sections 2.12, 5.4,
or 6.3 or any other applicable RRA contract term, will not be determined SRS Unavailability per this SLA. 

  
 -4-

Source: [{"source": "alea-institute/alea-institute/kl3m-data-edgar-agreements/train-00232-of-00352.parquet"}, [{"source": "alea-institute/alea-institute/kl3m-data-edgar-agreements/train-00232-of-00352.parquet"}]]