Application Details
Last published on: 7 October 2026 at 15:21 UTC
Application Responses
Section: Applying Entity Information
This question set collects information regarding the legal entity that would enter into a Registry Agreement with ICANN upon successful completion of all relevant application processes. The information collected is intended to be used for background screening.
Provide the full legal name of the applying entity as it appears on the official registration documents. Do not use abbreviations.
Wiz & Associates, S.A. de C.V.
Provide the long form (no acronyms) of the legal entity form/business structure of the applying entity as it appears on the official registration documents. If the original script of the legal entity form/business structure is not English, ONLY provide its official English translation. No additional information should be provided as this will be used for the automatic population of the Registry Agreement.
Sociedad Anónima de Capital Variable (S.A. de C.V.)
The jurisdiction indicates the location in which the business of the applying entity is registered for legal and financial purposes. This is either 1) a country name, or a 2) state/territory name, depending on where the applying entity is registered. No additional information should be provided as this will be used for the automatic population of the Base Registry Agreement. Examples include "Delaware", "Germany", etc.
El Salvador
Provide the website URL of the applying entity, if available.
https://wiz.biz/
1. Choose Yes or No. 2. Use the definition of Affiliate from the Base Registry Agreement (see https://www.icann.org/en/registry-agreements/base-agreement).
false
Choose Yes or No.
false
503
Provide the primary business phone number without including the country code.
03-5784-1069
Provide the primary business email address of the applying entity.
registry@brandsecurity.gmo
Enter the street address (no PO Box).
Calle La Mascota #533
Colonia San Benito
Enter the city, village, municipality, etc.
San Salvador
Enter the state, province, department, territory, prefecture, oblast, etc., if applicable.
San Salvador
1. Enter the postal code, if applicable. 2. If a postal code does not exist, type “Not Applicable”.
01101
SV
Section: Applying Entity Background and Organization
This question set collects information related to the individuals who will have access to TAMS, manage the application, and receive inquiries.
Jason Maurice D'Ambrosio, Johann-Friedrich Gallas
FOMO Hodling GmbH, Jason Maurice D'Ambrosio
Jason Maurice D'Ambrosio
Section: Self-Certification
Provide a single document for Self-Certification question Q4.2-1. The document must include only the SC4.2-1.1, SC4.2-1.2, or SC4.2-1.3 statements. Do not modify any of the Self-Certification statements.
1. Provide a single document for Self-Certification question Q4.2-1. 2. The document must include only the SC4.2-1.1 through SC4.2-1.3 statements. 3. Do not modify any of the Self-Certification statements. 4. If the applying entity cannot Self-Certify the SC4.2-1.1 through SC4.2-1.3 statements, provide a document that explains why the applying entity cannot Self-Certify the SC4.2-1.1 through SC4.2-1.3 statements.
Section: Security Policy and Planning
Provide a single document for Self-Certification question AGB Q220, Q5.1-1. The document must include only the SC5.1-1.1 through SC5.1-1.3 statements. Do not modify any of the Self-Certification statements. If the applicant cannot Self-Certify SC5.1-1.1 through SC5.1-1.3 statements, provide a document that explains why the entity cannot Self-Certify the SC5.1-1.1 through SC5.1-1.3 statements.
1. Provide a single document for Self-Certification question Q5.1-1. 2. The document must include only the SC5.1-1.1 through SC5.1-1.3 statements. 3. Do not modify any of the Self-Certification statements. 4. If the applying entity cannot Self-Certify the SC5.1-1.1 through SC5.1-1.3 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.1-1.1 through SC5.1.1-3 statements.
Section: DNS Abuse
Provide a single document for Self-Certification question AGB Q221, Q5.2-1. The document must include only the SC5.2-1.1 through SC5.2-1.7 statements. Do not modify any of the Self-Certification statements. If the applicant cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements.
1. Provide a single document for Self-Certification question Q5.2-1. 2. The document must include only the SC5.2-1.1 through SC5.2-1.7 statements. 3. Do not modify any of the Self-Certification statements. 4. If the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements.
Section: Primary String
This question set collects basic information regarding the string that is being applied for (for example, a-label, meaning, script). If the applying entity opts to designate a replacement string, it must answer the same set of questions for the replacement string from the AGB Question Set 5 on.
bitcoin
Provide the meaning, or restatement of the string in English, that is, a description of the literal meaning of the string in the opinion of the applying entity. If there is no literal meaning in English (for example, a brand name or a proper noun without a translation) simply state "No English Translation"
The name of the Bitcoin protocol and network and of the unit of the currency it operates; here, the community of those who run, build and provide the network's infrastructure and services.
Provide a representation of the string according to the International Phonetic Alphabet.
[ˈbɪtkɔɪn]
Confirm the statement using a checkbox.
true
1. Describe the mission and purpose of the applied-for gTLD, including the intended registrants and users, and the related activities that have been or will be carried out to achieve this purpose. 1a. If applying for a variant of an existing gTLD, please also describe the mission and purpose of the existing gTLD, including the intended registrants and users, and the related activities that have been or will be carried out to achieve this purpose. 2. Explain how this purpose is sustainable over time.
Mission. To operate .bitcoin as a restricted namespace serving the Bitcoin operational and contributor community, in which a domain name is evidence that its holder performs a verifiable function in the operation, development or provision of the Bitcoin network. Purpose. The Bitcoin ecosystem is a persistent target of impersonation and fraud, and the general public has no reliable signal by which to distinguish a genuine operator, wallet or exchange from an imitation of one. Because eligibility for a .bitcoin registration is conditioned on a verifiable functional qualification, the namespace supplies that signal: registration is itself a statement, enforceable through the registry’s own policy, that the registrant is a participant in the network’s operation and not a party appropriating its name. Restriction is therefore the purpose, not an incident of it. Intended registrants and users. Registrants are the members of the identified community: node and DNS seed operators; contributors to the reference implementation and the standards process; operators of explorers, wallets, exchanges, custody, payments and mining services; publishers and educators documenting the protocol; and organizers of the community’s conferences, meetups and working groups. Users are those registrants together with the wider public who rely on the namespace as an indication that a service is a bona fide participant. Activities undertaken and to be undertaken. The registry will operate .bitcoin under a Community Registration Policy proposed for inclusion in Specification 12 of the Registry Agreement; verify eligibility against the published functional qualifications before registration and on renewal; maintain a published abuse point of contact that receives and acts on reports of non-qualifying or abusive registrations; and operate under TLD-scoped governance in which the community’s relevant bodies determine policy and the applicant, as the contracting party, executes it. Sustainability over time. The purpose sustains itself by the same mechanism that defines it. Verification is funded from registration fees, so the cost of policing eligibility scales with the namespace it polices; the registry has no auction program and no premium-name program, so its revenue does not depend on selling names outside the community it serves. The applicant has operated the network’s most widely integrated public block explorer and one of its DNS seeds for over seven years without charging the community for either, and the registry commits 21% of gross revenue to funding Bitcoin development and infrastructure, returning the namespace’s proceeds to the community whose participation gives it meaning. These commitments stand as fixed obligations in the registry’s financial planning, and the 21% pledge is already a matter of public record in the applicant’s published notice to the community.
Section: Community
This question set collects information specific to Community gTLDs. However, question 133 (Mission & Purpose) must be answered by all applying entities.
General
Yes
1. Provide the name of the community that the applying entity is committing to serve. 2. Describe the distinct aspects of the community.
The string .bitcoin represents the Bitcoin operational and contributor community worldwide: those who run, build or provide the infrastructure, software and services of the Bitcoin network.
Enter a category that best describes your community. Some examples of community categories could include, but are not limited to: activity-based and volunteer groups, online or social media groups, religious or political groups, diasporic communities, linguistic communities, celebrity or sports team supporters.
The identified community is an established global technical and operational community. The category is chosen deliberately over alternatives such as an interest group, a user base, or a market. The distinction is functional rather than attitudinal: membership of this community is constituted by performing a function in the operation, development, provision or support of the Bitcoin network - operating a node or a DNS seed, contributing to the reference implementation or the standards process, providing an explorer, wallet or exchange service, publishing educational or documentary material about the protocol, or organizing the community's convenings. Each of those functions is externally observable and independently verifiable from public artifacts: a reachable node on the peer-to-peer network, a commit history, a published and operating service, published material, a program of record. That is what makes it a community in the sense the Guidebook requires, and not a public. Holding or purchasing bitcoin, by contrast, is an action that is not operational in nature and confers no role. The community is therefore defined so as to exclude holders and purchasers as such. A person who buys bitcoin is not a member. A person who runs the software that makes buying possible is. The community is technical in that its membership is bound by a shared specification (the consensus rules implemented in the network's software, to which every participant's transactions and blocks must conform) and operational in that its members maintain the network as a continuously running system, not as a body of knowledge or a market position.
Organization
Describe and provide evidence of the relationship between the applying entity and the identified community.
The applicant is connected to the identified community in two capacities: as a member performing several of the functions by which the community is defined, and as the holder of a trust the community itself conferred on it. The trust already held. The Bitcoin reference implementation carries in its source a short list of DNS hostnames that every newly started node queries in order to discover peers on the network. The applicant operates one of those seeds, seed.bitcoin.wiz.biz, and is named in the source as its operator. It is one of seven such seeds in the current implementation. The set is not self-declared: entries are added and removed through the community's own public, reviewed, version-controlled process, and the record of every change is permanently archived and attributable. The seed is in continuous operation and answers queries from nodes worldwide. This matters to the present application for a reason beyond credentials. The trust the community has already placed in the applicant concerns naming and discovery - the same function a top-level domain performs. The applicant does not come to this community asking for a new kind of responsibility. It asks to continue, at the top level of the domain name system, a naming role the community entrusted to it and has maintained across successive releases. Infrastructure the community relies on. The applicant operates mempool.space, the most widely used block explorer for the Bitcoin network, through which participants inspect transactions, fees and the state of the mempool. The project is open source and, in its own words, "developed and operated for the benefit of the Bitcoin community." The applicant's principal maintains and operates the project, and is its leading contributor by volume, with 3,313 commits recorded in the public repository, more than any other contributor. The service is relied upon by substantial regulated undertakings, and in July 2025 a report of the President's Working Group on Digital Asset Markets, published by the White House under Executive Order 14178, cited mempool.space as its source for the network's genesis block (footnote 209; captured 4 August 2026): reliance on the applicant's service by the executive branch of the United States, in its own published record. Service to a sovereign. The applicant operates bitcoin.gob.sv, the site of the National Bitcoin Office of El Salvador, for the government of that Republic. Community-facing work. The applicant has maintained public reference material for the community, including the site at bitcoin-only.com, and its principal participates in the community's convening activity, including meetups, conference programs and long-form public discussion. Evidence, not assertion. Each element above is verifiable by any evaluator without reference to the applicant: the seed entry and its operator attribution appear in the reference implementation's published source; the contribution record appears in the public repository; the seed answers live queries; and the National Bitcoin Office site is publicly reachable. Everyone in the Bitcoin community contributes in their own way; the applicant has contributed for many years as an experienced network operator (AS 54415), providing DNS and other critical infrastructure, and now proposes to extend that operational role to the top-level domain in service of the same community.
Describe and provide evidence related to the community organization, any relevant organizing bodies, and any relevant leaders within the community.
The applicant is not the organizing body for this community and does not claim to be. No single party organizes Bitcoin. The community is nonetheless organized, and organized functionally: through bodies each holding a defined role relevant to a member category, each admitting and removing participants by public, documented process. The Guidebook provides that a body which represents a community ranks equally with one that administers it. On that basis: 1 - The DNS seed operators. Relevant to: node and seed operation. Every newly started Bitcoin node discovers the network by querying a short list of DNS hostnames carried in the reference implementation's source. Seven are carried in the current implementation, each attributed to its operator: dnsseed.bluematt.me (Matt Corallo), seed.bitcoin.jonasschnelli.ch (Jonas Schnelli), seed.btc.petertodd.net (Peter Todd), seed.bitcoin.sprovoost.nl (Sjors Provoost), dnsseed.emzy.de (Stephan Oeste), seed.bitcoin.wiz.biz (the applicant) and seed.mainnet.achownodes.xyz (Ava Chow). This body is identified first because it demonstrates organization in the sense the criterion tests. Admission and removal occur through a public, reviewed, version-controlled process: entries were removed on 9 July 2026, 28 October 2025 and 26 August 2024, each by an attributable public change. A community that admits and removes the holders of a trust role by a recorded, reviewable procedure is an organized community. 2 - Maintainers and contributors of the reference implementation. Relevant to: protocol and software contribution. Authority to accept changes to the software the network runs rests with five maintainers, identified by signing keys published in the repository itself, and every change is recorded publicly with its reviewers. The implementation records 341 named contributors. 3 - Editors of the standards process. Relevant to: protocol and software contribution. Protocol proposals are numbered, reviewed and published under a process established on 19 September 2011, administered by assigned editors and recorded publicly. 4 - Conference and regional meetup organizers. Relevant to: convening. Standing series that convene the community recurringly. 5 - Operators of infrastructure and services. Relevant to: service provision. Explorers, wallets, exchanges, custody and payment providers, and mining pools, each identifiable by its service. Leaders. The community's leaders are identifiable by name and role. The seed operators are named in the implementation itself: Matt Corallo, Jonas Schnelli, Peter Todd, Sjors Provoost, Stephan Oeste, the applicant's principal, and Ava Chow. Five maintainers, identified by signing keys published in the repository, hold authority to accept changes to that implementation. Similarly, five maintainers have editorial authority over the BIP standards process, identified in the "bips" git repository. The convening, software, and educational bodies name their own leaders in the statements filed at Q156, including Adam Back (Blockstream), Olaoluwa Osuntokun (Lightning Labs), Gigi (OpenSats), Mike Schmidt (Brink), Lisa Neigut (bitcoin++), David Bailey (The Bitcoin Conference), Rod Roudi (Bitcoin Park), Anna (Baltic Honeybadger), Martin Kuchar (BTC Prague), Michael Tidwell (TABConf), and Giacomo Zucco (Plan B Network). Leadership here is functional, not hierarchical: each leads a body with a defined role in operating, developing, funding, or convening the network, and none claims authority over Bitcoin itself. Two express statements. None of the bodies above claims authority over Bitcoin itself, and the applicant attributes none to them; each holds a defined function, and that is the whole of the claim. And the committee proposed to govern this domain's policy is an instrument of the registry, not an organizing body of this community, being the mechanism by which the registry answers to the bodies above. It is described in the charter filed with this application.
1. Describe any formal membership process, if there is one. 2. If there is no formal membership process, provide evidence related to how an individual can join the identified community (i.e., “self-identify” as a community member).
Membership is defined by a verifiable functional qualification. It is neither a roster maintained by the applicant nor a matter of self-identification, and it does not depend on holding bitcoin, on nationality, or on domicile. A member of the identified community is a natural or legal person that performs at least one of the following functions in relation to the Bitcoin network, and whose performance of it can be verified from public evidence: Network operation - operating a reachable node on the Bitcoin peer-to-peer network, or operating a DNS seed by which new nodes discover peers. Verifiable from: the node's presence and service bits on the public network; for seeds, the published seed list carried in the reference implementation. Protocol and software contribution - contributing to the reference implementation or to other consensus-compatible node software, or participating in the standards process by which protocol proposals are drafted, reviewed and assigned. Verifiable from: public version-control history and the public proposal record. Infrastructure and service provision - operating a block explorer, wallet, exchange, custody, payments or mining-related service for the Bitcoin network. Verifiable from: the operating service itself. Documentation, education and publication - publishing material that documents or teaches the protocol and its use: books, technical documentation, periodicals, courses, podcasts or long-form written work. Verifiable from: the published work. Convening - organizing conferences, meetups, or working groups of the community. Verifiable from: the program and record of the events held. Joining requires no application to anyone. A person joins the community by beginning to perform a qualifying function, starting a node, publishing a first contribution, opening a service, and the public evidence of that performance is itself the record of membership. Two features of this definition matter for the panel's assessment. First, it is bounded: each qualification is a function performed, so the boundary is determined by evidence rather than by the applicant's discretion, and a person who ceases to perform any qualifying function ceases to qualify. Second, it is exclusive of the general public: the substantial population that buys, holds or transacts in bitcoin without performing any of the functions above is outside the community by the definition's own operation, not by exclusion after the fact. The same five categories, expressed as compulsory and measurable registry obligations, constitute the eligibility rules proposed for the registry's Community Registration Policy, so that the community as defined and the community as served are the same set.
Provide the primary location of the community.
Worldwide. The community is inherently distributed: members operate nodes, infrastructure and services across every populated region and coordinate through public networks rather than within any single jurisdiction.
1. Provide the estimated size of the community. The size should be in number format (e.g., “1,000,000 members”). 2. If the community is divided by group, region, sector, etc., this should include estimated size for each group.
Approximately 28,000 participants worldwide, by group: 27,556 reachable nodes; 341 reference-implementation contributors; 7 DNS seed operators; and operators of mining, exchange, wallet, explorer, payment, publishing and convening services.
Provide the estimated size of the community that is administered or represented by each relevant organizing body in the identified community.
DNS seeds: 7. Bitcoin Core: 341 contributors. OpenSats: 400+ grantees. Mining (Foundry+Antpool+SpiderPool): ~50%+ hashrate. Bitcoin 2024: 22,000+ attendees. BTC Prague: 8,400 visitors. Bitcoin Park: 6,582 members. 30+ service & infrastructure operators.
Engagement
1. Provide evidence of any documented practices of community efforts to date 2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission: a) Offering support; b) Sharing information; c) Responding to specific community needs; d) Fostering and strengthening relationships within the community.
The organizing bodies of this community engage it continuously, and they do so in public. Every item below is dated, falls inside the two years before submission, and is verifiable from the community’s own records, not from the applicant’s account of them. (a) Offering support. The maintainers of the reference implementation sustain not one release line but five concurrently maintained major series, issuing security and maintenance releases to older series alongside new ones so that operators who cannot upgrade immediately remain supported. Eighteen releases were published between 11 July 2024 and 10 July 2026 (v26.2, v27.2, v28.0 through v28.4, v29.0 through v29.4, v30.0 through v30.3, and v31.0 and v31.1), each with published release notes and an attributable change history. Support is also structural, not occasional: the DNS seed set answers peer-discovery queries from every newly started node on the network, continuously, without charge or registration. (b) Sharing information. The standards process publishes Bitcoin Improvement Proposals to a public repository under a documented procedure, and each of the eighteen releases above is accompanied by published notes describing its changes. The community’s development mailing list remains its deliberative venue and its archive is public and dated. Its conferences publish programs and recordings. (c) Responding to specific community needs. The clearest instance in the window concerns the organizing body at the centre of this application. The DNS seed set is a list carried in the reference implementation’s source, and its membership is curated — entries were removed on 26 August 2024, 28 October 2025 and 9 July 2026, each by a public, reviewed, version-controlled change with an attributable author and an archived discussion. A seed that ceases to serve the network is removed by the community’s own process, on the record. That is an organizing body identifying a need and acting on it, evidenced without any reliance on the applicant. (d) Fostering and strengthening relationships. The community’s convening bodies met repeatedly inside the window, and their own statements record the scale: BTC Inc’s Bitcoin events brought together approximately 67,000 attendees across multiple continents in 2025 alone, per its organizer’s statement filed at Q156; BTC Prague, Europe’s largest Bitcoin conference, brought together approximately 110 partner and sponsor organizations and more than 8,400 visitors; Bitcoin Park recorded 12,700 attendances by 3,821 distinct individuals, of whom 228 attended ten or more events; bitcoin++ has run more than eighteen editions of technical conferences, workshops and hackathons for developers; TABConf continued as a volunteer-run technical conference. Beyond the conference circuit, Bitcoin Ekasi sustains a functioning circular economy in Mossel Bay, South Africa, with roughly 500 people transacting weekly or daily, and Blocktrainer convenes German-language events drawing more than 1,000 participants each.
1. Describe whether the applying entity has a role in any of the activities listed in Question 141. 2. If the applying entity does play a role, provide evidence of the applying entity’s role. If the applying entity does not play a role, describe why this is the case.
Yes. The applying entity is not an observer of this community's engagement but a participant in it, and in several instances the party conducting it. Operating shared infrastructure others depend on. The applicant operates one of the seven DNS seeds by which every newly started node on the network discovers its peers, and operates mempool.space, through which participants inspect transactions and fee conditions. Neither is a passive holding: each is a service the community consumes daily, and the applicant's principal maintains the latter and is its leading contributor by volume, with 3,313 recorded commits. Supplying information to the community. The explorer exists to make the state of the network legible to its participants, and the applicant has maintained public reference material addressed to the community, including the site at bitcoin-only.com. Serving the community's institutional interface. The applicant operates the site of the National Bitcoin Office of El Salvador, a function that sits at the boundary between the community and a sovereign state. Convening and participating. The applicant's principal participates in the community's convening activity, including meetups, conference programs and public discussion. Sharing a trust role subject to the community's own review. The applicant's seed entry exists in the reference implementation because the community's process placed it there and has maintained it across releases. Participation in that process, being subject to it rather than merely benefiting from it, is itself engagement of the kind this criterion contemplates.
Awareness
1. Provide evidence that demonstrates that community members are aware of the identified community and the different member groups or segments within the identified community. 2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission: a) Surveys conducted; b) Records of activities involving a diversity of community groups, segments, or members.
Members of this community are aware of the community and of one another, and the evidence for it is documentary. No survey is offered, because the community's own records establish the point directly. Overlapping membership between organizing bodies. The same individuals hold roles in more than one of the community's bodies simultaneously, and the overlap is near-total. Every one of the seven DNS seed operators carried in the reference implementation has also contributed to that implementation, six of them substantially: Ava Chow (2,471 commits, most recent 24 July 2026), Jonas Schnelli (774), Matt Corallo (507), Sjors Provoost (450, most recent 23 July 2026), Peter Todd (106) and Stephan Oeste (3), figures taken from the public repository on 28 July 2026. A community in which the operators of one trust role are, almost without exception, the authors and reviewers of the software the network runs is a community whose members are known to one another by name and by function, not in the abstract. The awareness this sub-criterion tests is a condition of the roles being held at all, not an inference from them. Shared, reviewed decision-making. The mechanism by which a member is admitted to or removed from the seed set is a proposed change to the reference implementation, reviewed and accepted in public by that implementation's maintainers. Every such change carries the identities of the proposer and the reviewers. Awareness between members is therefore recorded in the artifact of every decision. A common deliberative venue. Protocol matters are discussed on a public mailing list with an open archive, and proposals are numbered and published under a common standards process. Participation across both is cross-cutting: the same participants appear as authors, reviewers and correspondents. Recurring convening. The community assembles on a recurring basis at standing conference series and regional meetups, at which its members appear as organizers, speakers and participants. A shared technical constraint that requires mutual awareness. Every member's transactions and blocks must conform to the same consensus rules, and every node operator depends on other members' nodes to relay and validate. The community's members do not merely know of one another. The system they operate does not function unless they interoperate by common agreement.
1. Provide evidence of community members’ awareness of the applying entity and its intent to apply for a community gTLD. 2. If there is no such evidence, explain why not.
Yes, and the evidence is on the public record. The notice. On 5 August 2026 the applicant published Notice of ICANN .bitcoin TLD community application, addressed to the community and issued under the name of the applicant’s Chairman and Chief Executive. The notice states the intention to file a community priority application for .bitcoin; identifies the applicant as Wiz & Associates, S.A. de C.V.; sets out the identified community in the same terms used in this application, namely those who run, build and provide the infrastructure, software and services of the Bitcoin network; describes the proposed registration policy and the committee that would oversee it; and gives the closing date of the submission window. It invites objections expressly, stating that the notice is given so that the intention is public and so that serious objections can surface early rather than during evaluation. It is dated and publicly accessible. The response, which is the stronger evidence. Within days of that notice, more than fifty organizations and individuals across the identified community responded in writing, each naming Wiz & Associates S.A. de C.V. and the string .bitcoin, and each addressing the application directly. The letters are dated between 5 and 11 August 2026 and are attached to Q156. They include multiple operators of Bitcoin DNS seeds and Bitcoin Core maintainers and contributors; the largest public funder of open-source Bitcoin development (OpenSats); major Bitcoin infrastructure and protocol companies (Blockstream and Lightning Labs); three of the largest mining pools by hashrate (Foundry, Antpool, and SpiderPool); the organizer of The Bitcoin Conference, the largest Bitcoin event by attendance; the organizers of BTC Prague, Baltic Honeybadger, Bitcoin Park, and other technical conferences and meetups; leading open-source wallet, node, custody, exchange, and payment projects; significant education and policy organizations; and circular-economy and regional Bitcoin communities. The supporting parties are established across the Americas, Europe, Africa, and Asia. Awareness is therefore evidenced twice over: the community was told, in a dated public notice that set out the application in the same terms as the filing; and the community demonstrably received it, because over fifty of its organizations and operators read the notice, understood what was proposed, and put their positions in writing within days. No member of the community has stated that it was unaware, and none has objected on that ground.
Established Presence
Provide evidence of the established presence of the community prior to the opening of the application submission period.
1. Provide evidence that demonstrates that individuals and groups outside of the community show an awareness of the identified community. 2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission: a) Media or other public information regarding the community and its activities or members; b) Discussion of the community in various fora, whether online or in person; c) Evidence of partnerships or collaborations with groups outside of the identified community; d) Evidence of the chartering or organization of the community prior to the opening of the application submission window; e) Evidence of contributions (for example, cultural or scientific) to a larger society or population;
Recognition of this community outside its own membership is unusually well-evidenced, and it extends to the highest level available - recognition by sovereign states in legislation. Sovereign recognition of the community's operators. The Republic of El Salvador operates its official Bitcoin information service at bitcoin.gob.sv on the applicant's infrastructure, a state entrusting a member of this community with a service on its own national domain. That entrustment followed the state's adoption of Bitcoin by Act of its Legislative Assembly in 2021, legislation that presupposes, and therefore recognizes, an operated network and the community that operates it. In August 2026 the Republic's Vice Minister of Foreign Affairs, under seal, recognized this community's "node and seed operators, protocol contributors, and the providers of the services that depend on them" as "a long-standing, identifiable and functioning community" on whose continued work the nation's payment and financial infrastructure depends, and recorded no objection to .bitcoin representing it, in connection with this application (MRREE/2026, exhibited). United States Senator Cynthia M. Lummis, in a letter dated 11 August 2026, expressly recognized the identified community, Bitcoin node and DNS seed operators, protocol and software contributors, and providers of infrastructure, services, and education, and stated that its continued work is essential to the Bitcoin network and to financial innovation in the United States. Public and documentary recognition. The subject has been continuously covered by the general press for well over a decade, is treated in dictionaries of record, and is the subject of an extensive published literature - including translations of the community's principal works into other languages, one of which the applicant published in Japanese. The distinction that matters for this criterion is between recognition of a subject and recognition of a community. What is recorded above is the latter: states legislating for the system this community operates, one state entrusting its own service to a member of it, another state's executive citing a member's infrastructure as its source of record, regulators supervising its participants, and major undertakings depending on infrastructure its members run.
Longevity
1. Provide evidence of the longevity of the community. 2. The applying entity should provide documentation of the following practices which should have occurred within the two years leading up to application submission: a) Evidence of recurring or scheduled activities that demonstrate continuity over time; b) Documented records of past activities that demonstrate a long-standing tradition or practice; c) Records of discussions emphasizing the community’s enduring presence or its cultural significance.
Why this answer has two parts. Deep history alone does not satisfy the instruction - an answer resting only on founding dates is non-conformant, however impressive the dates. Both halves are answered below. Part 1 - Long-standing tradition This community has operated continuously for over seventeen years, and its record is unusually precise because its own infrastructure timestamps it. The specification was published on 31 October 2008. The network began operating at 18:15:05 UTC on 3 January 2009 with the mining of block 0, and every block since remains publicly verifiable by anyone running the software. The reference implementation's version-control history reaches the network's first year (its earliest reachable commit is dated 17 December 2009) and records 341 named contributors. The community's institutions were established across successive years, none in connection with this application: the standards process by which protocol changes are proposed and published was established on 19 September 2011 and has operated continuously since; the public development mailing list has served as the community's deliberative venue since the network's earliest period; and the set of DNS seeds carried in the reference implementation has been maintained there across releases for more than a decade. That last point bears on longevity in a way founding dates do not. The seed set is not a static artifact of the community's early years. Its membership has been actively curated within the last two years - entries were removed on 26 August 2024, 28 October 2025 and 9 July 2026, each by an attributable public change to the reference implementation. A community that was maintaining the same trust role seventeen years after its founding, and doing so last month, is not merely long-lived but continuously operating. Part 2 - Practices within the two years before submission Part 2(a) - recurring and scheduled activity, from public record The reference implementation's release cadence over the two years before submission is public record. Eighteen releases were published between 11 July 2024 and 10 July 2026, across five concurrently maintained major series - not a single active branch but five maintained in parallel, with security and maintenance releases issued to older series alongside new ones: the release behavior of a community sustaining infrastructure in production for operators who cannot all upgrade at once. A recurring, scheduled practice inside the window, evidenced from the community's own record; the dated release table, retrieved 28 July 2026, accompanies this answer as an exhibit. Part 2(b) - the convening tradition, active in the window The community's standing conferences and meetup networks convened it throughout the two years before submission, and their own statements, dated August 2026 and filed at Q156, record the scale: BTC Prague with approximately 110 partner organizations and more than 8,400 visitors; bitcoin++ in its eighteenth edition; Bitcoin Park with 12,700 attendances by 3,821 distinct individuals; TABConf; and regional convening from German-language events of more than 1,000 participants to a functioning circular economy in South Africa. Archived programs for the 2024-2026 editions accompany this answer as exhibits. Part 2(c) - recent discussion of enduring significance In July 2025 the President's Working Group on Digital Asset Markets (Executive Order 14178) published Strengthening American Leadership in Digital Financial Technology - a United States executive-branch report treating the network this community operates as a subject of national policy, citing the community's own infrastructure (mempool.space, footnote 209) as its source of record for the network's first block. Governmental discussion of the community's significance, inside the two-year window, resting on the community's record (captured 4 August 2026).
Nexus
Explain how the applied-for string matches the name of the community or is a well-known alternative name (whether long or short form) of the community.
The identified community is the Bitcoin operational and contributor community: those who run, build or provide the infrastructure, software and services of the Bitcoin network. The applied-for string is the identifying element of that name. The remaining words (operational and contributor) state the functions by which membership is verified, and they name no different subject. Remove them and the community is still named. Remove "bitcoin" and nothing is named at all. The string is also the community's well-known short name. In ordinary English this community is called the bitcoin community, and that collocation is recorded in a dictionary of record: Merriam-Webster's entry for the word carries, as an illustrative quotation, Richard Kastelein's description of "a new financial instrument coming out of the bitcoin community" (entry captured 3 August 2026). The applicant did not coin the short name for this application. A lexicographer selected, as an example of ordinary usage, a published sentence in which this community is named by the string alone. What the string names. Where lexicographers distinguish the word's senses, the sense entered first, or entered separately, is the system rather than the unit. Collins English Dictionary gives as sense 1 "a system of open source peer-to-peer software for the creation and exchange of (payment in) a certain type of cryptocurrency; the first such system to be fully functional", and only as sense 2 "the cryptocurrency created and exchanged using this software", the second sense defined by reference to the first. Duden, the German dictionary of record, does not rank the senses at all: it enters "Bitcoin, Zahlungssystem" (payment system) and "Bitcoin, Zahlungseinheit" (payment unit) as two separate headwords. Merriam-Webster distinguishes by case, its capitalized headword denoting the scheme as a whole (created for peer-to-peer transactions, glossed as having "no central issuing authority") and only its lowercase headword denoting "a unit of this currency". Why that system is this community. A system of open source peer-to-peer software with no central issuing authority is not self-operating. It exists only while people run it and it changes only when people change it, and those people are the identified community. They are countable: 27,556 reachable nodes (btcnodes.io snapshot, 3 August 2026 23:29:53 UTC; corroborated at 25,495 nodes by the independent crawler bitnod.es on a different counting method); 341 named, non-anonymous contributors to the reference implementation published at bitcoin/bitcoin (contributor record retrieved 28 July 2026); seven DNS seed operators named in that implementation's own source; and a standards process opened by BIP 1 on 19 September 2011. The community's institutions carry the string in their own names: the specification published at bitcoin.org/bitcoin.pdf, the reference implementation's repository, the Bitcoin Improvement Proposal process, and the seed hostnames themselves. The relation between the string and the community is therefore constitution, not overlap. The string does not resemble this community's name, abbreviate it, or evoke it. It is the name, and the thing it names is the thing this community exists to run. The applicant does not claim the word has only this meaning. It also names the unit of value the system transfers, and that sense appears in every dictionary entry of the word that exists. It is not, however, an unrelated meaning: each dictionary that records the unit defines it by reference to the system - "created and exchanged using this software" (Collins), "a unit of this currency" (Merriam-Webster), "produced by a public network rather than any government" (Cambridge). The further sense of the word cannot be stated without naming what this community operates.
1. Explain how the applied-for string clearly relates to or represents the community 2. Explain whether the applied-for string has any other significant meaning beyond identifying the community or community members described in the application. The applying entity may wish to provide pertinent information regarding any particular geography, region, or themes that may be alluded to by the string, of which the community may or may not be a part.
The word entered the language as the name of a system. The document that coined it is titled Bitcoin: A Peer-to-Peer Electronic Cash System, the specification for an operated network, published in 2008. The unit of value followed in January 2009, when the network began producing it. The coin is named after the system, not the system after the coin, and everything the public has learned about the word since descends from that order. The word's senses nest; they do not compete. A bitcoin is an entry on a ledger that exists only as the shared state of the network's nodes. The unit cannot be held, sent, or even defined except by reference to the operated system. Even dictionaries that define only the currency define it as produced by a public network rather than any government, and a currency with no issuer is produced by whoever operates the network. That is the identified community. Every use of the word for the money therefore presupposes the thing this community runs; the currency sense is a dependent of the network sense, not a rival to it. The public's association with the community is operational, not merely verbal. No one buys, holds, or spends a bitcoin except through software the community's contributors write and services its members operate: every wallet, every exchange, every payment touches infrastructure this community provides. Usage has reflected that from the network's first days, among the first words the running system's first users published was the two-word report "Running bitcoin", and it persists in the compounds the public actually speaks: the Bitcoin network, a Bitcoin node, Bitcoin mining, Bitcoin Core. Asked who is behind bitcoin, the public can name no issuer, no company, and no headquarters, because none exists. The only human referent the word has ever had is the community that operates it. States and institutions use the word the same way. A sovereign government publishes its national Bitcoin office at bitcoin.gob.sv, a state office named for the string, operated on a community member's infrastructure, and the United States executive's 2025 digital-asset report treats Bitcoin as an operated network and cites a member's public infrastructure as its source of record (the exhibits are filed at Q146). The other meaning, disclosed. One sense of the word reaches beyond the community: for the holders and purchasers of bitcoin, the word means the asset and nothing more. The applicant does not minimize this population and expressly places it outside the identified community. Holding performs no function on the network, and holders are neither counted in the community's size, nor claimed as endorsers, nor eligible to register. But the asset sense is not an unrelated meaning. Both senses descend from a single referent, first described in the specification, and the second cannot be defined without the first. A string whose other meaning pointed somewhere else would tell against the community. This one points back.
Community Registration Policy
Select from Radio Buttons - Yes/No. Notes: 1. Community Registration Policies are conditions that community gTLD registry operators impose upon registrants within their gTLDs. 2. If you select “Yes” to this question, the applying entity is required to pay the conditional Registry Commitments Evaluation fee, and Community Registration Policies that are approved by ICANN will be scored in the CPE (if the applying entity elects to participate) and included in Specification 12 of the applicable Base RA. 3. If you select “No,” then the application cannot proceed as a community application.
Yes
1. Draft the Community Registration Policy as proposed contract language. Policies that are approved by ICANN will be included in Specification 12 of the applicable Registry Agreement and will be subject to enforcement by ICANN Contractual Compliance. See Appendix 4 Base Registry Agreement, Specification 12 for drafting approach. Consider the usage of defined terms and the definitions of such terms in the 2026 Round Base RA. 2. Enter a single proposed Community Registration Policy with respect to registrant eligibility in each response field. Up to 10 Community Registration Policies can be submitted. 3. Follow this format to propose what the Registry Operator must do and/or must not do: a) “Registry Operator shall___”; and/or b) “Registry Operator shall not___”. 4. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars ,: a) "Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or b) "Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”. 5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements: a) "Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring ___"; and/or b) "Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting ___". 6. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example: a) Registry Operator shall develop and implement a registration eligibility policy and publish this policy on its website no later than the date on which the TLD is delegated in the DNS. b) Registry Operator shall review the registration policy described in (a) at least once per year, and publish the results of such review (including any updates to the registration policy) on its website within thirty (30) days following the anniversary of the Effective Date. 7. If the Community Registration Policy is limited in time, duration, scope, or any other factors, specify the applicable limitations. For example, if a registrant eligibility restriction is time-limited, the applying entity must state if the restriction will apply for the lifetime of the gTLD, only during a specified period, or for some other defined period (such as, Registry Operator shall, for a period of x days from the Effective Date, ___). 8. See Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria for evaluation criteria that ICANN will apply for evaluating each proposed Community Registration Policy.
The Registry Operator shall restrict eligibility to register or hold a domain name in the TLD to registrants that demonstrate performance of at least one Qualifying Function, as published under Field 2.
Please see full instructions in AGB Q151.1.
The Registry Operator shall publish, and keep publicly available, the list of Qualifying Functions and, for each, the categories of evidence it accepts as establishing performance of that Function. The Qualifying Functions shall be: (a) operating a reachable node on the Bitcoin peer-to-peer network, or operating a DNS seed by which nodes discover peers, evidenced by the registrant's node being observable on the public network at a stated address, whether by the Registry Operator's own measurement or by a published third-party network crawler; (b) contributing to the Bitcoin reference implementation, to other consensus-compatible node software recognized under the Other Commitments, or to the Bitcoin Improvement Proposal process, evidenced by an attributed commit in the public version-control history or by authorship or editorship of a Bitcoin Improvement Proposal; (c) operating a block explorer, wallet, exchange, custody, payment or mining-related service for the Bitcoin network, evidenced by the service being publicly reachable and operated by the registrant; (d) publishing documentation, education or periodical material concerning the Bitcoin protocol or its use, evidenced by publication under the registrant's name or imprint, bearing a date and publicly accessible, and amounting to a body of work rather than a single item; (e) organizing conferences, meetups or working groups of the Bitcoin community, evidenced by a published program or announcement naming the registrant as organizer.
Please see full instructions in AGB Q151.1.
The Registry Operator shall verify the evidence submitted under Field 2 and shall not activate a domain name in the TLD before that verification is complete.
Please see full instructions in AGB Q151.1.
The Registry Operator shall refuse an application for registration where the applicant does not submit evidence of a Qualifying Function, or where the evidence submitted does not establish performance of a Qualifying Function.
Please see full instructions in AGB Q151.1.
The Registry Operator shall require and verify evidence of continued performance of at least one Qualifying Function at each renewal of a registration.
Please see full instructions in AGB Q151.1.
The Registry Operator shall give a registrant that fails re-verification under Field 5 written notice and a period of thirty (30) calendar days in which to submit evidence of a Qualifying Function.
Please see full instructions in AGB Q151.1.
The Registry Operator shall revoke a registration where the registrant has not submitted evidence establishing a Qualifying Function by the expiry of the period in Field 6.
Please see full instructions in AGB Q151.1.
The Registry Operator shall refuse or revoke a registration where the registrant's use of the domain name is directed to promoting a distributed ledger, protocol, token or token system other than Bitcoin, including any use directed to non-fungible tokens, tokenised representations of fiat currency, or decentralized finance protocols other than those operating on the Bitcoin network.
Please see full instructions in AGB Q151.1.
The Registry Operator shall maintain and publish a record of each refusal and revocation made under this policy, stating the Field relied upon, with personal data of natural persons redacted.
Please see full instructions in AGB Q151.1.
The Registry Operator shall not grant itself, any affiliate, or any related party any priority, preference or exemption in the allocation of domain names in the TLD or in the application of this policy.
1. Draft the Community Registration Policy as proposed contract language. Policies that are approved by ICANN will be included in Specification 12 of the applicable Base Registry Agreement and will be subject to enforcement by ICANN Contractual Compliance. See Appendix 4 Base Registry Agreement, Specification 12 for drafting approach. Consider the usage of defined terms and the definitions of such terms in the 2026 Round Base RA. 2. Enter a single proposed Community Registration Policy with respect to name selection criteria or rules for the applied-for string in each response field. Up to 10 Community Registration Policies can be submitted. 3. These criteria or rules should align with the community objectives of the applied-for gTLD string. 4. Follow this format to propose what the Registry Operator must do and/or must not do: a) “Registry Operator shall___”; and/or b) “Registry Operator shall not___”. 5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars: a) ""Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or b) ""Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”. 6. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements: a) ""Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring___""; and/or b) ""Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting ___"". 7. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example: a) Registry Operator shall develop and implement a name selection rule and publish it on its website no later than the date on which the TLD is delegated in the DNS. b) Registry Operator shall review the name selection rule described in (a) at least once per year, and publish the results of such review (including any updates to the rule) on its website within thirty (30) days following the anniversary of the Effective Date. 8. If the Community Registration Policy is limited in time, duration, scope, or any other factors, specify the applicable limitations. For example, if a name selection rule is time-limited, the applying entity must state if the rule will apply for the lifetime of the gTLD, only during a specified period, or for some other defined period (such as, Registry Operator shall, for a period of x days from the Effective Date, ___). 9. See Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria for evaluation criteria that ICANN will apply for evaluating each proposed Community Registration Policy.
The Registry Operator shall require that each domain name registered in the TLD correspond to the registrant's name, to a trade mark or trade name held by the registrant, or to the service, publication, project or event by reference to which the registrant established its Qualifying Function.
Please see full instructions in AGB Q152.1.
The Registry Operator shall publish, and keep publicly available, a list of withheld terms comprising (a) terms that assert authority over, or official status in relation to, the Bitcoin protocol, its reference implementation or its standards process, and (b) terms that are the proper names of protocols, protocol layers, network components or standards artifacts of the Bitcoin network, together with the criterion by which a term is added to that list.
Please see full instructions in AGB Q152.1.
The Registry Operator shall refuse an application to register a domain name that is identical to a term on the list published under Field 2.
Please see full instructions in AGB Q152.1.
The Registry Operator shall release a term withheld under Field 2 only to an applicant that the Registry Policy Committee has determined, against published criteria, to be the body, project or service to which the term refers, and shall publish each such determination and release.
Please see full instructions in AGB Q152.1.
The Registry Operator shall refuse or revoke a registration where the domain name is identical to the name of another registrant in the TLD, or of a Bitcoin software project or service published on the list maintained under Field 2, and the registrant has not established that it is that person, project or service.
1. Draft the Community Registration Policy as proposed contract language. Policies that are approved by ICANN will be included in Specification 12 of the applicable Registry Agreement and will be subject to enforcement by ICANN Contractual Compliance. See Appendix 4 Base Registry Agreement, Specification 12 for drafting approach. Consider the usage of defined terms and the definitions of such terms in the 2026 Round Base RA. 2. Enter a single proposed Community Registration Policy in each response field. Up to 10 Community Registration Policies can be submitted. 3. Follow the format to propose what the Registry Operator must do and/or must not do: a) “Registry Operator shall___”; and/or b) “Registry Operator shall not___”. 4. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars: a) ""Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or b) ""Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”. 5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements: a) ""Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring___""; and/or b) ""Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting___"". 6. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example: a) Registry Operator shall develop and implement a Community Registration policy and publish this policy on its website no later than the date on which the TLD is delegated in the DNS. b) Registry Operator shall review the Community Registration Policy described in (a) at least once per year, and publish the results of such review (including any updates to the registration policy) on its website within thirty (30) days following the anniversary of the Effective Date. 7. If the Community Registration Policy is limited in time, duration, scope, or any other factors, specify the applicable limitations. For example, if a commitment is time-limited, the applying entity must state if the rule will apply for the lifetime of the gTLD, only during a specified period, or for some other defined period (such as, Registry Operator shall, for a period of x days from the Effective Date, ___). 8. See Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria for evaluation criteria that ICANN will apply for evaluating each proposed Community Registration Policy.
The Registry Operator shall publish, and keep publicly available, a means by which any person may report that a registrant in the TLD does not perform a Qualifying Function.
Please see full instructions in AGB Q153.1.
The Registry Operator shall acknowledge each report received under Field 1 within five (5) business days of receipt.
Please see full instructions in AGB Q153.1.
The Registry Operator shall determine each report received under Field 1 within thirty (30) calendar days of receipt and shall notify the reporter and the registrant of the determination.
Please see full instructions in AGB Q153.1.
The Registry Operator shall, where it determines under Field 3 that a registrant does not perform a Qualifying Function, apply the notice and cure procedure at Q151 Fields 6 and 7 to that registration.
Please see full instructions in AGB Q153.1.
The Registry Operator shall report annually to the Committee constituted under the Registry Policy Committee Charter the number of reports received under Field 1, the determinations made, and the number of registrations refused and revoked, and shall publish that report.
Please see full instructions in AGB Q153.1.
The Registry Operator shall refer to the Committee, for determination, any question as to whether an activity constitutes a Qualifying Function that is not resolved by the published list under Q151 Field 2.
Please see full instructions in AGB Q153.1.
The Registry Operator shall maintain and publish a register of Bitcoin layer-two protocols and consensus-compatible node software recognized for the purposes of the Eligibility fields above. A protocol or software shall be entered on that register where it settles to, or validates against, the Bitcoin blockchain, and the Registry Policy Committee has so determined on published criteria. The Registry Operator shall publish those criteria, shall determine each application for entry within sixty (60) calendar days of receipt, shall publish a written decision with reasons in each case, and shall provide a procedure by which a refused applicant may seek review of that decision.
Please see full instructions in AGB Q153.1.
The Registry Operator shall contribute twenty-one percent (21%) of its annual gross revenue from the operation of the TLD to the development and maintenance of Bitcoin open-source software, shall publish annually the amount contributed and the recipients, and shall report that amount to the Committee.
1. If you are proposing any limitation to a proposed Community Registration Policy in Questions 151-153, please provide a rationale in this response field. Please see Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria. 2. If you are not proposing any limitation to a proposed Community Registration Policy in Questions 151-153, please type ""Not Applicable"" in this response field.
Rationale. The limitations exist because the value of this namespace, both to the community and to the public, is constituted by the restriction rather than diminished by it. A domain name in this TLD is intended to carry a specific meaning - that its holder performs a verifiable function in operating, developing or providing the Bitcoin network and its services. That meaning is destroyed if the namespace is open, and it is the reason the community would be served by the TLD at all. The restriction is also proportionate to a demonstrable harm. Impersonation of Bitcoin services is endemic, and the public has no reliable means of distinguishing a genuine operator from an imitation. A namespace in which eligibility is verified, in which determinations are published, and in which registrations are revoked when qualification lapses supplies that means. Each limitation in Q151 and Q152 is directed to that end and goes no further: eligibility turns on functions that are externally observable, not on the Registry Operator's opinion; the withheld-term list is published together with its criterion, and terms are released to the bodies they name; and no priority is reserved to the Registry Operator or its affiliates. (4) Compatibility with the ICANN Bylaws. In the Registry Operator's view the policy is compatible with the Bylaws. It does not discriminate between similarly situated parties: every applicant performing any one of the published Qualifying Functions is eligible on the same terms, the Registry Operator and its affiliates included, and Q151 Field 10 forbids self-preference. It operates through published, objective criteria applied uniformly, with determinations published and an avenue of interpretation vested in a committee that is not controlled by the Registry Operator, which serves the Bylaws' commitments to openness and to accountability. It is confined to the technical and administrative operation of the TLD and does not purport to regulate content, expression or conduct beyond the namespace. (5) Whether an additional Registry Service is required. The policy requires the verification of evidence submitted by applicants and registrants. Whether that verification is provided as an additional Registry Service is addressed in the application's Registry Services section, in consultation with the Registry Service Provider.
1. Provide an explanation of how the proposed Community Registration Policies meet the Registry Commitments Evaluation criteria 4 and 5 using the considerations in the Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria. 2. Consider whether the proposed Community Registration Policy could be argued to be duplicative of a requirement under applicable law, ICANN agreements, or ICANN Consensus Policies or Temporary Policies. There may be circumstances in which a Community Registration Policy that would duplicate requirements under applicable consensus policy or law could be approved at ICANN’s sole discretion. If not duplicative, please explain why you believe the Community Registration Policy is not duplicative. If yes, please specify such a requirement and explain why you believe duplication in the Base RA is necessary. 3. Consider whether the proposed Community Registration Policy could be argued to be contrary to a requirement under applicable law, ICANN agreements, or ICANN Consensus Policies or Temporary Policies. ICANN will not approve any Community Registration Policies that are found to be contrary to applicable laws, ICANN agreements and policies. Please share your views on this issue in the answer to this question. 4. Consider whether the proposed Community Registration Policy could be argued to be incompatible with ICANN’s Bylaws. ICANN will not approve any Community Registration Policies that are found to be incompatible with the ICANN Bylaws. See background at the ICANN Board resolution 2024.06.08.08-2024.06.08.10. Please share your views on this issue in the answer to this question. 5. Consider whether the proposed Community Registration Policy requires the operation of an additional Registry Service. The applying entity shall engage its selected RSP to discuss the implementation of such an additional Registry Service, which must be evaluated through the RSP Program and approved by ICANN.
(a) The policy is not duplicative of existing ICANN rules. The commitments are confined to matters the base Registry Agreement does not address. The Agreement does not condition registration on the registrant's performance of any function, does not provide for verification of eligibility or for re-verification at renewal, and does not provide a channel for reports that a registrant is not eligible. The policy deliberately excludes the matters the Agreement already governs: it does not restate the abuse point of contact required by the Agreement, the reserved names ICANN requires, or the rights protection mechanisms the Agreement imposes. The eligibility-complaint procedure at Q153 is directed to eligibility alone and operates alongside, not in place of, the Agreement's abuse provisions. (b) The policy is not contrary to law, agreements or policies. It imposes no obligation on any registrant that is unlawful in any jurisdiction and confers no right the Registry Operator does not hold. It does not restrict any registrant's use of the Bitcoin network, only eligibility to hold a name in this TLD. It does not conflict with the Registry Agreement, with Consensus Policies, or with the dispute resolution procedures to which the Registry Operator is subject; determinations under Q153 do not displace those procedures and are without prejudice to them. (c) The policy is compatible with the ICANN Bylaws. It does not discriminate between similarly situated parties: every applicant performing any published Qualifying Function is eligible on the same terms, the Registry Operator and its affiliates included, and Q151 Field 10 forbids self-preference. It operates through published, objective criteria applied uniformly, with determinations published and interpretation vested in a committee the Registry Operator does not control, serving the Bylaws' commitments to openness and to accountability. It is confined to the technical and administrative operation of the TLD and does not purport to regulate content, expression or conduct beyond the namespace. (d) The policy requires no additional Registry Service. Eligibility is verified from public evidence, the reachable node, the commit history, the operating service, the published work, the event record, outside the registry's technical systems, and registrations are processed through standard registry services once verification concludes. No new Registry Service within the meaning of the RSP Evaluation Program is created, and none is requested.
Community Endorsement
Please provide evidence of support for the applying entity’s application by attaching written endorsements from the organizing bodies relevant to the identified community (related to Question 136).
Support comes from the organizing bodies identified at Q136 and operators in all five functional categories. Fifty-six written statements from fifty-five endorsing parties are attached: fifty-one endorsements from within the community, and five statements of recognition from outside it. From the operators of the community's constitutive infrastructure and the maintainers of its software. Four of the seven DNS seed operators identified at Q136, beyond the applicant, endorse in their own names: Sjors Provoost, Ava Chow (a maintainer of the reference implementation), Stephan Oeste and Matt Corallo, each named with their seed hostnames in the implementation's source. With the applicant's own seed, a majority of the seed set stands behind the application. Blockstream, whose chief executive authored the proof-of-work scheme cited in the founding specification, endorses (two hundred professionals, six continents). Brink, funding nine of the roughly forty protocol maintainers, and OpenSats, four hundred grants exceeding thirty-five million dollars across forty countries, endorse as its funding bodies. Named contributors, the maintainer of Utreexo, the founder of Sparrow Wallet, and Fulmo (Lightning Hackdays; 4,300 registered members) endorse; RaspiBlitz reports 193 contributors, Bisq roughly 50. Lightning Labs, maintainer of lnd and btcd, over 450 repository contributors, endorses in full. From the community's convening and publishing bodies. BTC Inc, publisher of Bitcoin Magazine since 2012, whose 2025 events drew approximately 67,000 attendees across several continents; BTC Prague, Europe's largest, with 110 partner organizations; bitcoin++, in its 18th edition; TABConf; Bitcoin Park, more than 6,000 members; Baltic Honeybadger, Europe's longest-running; Plan B Network of Lugano; Einundzwanzig, whose network has held 310 meetups; and Bitcoin Austria, convener of more than 200 public meetups, signing with a government-verifiable qualified electronic signature. From those who provide the network's mining infrastructure. Antpool, Foundry and SpiderPool state approximately 18.5%, 29% and 9% of global hashrate, together more than half of the network's, verifiable standing rather than headcount; and the 256 Foundation. From service operators and educators. Swan; Unchained; Bull Bitcoin; Zaprite; JAN3; 21bitcoin; Shock Network; AnchorWatch, whose Lloyd's-regulated custody insures up to $370 million per customer; and Blocktrainer, the largest German-language Bitcoin education platform. From communities outside the network's established centers. Bitcoin Ekasi, roughly 500 weekly transactors and about 70 merchants, and Bitcoin Beach of El Zonte, where the country's adoption began. Recognition from beyond the identified community, exhibited with Q146, not counted among the endorsements. El Salvador's Vice Minister of Foreign Affairs, under seal, recognizes the community and records no objection (MRREE/2026); the National Artificial Intelligence Agency of El Salvador; a United States Senator, recognizing this community by its functions; the Human Rights Foundation, whose Bitcoin Development Fund has awarded $11.8 million across 68 countries; and the Bitcoin Policy Institute. How the applicant measures this support. The statements answer the applicant's published notice, filed as received. User populations served by endorsers, 10,000 to over 100,000 each, are outside the community and not counted; the applicant counts the organizations and the contributors and member bodies they state they represent. The bodies through which the wider bitcoin-using population reaches the network have supported the application, and no organization representing that population has stated opposition. Reach. The endorsements come from bodies and operators established in thirteen jurisdictions across the Americas, Europe and Africa, corresponding to the distribution of the network the community operates.
Provide an explanation of why opposition may or may not be relevant or how the applying entity intends to address or resolve the opposition, if applicable.
The applicant discloses the opposition it anticipates unasked. 1 - Competing applicants for the same string. The applicant is aware of multiple parties positioned to seek this string for commercial purposes: blockchain-naming firms selling or brokering top-level labels, including operators already distributing .bitcoin labels outside the authoritative root, at least one of which has publicly stated an intention to apply. The applicant expects the string to be heavily contested, by commercial actors outside the identified community whose interest is the sale of names to the public rather than service to the community the string names. The points below apply to that class, whichever of its members files. They are not members of the identified community. An undertaking directed to a separate naming system does not run, build or provide the Bitcoin network's infrastructure, software or services. Its opposition is opposition from outside. Their opposition would carry a competing commercial interest. The Guidebook directs the panel to weigh whether opposition is spurious, unsubstantiated or filed for obstruction; opposition by a rival applicant for the identical string, which gains directly from this application's failure, is assessed on that footing. Prior distribution of .bitcoin labels outside the authoritative root confers no standing. Those labels do not resolve in the Domain Name System. They confer no priority: standing in this round rests on community establishment, nexus, policy and endorsement, none of which is satisfied by selling strings in a namespace of one's own construction, and such sales create no trademark or other recognized right. ICANN's position is that the root is unique and names issued outside it acquire no status within it. 2 - Principled objection from within the community: that no single party should hold .bitcoin, or that restriction centralizes an ecosystem that resists centralization. The answer is structural: Policy authority is vested in a committee of the community's relevant bodies; the applicant holds one seat, has no casting vote and no veto, and abstains where its registry interest is engaged. Every seat is filled only with the written consent of its holder; an unconsented seat stays vacant, and the applicant may neither fill nor vote it. The applicant receives no registration priority: every party meeting the published eligibility criteria has the same opportunity on the same terms. The committee's authority is confined to this domain's policy; it expressly disclaims authority over the consensus rules, implementations, the operation of the network, the standards process, and anyone's participation in Bitcoin. Nothing it decides can exclude anyone from Bitcoin. These guarantees are entrenched: the committee cannot amend them. 3 - Objection to restriction as such. A party may object that eligibility rules exclude it, or that the identified community is narrower than the string suggests. Restriction is the purpose, not a side effect: the namespace's value to the community, and its public utility as a mark of a bona fide participant, exists only because eligibility is verified. The applicant has tested that objection instead of asserting an answer to it. Community members operating wallet, exchange, custody, payment and publishing services, whose services reach several hundred thousand people outside the identified community, have provided written support. The organizations best placed to object on behalf of that wider population, were the definition to disadvantage it, have supported the application instead, and the applicant is aware of no opposition from any body representing it. Resolution. Objection from within the community is engaged directly and through the committee, with any resulting policy change placed before it for decision; opposition from outside, motivated by a competing claim to the string, is addressed on the record under the Guidebook's procedures.
Section: Safeguard Identification
This question set collects information related to determining whether certain Safeguard Public Interest Commitments (Safeguard PICs) are required for the applied-for gTLD string. See Section 7.8.2.3 Safeguard PICs. Answers to these questions will inform assessment by ICANN on whether and which Safeguard PICs must be incorporated in the applicable Registry Agreement (RA) if the string proceeds to delegation. The answers themselves will not automatically make such a determination.
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. I-2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. I-2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
Select Yes or No. Notes: 1. ICANN will evaluate whether an applied-for gTLD string requires one or more Safeguard Public Interest Commitments (Safeguard PICs) to be included in the Base RA). 2. In addition to the Mandatory Public Interest Commitments (PICs) that must be included in each Base RA, a subset of Base RAs must include Safeguard PICs based on ICANN’s Safeguard Assessment. See Section 7.8.2.3 Safeguard PICs. 3. Applying entities for TLDs that are not found to require Safeguard PICs can elect to add them to the applicable Base RAs voluntarily to, for example, further their business objectives, help address issues or concerns that are raised or could be raised with respect to their applications, or avoid the need for the evaluation and implementation of customized Registry Voluntary Commitment (RVC). See Section 7.8.3 Registry Voluntary Commitments (RVCs).
No
Section: Registry Voluntary Commitments (RVCs)
This question set collects information related to any Registry Voluntary Commitments (RVCs) that the applying entity is submitting. The decision to submit an RVC is typically voluntary, except for those recognized by ICANN to resolve an objection or to address GAC Consensus Advice. See Section 7.8.3 Registry Voluntary Commitments for more information.
1. Select Yes or No. 2. In addition to Safeguard Public Interest Commitments (PICs), an applying entity will be permitted to propose one or more Registry Voluntary Commitments (RVCs) to provide additional safeguards with regard to the registry operator’s operation of an applied-for gTLD string. See Section 7.8.3 Registry Voluntary Commitments (RVCs). 3. RVCs are separate from Community Registration Policies. See Section 7.8.3 Registry Voluntary Commitments (RVCs) and Section 7.8.4 Community Registration Policies for more information. If you are applying for a Community gTLD, please submit the Community Registration Policies by answering Questions 150-155. However, if you propose to include additional Registry Voluntary Commitments in the RA beyond the Community Registration Policies, you may answer "yes" and proceed to answer the following questions. 4. You are encouraged to consider whether there are other means, separate from including commitment(s) in the Base RA, that could be used to further your business objectives or help resolve any anticipated or actual issue(s) raised regarding the applied-for gTLD string or application. See Section 7.8.3 Registry Voluntary Commitments (RVCs). Notes: If you select “yes” to this question, you are required to pay the conditional Registry Commitments Evaluation fee, and commitments that are approved by ICANN will be included in Specification 11 of the applicable Base RA as specific voluntary public interest commitments as contractual obligations.
No
Section: Brand & Code of Conduct Exemptions
This question set collects information related to whether the applied-for gTLD string is a .Brand (see Section 7.3) or if the applying entity is seeking a Code of Conduct exemption (see Section 7.4).
Select Yes or No
No
This serves as an indication of intent to apply for an exemption to Specification 9 and that the applying entity is NOT requesting to be designated a .Brand TLD, pursuant to Specification 13.
No
Section: Additional Information and Supporting Materials
This question set collects any additional information that the applying entity would like to provide, including any supporting materials.
Section: Bona Fide Intent and Prohibited Communications
This question set contains attestations related to the applying entity’s acknowledgment of bona fide intent and prohibited communications.
Confirm the statement using the checkbox.
true
Confirm the statement using the checkbox.
true