.bitcoin

Q4.2-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. If financial statements are provided by a Qualified Parent Entity (QPE), the CEO, President, CFO, and/or equivalent officer of the QPE must co-sign the certification document. The self-certification document must represent and warrant: SC4.2-1.1 - The applying entity and/or a QPE will fund the startup and long-term operation of all applied-for gTLD strings and (if applicable) currently operated gTLDs of a QPE. SC4.2-1.2 - The applying entity or QPE has at a minimum of US$50,000 plus 25% of the application base fee for each applied-for gTLD string in Cash and Cash Equivalents on the balance sheet of the provided financial statements, up to a maximum of US$300,000, designated to support the startup and operation of all of the applying entity’s applied-for gTLD strings. SC4.2-1.3 - The applying entity and/or its officers are bound by law in its jurisdiction to represent financial statements accurately and the applying entity is in good standing in that jurisdiction.

Réponse fournie sous forme de document. L'ICANN ne publie pas les pièces jointes.

Q5.1-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. The self-certification document must represent and warrant: SC5.1-1.1 - The applying entity will appropriately protect confidentiality of data and prevent unauthorized access to data and services. SC5.1-1.2 - The applying entity will maintain a mature, appropriately funded and staffed security program, following a recognized, modern security framework based on risk management (such as the ISO27000 series, COBIT, HITRUST CSF, legally required security frameworks, or equivalent). The security program must be in place prior to delegation, and exist through at least the period of the registry agreement. SC5.1-1.3 - The applying entity is aware of and has designed its systems and business to comply with the relevant privacy and security regulations for all countries in which it operates.

Réponse fournie sous forme de document. L'ICANN ne publie pas les pièces jointes.

Q5.2-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. The self-certification document must represent and warrant: SC5.2-1.1 - The applying entity will, no later than delegation of the Top Level Domain (TLD), establish a dedicated abuse point of contact responsible for addressing matters requiring expedited attention and providing a timely response to abuse complaints concerning any name registered in the TLD. SC5.2-1.2 - The applying entity will, no later than delegation of the TLD, establish, publish, and provide to ICANN the location of a mechanism for members of the public to submit reports of abuse in accordance with the current obligations of the Base RA and any Consensus Policies. SC5.2-1.3 - The applying entity has developed proposed measures for removal of orphan glue records for names removed from the zone when provided with evidence in written form that the glue is present in connection with malicious conduct (see Specification 6). SC5.2-1.4 - The applying entity has or will have at time of delegation, established policies for handling complaints regarding abuse. Such policies are to be maintained and posted publicly so that anyone can review the policies via the Internet and any other means deemed appropriate by the applying entity. The applying entity’s policies at a minimum should contain appropriate confirmation of the receipt of the abuse report, the process of review of the report, and actions that will be taken if the applying entity confirms the report is legitimate. SC5.2-1.5 - The applying entity understands that DNS Abuse is Phishing, Malware, Botnets, Pharming and Spam (when used to deliver other forms of DNS Abuse). The applying entity understands and is prepared to contribute to the mitigation or disruption of DNS Abuse in domains in the TLD zone. SC5.2-1.6 - The applying entity’s abuse response capabilities are resourced appropriately to ensure a timely and adequate investigation and response to reports of DNS Abuse. This includes capabilities to receive and evaluate evidence of DNS Abuse in reports, and to take action to stop or disrupt the DNS Abuse. SC5.2-1.7 - The applying entity is prepared to conduct periodic scans of its zone to identify if domains are being used to perpetrate DNS Abuse, and to maintain statistical reports of the scans, the findings, and actions taken.

Réponse fournie sous forme de document. L'ICANN ne publie pas les pièces jointes.

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

true

How would you categorize your community?

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.

What is the applying entity's connection to the 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.

How is the community organized? Are there one or multiple organizations ("organizing body") that represent or administer 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.

Does the community have defined membership requirements, such as registration, licensing, or use of specific communication? Or, do community members self-identify as part of the community?

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.

Where is the community located?

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.

What is the estimated size of the community? This should take into account any regions listed in Question 138.

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.

What portion of the community do any organizing bodies represent or administer to?

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.

Do the organizing bodies demonstrate active and consistent efforts to engage and connect with the identified community and its members?

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.

Réponse fournie sous forme de document. L'ICANN ne publie pas les pièces jointes.

What is the role of the applying entity in the engagement efforts listed in Question 141?

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.

Are community members aware of the identified community and each other?

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.

Are community members aware of the applying entity and its intention to apply for a community gTLD?

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.

Réponse fournie sous forme de document. L'ICANN ne publie pas les pièces jointes.

Was there an established presence of the identified community prior to the opening of the application submission period?

Yes

Réponse fournie sous forme de document. L'ICANN ne publie pas les pièces jointes.

Are individuals and groups outside of the identified community aware of the existence of the identified community?

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.

Réponse fournie sous forme de document. L'ICANN ne publie pas les pièces jointes.

Are the pursuits of the identified community enduring and sustainable?

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).

Réponse fournie sous forme de document. L'ICANN ne publie pas les pièces jointes.

Does the string match the name of the identified 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.

Will the general public instinctively think of the community when thinking of the applied-for string?

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.

Are you proposing to include one or more Community Registration Policies in the Registry Agreement (RA) that are unique to the applying entity's applied-for community gTLD?

Yes

Please state a specific Community Registration Policy with respect to registration eligibility for community members.

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.

If there is an additional proposed policy, please state the specific Community Registration Policy with respect to registration eligibility for community members.

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.

If there is an additional proposed policy, please state the specific Community Registration Policy with respect to registration eligibility for community members.

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.

If there is an additional proposed policy, please state the specific Community Registration Policy with respect to registration eligibility for community members.

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.

If there is an additional proposed policy, please state the specific Community Registration Policy with respect to registration eligibility for community members.

The Registry Operator shall require and verify evidence of continued performance of at least one Qualifying Function at each renewal of a registration.

If there is an additional proposed policy, please state the specific Community Registration Policy with respect to registration eligibility for community members.

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.

If there is an additional proposed policy, please state the specific Community Registration Policy with respect to registration eligibility for community members.

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.

If there is an additional proposed policy, please state the specific Community Registration Policy with respect to registration eligibility for community members.

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.

If there is an additional proposed policy, please state the specific Community Registration Policy with respect to registration eligibility for community members.

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.

If there is an additional proposed policy, please state the specific Community Registration Policy with respect to registration eligibility for community members.

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.

State a specific Community Registration Policy with respect to name selection criteria or rules for the applied-for string.

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.

If there is an additional proposed policy, state the specific Community Registration Policy with respect to name selection criteria or rules for the applied-for string.

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.

If there is an additional proposed policy, state the specific Community Registration Policy with respect to name selection criteria or rules for the applied-for string.

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.

If there is an additional proposed policy, state the specific Community Registration Policy with respect to name selection criteria or rules for the applied-for string.

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.

If there is an additional proposed policy, state the specific Community Registration Policy with respect to name selection criteria or rules for the applied-for string.

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.

State a specific Community Registration Policy with respect to an additional commitment besides registration eligibility for community members and naming selection criteria or rules for the applied-for string.

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.

If there is an additional policy, state the specific Community Registration Policy with respect to an additional commitment besides registration eligibility for community members and naming selection criteria or rules for the applied-for string.

The Registry Operator shall acknowledge each report received under Field 1 within five (5) business days of receipt.

If there is an additional policy, state the specific Community Registration Policy with respect to an additional commitment besides registration eligibility for community members and naming selection criteria or rules for the applied-for string.

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.

If there is an additional policy, state the specific Community Registration Policy with respect to an additional commitment besides registration eligibility for community members and naming selection criteria or rules for the applied-for string.

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.

If there is an additional policy, state the specific Community Registration Policy with respect to an additional commitment besides registration eligibility for community members and naming selection criteria or rules for the applied-for string.

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.

If there is an additional policy, state the specific Community Registration Policy with respect to an additional commitment besides registration eligibility for community members and naming selection criteria or rules for the applied-for string.

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.

If there is an additional policy, state the specific Community Registration Policy with respect to an additional commitment besides registration eligibility for community members and naming selection criteria or rules for the applied-for string.

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.

If there is an additional policy, state the specific Community Registration Policy with respect to an additional commitment besides registration eligibility for community members and naming selection criteria or rules for the applied-for string.

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.

Explain the rationale for any limitations to the Community Registration Policy proposed by the applying entity in Questions 151-153.

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.

Explain how the proposed Community Registration Policies of the applying entity meets the Registry Commitments Evaluation criteria 4 and 5?

(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.

From where does the applying entity have the support to run the applied-for string on behalf of the identified community?

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.

Réponse fournie sous forme de document. L'ICANN ne publie pas les pièces jointes.

Is there any opposition to the applying entity, application, or applied-for string that the applying entity is aware of? If yes, please explain.

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.

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

true

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

true