Instantané du 8 octobre 2026 · ICANN APS, champs publics

Candidatures / .avax / ANL2619T-T13025 · publié par l'ICANN le 7 octobre 2026 · instantané du 2026-10-08

.avax

CommunautéActive

Avax Naming Limited, VG Q1·Q25

Contrôle ultime déclaré : Red Rock (Cayman) Foundation Q108 · Fiche ICANN ↗

Opérateur de registre, bureau d'enregistrement ou affilié existant, tel que déclaré : Q12

The applying entity is an Affiliate of Interstellar Registrar Limited, a British Virgin Islands company and ICANN-accredited registrar (IANA ID 3784). The applying entity and Interstellar Registrar Limited are under the common control of their parent, Red Rock (Cayman) Foundation. The applying entity is not itself an existing registry operator or ICANN-accredited registrar.

§ 1 — Sens de la chaîne Q118·Q120

No English Translation. “AVAX” is the established symbol of Avalanche’s native utility token and a recognized shorthand identifier for the Avalanche network, ecosystem, and community.

/ˈæv.æks/ (“AV-aks”)

§ 2 — Mission et objet Q133

The mission of .avax is to establish a trusted, stable, and enduring Internet namespace for the global Avalanche community. AVAX is the established symbol of Avalanche’s native utility token and a recognized shorthand identifier for its network and ecosystem. The TLD will carry that identity into the ICANN-administered Domain Name System, providing community-aligned DNS identities for websites, applications, services, and organizations.

The Avalanche community is global, open, and activity-based. Members develop software; operate validators and Avalanche L1s; use wallets and applications; build services across DeFi, gaming, enterprise, creator, SocialFi, and consumer sectors; provide infrastructure and security; and participate in grants, events, forums, and regional initiatives.

Intended registrants are persons and organizations participating in or affiliated with the ecosystem, including developers, validators, L1 builders and operators, funded-wallet users, application teams, infrastructure providers, grant recipients, enterprises, educators, creators, regional organizations, and verified program participants. Eligibility will be governed by the Community Registration Policies in Q151-Q153. Intended users include community members and the public seeking to identify and interact with Avalanche-aligned participants and resources.

The namespace will complement Avalanche’s wallet, identity, application, and on-chain infrastructure while remaining technically distinct from it. A .avax domain will be delegated through the ICANN root and resolve through the Domain Name System. Registration will not create an on-chain identifier, require blockchain-based resolution, or establish an alternative naming root. Optional integrations may associate .avax domains with ecosystem functionality without changing their authoritative operation in the DNS.

Avalanche Foundation, a leading supporter of the ecosystem, formally endorsed Avax Naming Limited after reviewing its proposed structure, relevant ICANN and domain-industry experience, registry infrastructure, and community registration framework. Ava Labs, Avant Protocol, BENQI, LFJ, Pangolin, and The Arena separately support the application from their roles across protocol development, lending and liquid staking, stablecoin and yield, trading and liquidity, community-governed DeFi, and SocialFi and creator activity. Avax Naming is the dedicated applicant and proposed registry operator through which the community-supported initiative is pursued. It independently retains responsibility for the application and, if delegated, registry governance, policies, operations, and ICANN compliance.

Activities undertaken or planned include pursuing the ICANN application; consulting with Avalanche Foundation, Ava Labs, and organizations serving important segments; developing and enforcing community eligibility, name-selection, and review policies; establishing qualified registry infrastructure; distributing registrations through ICANN-accredited registrars; conducting community-focused launch activities; publishing verification procedures; supporting appropriate integrations; and maintaining DNS security, abuse mitigation, data escrow, continuity, and compliance.

The purpose is sustainable because continuing network development, validation, L1 deployment, application activity, community programs, and global use create recurring needs for trusted identity, discoverability, authentication, and navigation. Registration and renewal revenue will support operations, while established registry infrastructure, registrar distribution, and ICANN continuity requirements provide a durable framework independent of any single application, market cycle, or participant.

§ 3 — Engagements et sauvegardes Q164–Q188

Confiance accrue, risque pour le consommateur, secteur réglementé, déclarations à l'État, préjudice, fonction régalienne Q164–Q169Non à chacune
PIC de sauvegarde volontaires Q170·Q171Aucun · 90 candidatures de la ronde en proposent
Registry Voluntary Commitments Q172·Q173Aucun · 5 en proposent
TLD communautaire Q131·Q132

The Avalanche community: a global, online, activity-based community of developers, validators, L1 creators, wallet users, application and infrastructure organizations, and verified participants who build, operate, use, or support the Avalanche ecosystem.

Exemption du Code de conduite demandée Q185·Q188Non

§ 4 — Toutes les autres réponses publiées

Toutes les autres réponses que l'ICANN a publiées pour cette candidature, dans l'ordre du formulaire. Les coordonnées (Q17–Q24) sont laissées à la fiche ICANN.

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

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.

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

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.

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

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.

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

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

Q134How would you categorize your community?

How would you categorize your community?

The Avalanche community is best categorized as a global, online, activity-based technology community centered on the open-source Avalanche protocol, its Primary Network, and the ecosystem of Avalanche L1s and applications built upon it.

The community comprises developers who build and deploy software; independent validators and L1 operators who operate and secure networks; funded-wallet users; organizations that build applications, protocols, wallets, and infrastructure; grant recipients; researchers, educators, creators, enterprises, and other contributors; and verified participants in recognized ecosystem and regional programs.

Like other open-source technology communities, affiliation follows from participation rather than admission by a single centralized membership body. The community is broader than any one company, application, or token-holder group, but its boundaries are not based solely on an unsupported assertion of interest.

Participation is objective and observable. It may be demonstrated through control and use of a funded Avalanche wallet; operation of an Avalanche validator or L1; deployment of a smart contract, application, or other software to Avalanche; contribution to public technical repositories; receipt of an Avalanche Foundation grant; or documented participation in a recognized builder, accelerator, research, education, ambassador, validator, regional, or other ecosystem program. These connections can be confirmed through public network and software records or the records of institutions administering the applicable programs.

Avalanche Foundation is a leading ecosystem-wide support institution. Ava Labs and independent technical contributors advance Avalanche technology and tooling. Validators and L1 operators provide decentralized network operations, while independent organizations serve particular functional segments. The supporting organizations accompanying this application illustrate that structure: BENQI serves lending, liquid-staking, and validator participants; Avant Protocol serves stablecoin, lending, yield, and liquidity participants; Avant Protocol serves stablecoin, lending, and liquidity participants, while LFJ and Pangolin serve trading, liquidity, and governance communities.

These participants are connected by shared technology, technical standards, public network records, established institutions and communication channels, grants and developer programs, recurring events and hackathons, and the common purpose of developing, operating, securing, supporting, and using Avalanche.

Accordingly, the Avalanche community is not merely an audience, social-media following, collection of AVAX holders, or group defined by general interest in blockchain technology. It is an established open-technology community whose members have identifiable technical, operational, economic, institutional, educational, or programmatic connections to the Avalanche ecosystem.

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

Q135What is the applying entity's connection to the community?

What is the applying entity's connection to the community?

Avax Naming’s connection arises from institutional endorsement. Avalanche (BVI), Inc. dba Avalanche Foundation evaluated the .avax initiative and formally endorsed Avax Naming as the appropriate applicant and ICANN operating partner for the community.

That endorsement followed deliberate review. The Foundation evaluated the ICANN new gTLD opportunity and the role an Avalanche-aligned DNS namespace could play in the ecosystem’s long-term development. It considered the need for technically capable, ICANN-compliant operation aligned with DNS and Avalanche-native participants. The Foundation reviewed Avax Naming’s proposed structure, ICANN and domain-industry experience, registry-services infrastructure, and community-based registration framework. Following internal review and leadership discussion, its Board approved the endorsement on June 26, 2026. The written endorsement records the determination that Avax Naming is the appropriate applicant and supports operation of .avax for the community.

The operator must connect an ICANN-administered DNS namespace with Avalanche identity, developer, wallet, application, validator, and community infrastructure while preserving DNS stability and ICANN compliance. Avax Naming is a dedicated special-purpose registry entity formed to perform that function. Its leadership and advisers provide relevant ICANN and domain-name experience; contracted service providers contribute Web3-native infrastructure and product capabilities; and its designated Registry Services Provider will provide established registry infrastructure, abuse mitigation, rights protection, continuity, and compliance capabilities.

The connection is corroborated by organizations serving important community functions. Ava Labs, the original developer and a principal technical contributor to Avalanche, supports the application from its protocol, technology, and ecosystem role. BENQI supports lending, liquid staking, and validator participants. Avant Protocol supports stablecoin, lending, yield, and liquidity participants. LFJ supports trading, liquidity, applications, and users as a major decentralized exchange on Avalanche. Pangolin supports DeFi users and a community-governed protocol ecosystem. The Arena supports SocialFi, creator, collector, and digital-asset participants and reports more than 220,000 monthly users across the ecosystem. Their signed letters identify Avax Naming, support the Foundation’s endorsement and the .avax application, and describe the anticipated benefits of a trusted DNS namespace for their participants.

Avax Naming is not a corporate affiliate or subsidiary of Avalanche Foundation, Ava Labs, Avant Protocol, BENQI, LFJ, Pangolin, or The Arena, and no endorsement confers ownership, control, or decision-making authority over the applicant or registry. Contracted service relationships provide technical and operational support without displacing Avax Naming’s accountability. Avax Naming independently retains sole responsibility for the application and, if delegated, ultimate responsibility for registry governance, policies, operations, and compliance with the Registry Agreement. The Foundation and supporting organizations provide endorsement, knowledge, and anticipated participation without directing registry decisions.

This structure connects a community-supported initiative with the specialized capability required by ICANN. It preserves Avax Naming’s independent accountability while allowing organizations serving ecosystem-wide support, stablecoin, lending, liquidity, trading, DeFi, governance, SocialFi, creator, and user functions to support the namespace and the commitments in Q151-Q153.

Corresponding documentation includes the Foundation’s written endorsement and supporting letters from organizations serving the identified functional segments.

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

Q136How is the community organized? Are there one or multiple organizations ("organizing body") that represent or administer the community?

How is the community organized? Are there one or multiple organizations ("organizing body") that represent or administer the community?

The Avalanche community is an open, global, activity-based technology community organized around the Avalanche network. It is not governed by one membership association or individual leader. Its organization is distributed among an ecosystem-wide support institution, a designated ICANN body, technical contributors, validators and L1 operators, and organizations serving particular activities.

Avalanche Foundation is the community’s leading ecosystem-wide support institution and principal organizing body for programs spanning the broader community. It supports ecosystem growth, developer engagement, adoption, infrastructure, grants, events, education, and strategic initiatives across developers, validators, builders, enterprises, projects, users, and regional participants. Its programs and relationships support the ecosystem as a whole. The Foundation acts through its Board of Directors and approved its endorsement of Avax Naming following the review described in Q135. It supports community development without owning or controlling the decentralized protocol or independent Avalanche L1s.

For the limited DNS function, Avalanche Foundation endorsed Avax Naming Limited as the community’s applicant and ICANN operating partner. Avax Naming represents the community for this application and, if delegated, will administer .avax under its Registry Agreement and the commitments in Q151-Q153. It does not govern the Avalanche protocol, Primary Network, or individual L1s and does not replace the community’s other institutions.

Ava Labs is the original developer and a principal technical contributor to Avalanche. It develops AvalancheGo, developer tooling, wallet and application infrastructure, and other ecosystem technology. AvalancheGo and related software are maintained through public repositories in which contributors are identifiable. Ava Labs provides technical leadership and products but does not administer the community as a whole.

A separate operational layer is provided by Primary Network validators and the validator sets of individual Avalanche L1s. Validators operate nodes, participate in consensus, validate transactions, and secure their networks under published requirements. Avalanche’s P-Chain maintains the public validator registry. Each Avalanche L1 is sovereign and may establish its own membership, validation, governance, and token-economic rules. No single validator, L1, or validator association represents the wider community.

Independent organizations administer services and communities for functional segments. BENQI serves lending, liquid-staking, and validator participants; Avant Protocol serves stablecoin, lending, yield, and liquidity participants; LFJ serves trading, liquidity, application, and user communities; The Arena serves users, creators, collectors, and digital-asset participants through a SocialFi application on Avalanche; and Pangolin serves DeFi users through a community-governed protocol. Their letters demonstrate active participation, service to meaningful segments, and support for .avax and the Foundation’s endorsement of Avax Naming. They act for their own organizations and programs, not with authority over the community as a whole.

The structure is functional rather than hierarchical: Avalanche Foundation provides ecosystem-wide support and coordination; Avax Naming performs the designated DNS role; Ava Labs and public contributors advance the technology; validators and L1 operators secure networks; and ecosystem organizations administer their own protocols and communities.

Relevant leaders include Aaron Unterman, an Avalanche Foundation Director and signatory to its endorsement; Emin Gün Sirer, Chief Executive Officer of Ava Labs; John Wu, President of Ava Labs and a key ecosystem-facing leader; and the executives who signed the ecosystem letters. Each acts through an identified institution; none claims personal authority over the Avalanche community as a whole.

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

Q137Does 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?

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?

The Avalanche community has no single universal admission, licensing, or membership-registration process. It is an open, participation-based community in which individuals and organizations become members through conduct connecting them to the Avalanche network and ecosystem. Members self-identify through that participation, but affiliation does not rest solely on an unsupported assertion of interest: the underlying activity is generally observable or documented.

People and organizations join through several established paths. They may operate and control an Avalanche Mainnet wallet address; deploy smart contracts, applications, infrastructure, or an Avalanche L1; operate a node or validator; hold an on-chain .avax name issued through documented Avalanche naming infrastructure; contribute code, documentation, education, content, events, or other ecosystem promotion; participate in an Avalanche Community Proposal; join the official Forum or regional channels; receive an Avalanche Foundation or Team1 grant; participate in a recognized builder, research, education, accelerator, ambassador, university, or regional program; or operate an organization providing services to Avalanche participants.

The degree of formality depends on the path. Wallet use, software development, public-repository contribution, ecosystem promotion, and Forum participation are generally open and self-directed. The Avalanche Community Proposal framework permits anyone to propose an improvement, subject to published formatting, public discussion, and consensus-building procedures. Primary Network validators must satisfy published protocol, staking, technical, and uptime requirements. Each sovereign Avalanche L1 may establish additional requirements for its own validators or participants.

Foundation grants, Team1 membership and grants, accelerators, research programs, university initiatives, and other recognized programs use applications, eligibility requirements, selection processes, and institutional records. Team1 maintains a membership portal and application process for its global network of builders, developers, creatives, gamers, and community members. These programs provide additional paths into particular segments without serving as a universal gatekeeper.

Participation can be evidenced through public records showing wallet activity, smart-contract or L1 deployment, validator operation, and qualifying on-chain names; repositories and ACP records identifying contributors and authors; Forum discussions; evidence of education, content, events, integrations, or other support; and records of institutions administering grants and programs. These mechanisms distinguish participants from people who merely know of or express an interest in Avalanche.

Members do not receive uniform community-wide rights. Their benefits and responsibilities follow their participation and may include use of network infrastructure, access to technical resources and channels, collaboration, proposal participation, validator rewards, or program-specific funding, mentorship, events, education, and support.

The Community Registration Policy in Q151 does not create or exhaustively define the Avalanche community. It draws from participation paths capable of producing objective, confirmable evidence and translates them into registrant-eligibility criteria. It also permits prospective eligibility based on an intention to satisfy a criterion within 90 days and contains a limited trademark-holder exception intended to protect rights and promote a safe namespace. Those provisions govern access to .avax; they do not make unsupported self-identification or trademark ownership alone a basis for general membership in the Avalanche community.

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

Q138Where is the community located?

Where is the community located?

The community is global and online, without a single geographic center. Members participate across N. America, L. America, Europe, Asia-Pacific, Africa, and the Middle East through network activity, campaigns, programs, events, and regional communities.

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

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

194M cumulative unique C-Chain addresses; 921K average daily; 189M active addresses across Avalanche L1s in Q2 2026; 610 Primary Network validators and 600 validators across Avalanche L1s (30 July 2026). Addresses are non-unique proxies; segments overlap.

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

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

Avalanche Foundation’s ecosystem-wide remit spans the full community estimated in Q139, though it keeps no membership roll. Ava Labs serves technical participants network-wide; Team1 and ecosystem organizations administer only their own members or users

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

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

Yes. During the two years preceding submission, Avalanche Foundation, Ava Labs, Team1, technical contributors, and independent ecosystem organizations maintained recurring, publicly documented engagement across the Avalanche community. The evidence reflects established programs and channels rather than outreach created for this application.

OFFERING SUPPORT. Avalanche Foundation maintained multiple funding paths for different community needs, including Retro9000 for Avalanche L1s, C-Chain applications, and infrastructure tooling; InfraBUIDL() and InfraBUIDL(AI); academic research grants of up to $50,000; Team1 Mini Grants; and a security bug-bounty program offering up to $100,000. Codebase Season 2 ran in fall 2024 with 15 cohort members and a $400,000 prize pool; subsequent cohorts continued with non-dilutive stipends, technical guidance, mentorship, workshops, and investor access. The six-week Innovation House residency in London in April-May 2025 provided selected teams with travel, accommodation, workspace, mentorship, workshops, and continuing ecosystem support.

SHARING INFORMATION. Ava Labs and Avalanche Foundation regularly publish network releases, grant criteria and results, technical documentation, educational courses, security guidance, ecosystem updates, event materials, and program opportunities. The Avalanche Builder Hub consolidates documentation, APIs, academy courses, hackathons, grants, network metrics, and validator resources. Public repositories, the ACP tracker, GitHub Discussions, the Avalanche Forum, developer calls, and Team1 channels provide continuing paths for builders, validators, users, and regional participants to receive information and contribute.

RESPONDING TO SPECIFIC COMMUNITY NEEDS. The Avalanche Community Proposal framework permits anyone to propose a network improvement, requires public discussion, and uses documented consensus-building before activation. During the relevant period, the Etna upgrade implemented ACP-77 and related proposals to reduce barriers to launching and validating sovereign Avalanche L1s, improve interoperability, and reduce C-Chain fees. The Octane upgrade, activated on Mainnet in April 2025, implemented ACP-176, allowing validators to adjust gas targets and improving fee efficiency and scalability. Retro9000 uses public submissions, project pages, leaderboards, and advisory community voting, while later rounds introduced revised verification and reward mechanics. The Foundation also opened research funding addressing network economics and validator-incentive design. These mechanisms identify defined technical, economic, and builder needs and support documented responses.

FOSTERING AND STRENGTHENING RELATIONSHIPS. Avalanche Summit London convened the community from May 20-22, 2025, followed by a three-day, $50,000 builder hackathon with workshops, team formation, mentors, judges, and ecosystem partners. Innovation House connected resident teams with one another and with mentors before the Summit. Recurring Codebase cohorts, pitch days, hackathons, developer education, Team1 events, regional programming, and the reopening of Team1 applications in May 2026 sustained relationships beyond individual events. Team1 expressly operates as a global community program using education, events, content, and direct support for builders and newcomers. Independent protocols and infrastructure organizations supplement these efforts through integrations, governance, documentation, user support, and community channels for their respective segments.

Together, these continuing practices engage developers, validators, L1 operators, infrastructure providers, researchers, founders, DeFi and gaming participants, enterprises, regional groups, and users across the community.

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

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

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

Avax Naming Limited’s role in the engagement described in Q141 is specific and complementary. It is the entity designated and endorsed by Avalanche Foundation to carry the community’s Internet-naming initiative through the ICANN process and, if approved, establish and operate .avax as an enduring DNS resource for the ecosystem those engagement efforts have built.

Within the activities described in Q141, Avax Naming’s contribution has been consultative and preparatory. It engaged with Avalanche Foundation, Ava Labs, and organizations serving important ecosystem segments to define the initiative, understand community naming and identity needs, distinguish the proposed DNS namespace from existing on-chain naming systems, and develop the community-based registration framework proposed in Q151-Q153. It also assembled the specialized registry, ICANN, domain-industry, and web3-native capabilities required to translate those needs into an operable TLD.

Avalanche Foundation endorsed Avax Naming for this role following the review described in Q135. The Foundation considered the ICANN opportunity, Avax Naming’s proposed structure, the experience available to the applicant, its proposed registry-services infrastructure, its community-based registration framework, and its ability to serve both conventional DNS users and Avalanche-native participants. Its written endorsement records the Foundation’s determination that Avax Naming is the appropriate applicant and ICANN operating partner for .avax.

The consultation and resulting community awareness are further evidenced by written support from Ava Labs and from organizations serving significant functional segments: BENQI, The Arena, Avant Protocol, LFJ, and Pangolin. These organizations identify their respective relationships with Avalanche, recognize the community benefit of an ICANN-administered .avax namespace, support the Foundation’s endorsement, and look to Avax Naming to pursue and operate the TLD. Their participation provided technical, application, DeFi, liquidity, and user perspectives relevant to the proposed namespace.

The broader engagement practices in Q141—including grants, Retro9000, Codebase, Innovation House, Team1 programs, technical documentation, ACP discussions, network upgrades, hackathons, and global events—are conducted by Avalanche Foundation, Ava Labs, Team1, contributors, validators, and independent ecosystem organizations in their established roles. Avax Naming’s role complements that activity by creating the dedicated Internet-identity resource through which community participants may identify and present themselves in the global DNS.

Avax Naming’s continuing contribution is to convert the community-supported initiative into enforceable Community Registration Policies, qualified registry infrastructure, accredited-registrar distribution, published registration and verification procedures, DNS security and abuse controls, rights-protection mechanisms, data escrow, operational continuity, and continuing ICANN compliance. It will coordinate the contracted registry and web3-native service providers supporting those functions while independently administering the registry.

Avax Naming remains solely accountable for the application and, if delegated, for registry governance, policies, operations, and compliance with the Registry Agreement. Avalanche Foundation, Ava Labs, and the supporting organizations contribute community knowledge, endorsement, and anticipated participation without acquiring ownership of the applicant or authority to direct registry decisions.

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

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

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

Yes. Members recognize both the Avalanche community as a whole and its functional and regional segments. Awareness is demonstrated through shared technical and governance processes, builder programs, cross-segment events, communication channels, on-chain records, and organizations that identify their roles within the wider ecosystem.

The Avalanche Community Proposal process provides direct evidence. ACP authors publicly propose changes; developers review specifications and implementations; validators consider operational effects; L1 teams assess infrastructure consequences; and the wider community discusses proposals through GitHub and public channels. Activation ultimately depends on participants adopting compatible network software. The Etna and Octane upgrades therefore record interaction among proposal authors, client developers, validators, L1 operators, application builders, and users around shared network needs.

Retro9000 makes community activity visible across segments. Developers publish project pages for L1s, C-Chain applications, and infrastructure tooling; other participants review them through public leaderboards and advisory community voting; and the Foundation publishes program rules, verification mechanics, funding rounds, and results.

Builder programs create sustained interpersonal awareness. Codebase cohorts bring founders together with engineers, mentors, investors, infrastructure providers, and ecosystem applications through onboarding, workshops, development sprints, pitch days, and alumni activity. Innovation House placed selected teams in a shared six-week residency before Avalanche Summit London, combining peer collaboration with mentorship, workshops, and ecosystem integration. Team1 connects builders, developers, creatives, gamers, educators, and regional participants through membership, grants, events, content, and direct support.

Avalanche Summit London and its associated hackathon provide additional records involving diverse groups. The Summit convened developers, validators, founders, enterprises, institutional participants, applications, infrastructure providers, and users under the Avalanche identity. The three-day hackathon included team formation, workshops, mentors, judges, and partners, with projects spanning Avalanche L1s, cross-chain applications, AI, DeFi, real-world assets, gaming, social applications, institutional solutions, and developer tooling.

Public records allow participants to identify one another and understand the community’s structure. The Avalanche Explorer identifies L1s, blockchains, validators, and network activity; repositories and ACP records identify authors, maintainers, and contributors; grant and program materials identify funded projects and cohort members; and the Forum, GitHub Discussions, Builder Hub, Team1 channels, and application communities provide persistent venues for interaction.

The endorsements accompanying this application provide further cross-segment evidence. Avalanche Foundation and Ava Labs identify the broader community and their respective ecosystem and technical roles. BENQI, Avant Protocol, LFJ, Pangolin, and The Arena—representing lending and liquid staking, stablecoin and yield, trading and liquidity, community-governed DeFi, and SocialFi and creator activity—identify the same broader Avalanche community and their respective places within it.

No membership survey was commissioned for this application, and no survey result is relied upon. As an open community without a universal membership roll, the more probative evidence consists of public records of actual interaction: proposal discussion and adoption, project publication and community voting, mixed-segment cohorts and events, on-chain operations, and separately executed institutional endorsements. Together, these practices demonstrate awareness of the common Avalanche identity and of the distinct groups participating within it.

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

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

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

Yes. Before submission, the Avalanche community’s principal ecosystem institution, principal technical contributor, and organizations serving major functional segments were aware of both Avax Naming Limited and its intention to apply for .avax as a community gTLD. That awareness is documented through separate institutional letters.

Avalanche Foundation evaluated the ICANN new gTLD opportunity and the role an Avalanche-aligned DNS namespace could play in the ecosystem’s long-term development. It reviewed Avax Naming’s proposed structure, the ICANN and domain-industry experience available to the applicant, its proposed registry-services infrastructure, its community-based registration framework, and its ability to serve conventional DNS users and Avalanche-native participants. Following internal review and leadership discussion, the Foundation’s Board approved the endorsement on June 26, 2026. Its signed letter identifies Avax Naming as the appropriate applicant and ICANN operating partner, supports operation of .avax for the community, and urges ICANN to approve the application.

Ava Labs separately demonstrates informed awareness from its role as a significant technical and product contributor. Its written letter states that Ava Labs understands Avalanche Foundation endorsed Avax Naming as the applicant and proposed ICANN operating partner and that Ava Labs supports that endorsement. It identifies the proposed namespace as an ICANN-administered community TLD, describes the intended users and community benefits, and supports technically capable, ICANN-compliant operation by Avax Naming.

Awareness extends across important functional segments. Signed letters from The Arena, Avant Protocol, LFJ, Pangolin, and BENQI identify Avax Naming by name, support its community application, recognize the Foundation’s endorsement, and describe the expected benefit to their users and participants. Together they provide evidence from stablecoin and money-market infrastructure, decentralized trading and liquidity, community governance, lending, liquid staking, validators, and economically active users. BENQI’s letter provides particularly direct evidence of the awareness process. It states that Avax Naming supplied application materials, including the proposed registrant-eligibility and name-selection policies; that BENQI reviewed those materials; and that its decision to support the application was taken through its internal governance. BENQI therefore understood both the identity of the applicant and the community-restricted character of the proposed TLD before executing its letter.

The awareness reflected in these letters is informed rather than nominal. The signers address what is proposed: an application by Avax Naming to establish an ICANN-administered DNS namespace for the Avalanche community, subject to the Community Registration Policies in Q151-Q153. They identify anticipated benefits for their participants and look to Avax Naming to pursue and operate the registry. Their endorsements provide community knowledge and support without conferring ownership of the applicant or authority over registry decisions.

Institutional evidence is appropriate for this open, global community. As described in Q136 and Q137, Avalanche has no universal membership roll or general assembly through which a community-wide notice or collective vote could be issued. Avalanche Foundation, Ava Labs, and established organizations serving identifiable segments are the mechanisms through which awareness and support can be documented. Each letter speaks from the signer’s own participation and constituency; collectively, they demonstrate awareness across SocialFi, creator, stewardship, technical development, DeFi, liquidity, trading, staking, validation, governance, and user segments.

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

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

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.

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

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

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

Yes. Individuals and organizations outside the Avalanche community recognize it as an established global technology community. During the two years preceding submission, governments, international sports bodies, financial institutions, asset managers, exchanges, researchers, regulators, and media identified Avalanche by name and discussed its network, developers, validators, applications, and ecosystem.

MEDIA AND PUBLIC INFORMATION. Independent financial and technology media regularly report on Avalanche’s technology, applications, network activity, institutional deployments, and AVAX. Public SEC and exchange materials for products sponsored by VanEck, Grayscale, and Bitwise separately identify the Avalanche Network and its native asset. Major exchanges and market-data services also maintain dedicated Avalanche pages, demonstrating routine recognition outside community-controlled channels.

DISCUSSION IN PUBLIC FORA. Avalanche has been discussed in SEC and Federal Register proceedings concerning exchange-listed products, Wyoming Stable Token Commission meetings and legislative materials, FIFA public announcements, financial-industry publications, and international conferences. These fora are administered by governments, regulators, sports institutions, financial-market participants, and independent publishers rather than by Avalanche Foundation.

PARTNERSHIPS AND COLLABORATIONS. In November 2024, BlackRock expanded its BUIDL tokenized fund through Securitize to include an Avalanche share class. In 2025, FIFA launched its own blockchain built on Avalanche technology for FIFA Collect and broader fan experiences; FIFA reported more than 85,000 addresses shortly after launch. Wyoming deployed its state-issued Frontier Stable Token across seven blockchains, including Avalanche, and announced distribution through a Visa-integrated card platform operating on Avalanche. FIS and Intain launched a Digital Liquidity Gateway using an Avalanche L1 to support loan trading and securitization by community and regional banks. These decisions reflect technical and institutional evaluation by substantial organizations outside the community.

PRIOR ORGANIZATION. The evidence submitted in Q145 shows that Avalanche Mainnet, Avalanche Foundation, Ava Labs, the validator set, open-source repositories, developer channels, and ecosystem applications were established years before the application period. Mainnet has operated publicly since September 2020. External recognition therefore concerns an established community, not a group assembled for this application.

CONTRIBUTIONS TO A LARGER POPULATION. Avalanche technology is used beyond blockchain-native participants. FIFA uses it to provide digital collectibles and new experiences to a worldwide fan base. Wyoming’s stable-token work reaches individuals, businesses, and public finance. The FIS/Intain platform is intended to improve liquidity access for regional and community banks, while institutional tokenization projects support regulated financial markets. AvalancheGo, developer tooling, research, and the public Avalanche Community Proposal process are openly available for use, study, and improvement.

Together, independent reporting, regulatory materials, public-sector activity, institutional deployments, and third-party use demonstrate clear awareness of the Avalanche community and its members beyond the community itself.

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

Q147Are the pursuits of the identified community enduring and sustainable?

Are the pursuits of the identified community enduring and sustainable?

Yes. The Avalanche community’s pursuits are enduring because they concern the continuing development, operation, security, and use of a public network and the independent applications and Layer 1 blockchains built upon it. They are not limited to a temporary campaign or product launch.

LONGEVITY. Avalanche Mainnet has operated publicly since September 2020. Independent validators have secured the network; developers have maintained open-source software; applications have served users; and Avalanche Foundation, Ava Labs, and ecosystem organizations have provided continuing stewardship, technical development, education, funding, and infrastructure. Support letters show that BENQI, LFJ, and Pangolin have served important Avalanche segments since 2021, while newer participants demonstrate continuing expansion.

RECURRING AND SCHEDULED ACTIVITIES. During the two years preceding submission, recurring programs included Retro9000 funding rounds, Codebase incubator seasons, Foundation and Team1 builder grants, research funding, security bug bounties, Innovation House residencies, developer education, and regional programming. Codebase records cohorts beginning in 2024 and continuing through multiple seasons, while Retro9000 reached its fifth C-Chain round in July 2026. Avalanche Summit London was held in May 2025, and Avalanche Summit New York was scheduled for September 2026. These cycles show an established practice of repeatedly funding, educating, convening, and supporting participants.

CONTINUING TECHNICAL DEVELOPMENT. Avalanche Community Proposals provide a standing public process through which participants propose and discuss network changes. Public repositories, releases, audits, validator signaling, and upgrade records document continuing work. Etna activated in December 2024, Granite in November 2025, and Helicon development continued in 2026. This demonstrates a community capable of maintaining security, responding to technical needs, and evolving the network.

ENDURING PURPOSE AND CULTURE. Public discussions address long-term network economics, validator incentives, scalability, security, interoperability, and adoption. Summits, builder houses, forums, regional programs, and application communities provide recurring places where participants form relationships and transmit knowledge. Public materials describe a global culture of builders, creators, and collaborators whose purpose extends beyond any one application.

SUSTAINABILITY. The community is diversified across protocol development, validation, custom L1s, DeFi, payments, institutional tokenization, gaming, consumer applications, infrastructure, research, and education. Deployments by FIFA, BlackRock and Securitize, Wyoming, FIS and Intain, and other institutions create uses beyond short-term digital-asset markets. Network fees, staking and validation, application activity, Foundation programs, and independent investment provide multiple forms of support rather than dependence on one organization or product.

The .avax initiative adds a durable Internet-identity function. Avalanche Foundation’s review and endorsement of Avax Naming, corroborated by Ava Labs and ecosystem organizations, demonstrates long-term stewardship of the community’s identity and a deliberate effort to secure its identifier in the DNS. If delegated, registration and renewal revenue, Identity Digital’s registry infrastructure, registrar distribution, and ICANN continuity requirements will provide a sustainable operating framework.

More than five years of Mainnet operation, recurring programs and gatherings, continuous technical governance, durable institutions, diversified activity, and scheduled future initiatives demonstrate that the community’s pursuits are enduring and sustainable.

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

Q148Does the string match the name of the identified community?

Does the string match the name of the identified community?

Yes. The identified community’s full name is the Avalanche community, and “AVAX” is its official and well-known short-form identifier.

AVAX is the established name and symbol of Avalanche’s native asset, which is used to pay network fees, secure the platform through staking, and support operations across the network. The same identifier appears in Avalanche’s principal public Internet address, avax.network, and throughout official technical documentation, wallets, explorers, exchanges, applications, market data, financial products, and institutional materials. Public references consistently pair the full and short forms as “Avalanche (AVAX).”

The association extends beyond the asset itself. Community participants use AVAX to identify Avalanche-aligned activity, products, services, and identity, including references to the “AVAX ecosystem,” “AVAX community,” applications operating “on AVAX,” and participants who build, validate, stake, transact, or provide services within that ecosystem. The string therefore identifies the technological and economic system around which the community described in Q132 is organized, not merely one product offered to that community.

The use predates and exists independently of this application. Avalanche Foundation, Ava Labs, and supporting ecosystem organizations—including BENQI, Avant, LFJ, and Pangolin—each recognize .avax as the natural or appropriate DNS identifier for the Avalanche community and describe its expected use by developers, validators, applications, enterprises, infrastructure providers, and users. Their independently executed letters confirm that the shorthand is understood consistently across stewardship, protocol development, DeFi, trading, liquidity, staking, and governance segments.

Historical use of .avax-formatted on-chain names supplies additional evidence that the community has adopted AVAX for identity-related purposes. Those identifiers are technically separate from DNS names and do not resolve through the ICANN root; their relevance here is the community’s prior choice of the same string.

Accordingly, .avax need not reproduce the community’s complete “Avalanche” name to match it. It is the community’s established, distinctive, and widely recognized alternative short-form name.

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

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

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

Yes. When encountered as the Internet identifier .avax, the general public would instinctively associate the string with the Avalanche network and community.

That association is reinforced at every principal point through which the public encounters Avalanche. The ecosystem’s official website is avax.network; AVAX is the official name and symbol of the network’s native asset; and exchanges, wallets, explorers, market-data services, financial institutions, media, and public regulatory materials consistently present the pairing “Avalanche (AVAX).” The exact string therefore functions publicly as a compact identifier for Avalanche, not as terminology created for this application. SEC materials relating to Avalanche investment products, for example, identify AVAX as the native token of the Avalanche Network, demonstrating recognition beyond community-controlled channels.

The string also represents the identified community rather than only the native asset. AVAX is integral to participation across the ecosystem: it is used for network fees, staking and network security, and other Avalanche operations. Developers, validators, L1 operators, applications, infrastructure providers, enterprises, and users therefore encounter the same identifier through their shared activity. Avalanche Foundation, Ava Labs, BENQI, Avant, LFJ, and Pangolin independently recognize .avax as the proposed DNS namespace for those participant groups.

Historical community use of .avax-formatted on-chain identifiers further corroborates the identity association, although those identifiers are technically separate from DNS and do not resolve through the ICANN root.

“AVAX” is not an ordinary English word, geographic designation, or generic term describing a class of goods, services, organizations, or communities. Its significant and commonly recognized meaning in the Internet, technology, and digital-asset contexts is as the distinctive identifier associated with Avalanche.

In the TLD context, the clear organized-community meaning of .avax is therefore the Avalanche community. The use of avax.network as the ecosystem’s established public address, the widespread Avalanche/AVAX pairing, the function of AVAX within the network, and cross-segment support for this application together make that association clear.

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

Q150Are 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?

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

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

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

Registry Operator shall restrict registrant eligibility for second-level domain names in the .avax TLD to persons or entities that demonstrate participation or affiliation with the Avalanche ecosystem at the time of initial registration or an intent to participate within 90 days after registration. An eligible registrant shall satisfy at least one of the following criteria pursuant to the Verification Methodology described below:

(a) Operates and controls an Avalanche wallet address on Avalanche Mainnet; (b) Operates an active validator of the Avalanche Primary Network or an Avalanche L1; (c) Has deployed one or more smart contracts, applications, or Avalanche L1s to Avalanche Mainnet; (d) Holds one or more .avax on-chain names issued through documented Avalanche naming infrastructure, as recognized under the Verification Methodology; (e) Has received an Avalanche Foundation grant within the 36 months preceding registration; (f) Is a verified participant in an Avalanche Foundation-recognized ecosystem program included on the Programs List described below; (g) Promotes the Avalanche ecosystem; (h) Can provide other objectively verifiable evidence of participation in the Avalanche ecosystem upon request; or (i) Intends to satisfy one or more of criteria (a)-(h) within 90 days after registration.

Registry Operator shall maintain and publish on its website a sample list of programs eligible under criterion (f) (the “Programs List”). Registry Operator shall independently administer the Programs List and may add, remove, or recognize substantially equivalent programs in accordance with the published Verification Methodology.

Registry Operator shall publish the Verification Methodology on its website no later than commencement of the first registration period. The Verification Methodology shall identify the information or records used to evaluate each criterion and the party responsible for verification. Records or confirmation supplied by Avalanche Foundation, Ava Labs, a program administrator, or any other person or entity shall be evidentiary only and shall not confer authority to direct, approve, veto, or otherwise control a determination or operation of the .avax TLD.

Registry Operator shall permit a trademark holder to register a second-level domain name that is identical to its trademark at any time, even if the holder does not otherwise satisfy criteria (a)-(i), as part of Registry Operator’s efforts to create a safe and reputable namespace.

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

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

Registry Operator shall not permit registration of a second-level domain name in the .avax TLD that is identical, without regard to letter case, to a label included on the Reserved Names List unless Registry Operator provides written authorization.

Registry Operator shall maintain and publish on its registrar portal a Reserved Names List containing second-level labels that may correspond to documented names, trademarks, or commonly used identifiers of persons or entities with a documented connection to the Avalanche ecosystem.

Registry Operator shall independently establish and administer the Reserved Names List under this policy.

Registry Operator shall create the initial Reserved Names List no later than commencement of the first registration period for the TLD.

An addition to the Reserved Names List shall apply prospectively and shall not affect a Registered Name created before the addition unless required by applicable ICANN policy, an applicable dispute-resolution proceeding, court order, or agreement with the Registered Name Holder.

Q153.1State 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.

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.

Registry Operator shall maintain a process through which a registrant or prospective registrant may request review of an adverse determination made under the .avax registrant eligibility or name-selection policies.

Registry Operator shall permit a request for review to be submitted within seven (7) days after notice of the adverse determination and shall provide the requesting party with a written decision within thirty (30) days after receiving the request.

Registry Operator shall publish the review process on its website no later than commencement of General Availability.

Registry Operator shall independently establish, following appropriate consultation with Avalanche community participants, a Reserved Names List and policy for community-priority names that may be allocated to qualified community members. Registry Operator shall publish the applicable qualifications, allocation method, and priority period on its website before the period begins.

Registry Operator shall hold one or more Limited Registration Periods before General Availability, with eligibility restricted to qualified Avalanche community members. Registry Operator shall publish the applicable qualifications and launch dates on its website before each period begins.

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

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

The proposed Community Registration Policies contain limited temporal and scope qualifications, each tailored to the purpose of the applicable policy.

Q151 evaluates community eligibility at initial registration rather than at each renewal. This permits a Registered Name to remain a stable Internet identifier after a registrant establishes a qualifying connection to the community, even if the particular form of participation later changes. The 90-day intent pathway allows a good-faith new participant to obtain an identity for an activity it is preparing to undertake within the Avalanche ecosystem. The 36-month period for grant-based eligibility ensures that a grant used as evidence reflects a reasonably current community connection. The trademark-holder exception is limited to registration of the holder’s trademark and supports a safe and reputable namespace without creating a broader exception to community eligibility.

Under Q152, an addition to the Reserved Names List applies prospectively. This protects the reasonable expectations of an existing Registered Name Holder and avoids retroactively impairing a registration that was permitted when created. The written-authorization exception permits Registry Operator to authorize an otherwise reserved registration when appropriate.

Under Q153, the seven-day period for requesting review promotes prompt resolution of adverse determinations, while the 30-day decision period provides sufficient time to evaluate the request and issue a reasoned written decision. Community-priority allocation periods and Limited Registration Periods are time-limited because they serve launch and priority-allocation purposes before the ordinary registration process applies.

Except for these expressly identified temporal and scope qualifications, the proposed Community Registration Policies are not time-limited and are intended to apply throughout the term of the Registry Agreement.

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

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

CRITERION 4: DUPLICATION AND CONTRARY REQUIREMENTS. The proposed Community Registration Policies do not duplicate, and are not contrary to, requirements under applicable law, the Base Registry Agreement, ICANN Consensus Policies, or ICANN Temporary Policies.

Q151 establishes a .avax-specific eligibility framework based on participation or affiliation with the Avalanche ecosystem, evidence of community participation, promotion of the ecosystem, or an intent to participate within 90 days. No applicable law or ICANN requirement establishes or administers these community-specific eligibility conditions. The limited trademark-holder exception is an eligibility provision and does not replace or duplicate the Trademark Clearinghouse, Sunrise, Trademark Claims, UDRP, URS, or any other applicable rights-protection mechanism.

Q152 establishes a .avax-specific Reserved Names List and rules governing the availability and prospective reservation of community-related second-level labels. Applicable ICANN requirements and rights-protection mechanisms do not require Registry Operator proactively to identify and reserve documented names, trademarks, or identifiers associated with the Avalanche ecosystem. The policy supplements those requirements without replacing or limiting them.

Q153 establishes an internal review procedure for determinations made under the .avax eligibility and name-selection policies, together with community-priority allocation and Limited Registration Period processes. Applicable law and ICANN requirements do not provide an equivalent review or priority-allocation process for the Avalanche community. These processes operate subject to, and do not limit, any rights or remedies available under applicable law, the Registry Agreement, or ICANN policies.

Nothing in Q151-Q153 authorizes conduct prohibited by, excuses compliance with, or alters any obligation imposed by applicable law, the Registry Agreement, an ICANN Consensus Policy, or an ICANN Temporary Policy.

CRITERION 5: ICANN BYLAWS COMPATIBILITY. The proposed policies concern who may register a .avax domain name, when registration may occur, which second-level labels may be available, and how Registry Operator determinations may be reviewed. These are operational and procedural conditions directly concerning the allocation and administration of unique identifiers within the .avax TLD.

The policies do not restrict or require evaluation of website content, communications, applications, products, or services. References to Avalanche Mainnet, Avalanche L1s, and on-chain names are used solely to identify evidence of community participation. The policies do not require DNS resolution through Avalanche, create interoperability with an on-chain identifier, or establish an alternative naming root.

ADDITIONAL REGISTRY SERVICE CONSIDERATIONS. Registry Operator is coordinating implementation with its selected Registry Service Provider. The policies can be implemented through ordinary registration, reservation, verification, and launch workflows. Eligibility may be evaluated using public Avalanche Mainnet records, cryptographic proof, or documentary evidence without altering DNS, DNSSEC, EPP, RDDS, or data-escrow services and without providing an on-chain resolution service. On the proposed implementation, the policies do not require an additional Registry Service. If ICANN or the selected Registry Service Provider determines that a particular implementation would constitute an additional Registry Service, Registry Operator shall complete the required RSP Program evaluation and obtain ICANN approval before offering that service.

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

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

Avax Naming Limited has direct written support from Avalanche Foundation, the principal ecosystem-wide organizing body identified in Q136, together with corroborating support from Ava Labs and independent organizations serving important functional segments of the Avalanche community.

Avalanche Foundation evaluated the ICANN new gTLD opportunity and the role a community-based .avax DNS namespace could play in the ecosystem’s long-term development. It reviewed Avax Naming’s proposed structure, the ICANN and domain-industry experience supporting the applicant, its intended registry infrastructure, its proposed Community Registration Policies, and the intended relationship between conventional DNS and Avalanche-native uses. Following internal review, the Foundation approved its endorsement on or about June 23, 2026. Its signed letter determines that Avax Naming is the appropriate applicant and ICANN operating partner for .avax, supports operation of the TLD for the Avalanche community, and urges ICANN to approve the application.

That endorsement is the principal evidence of community support. As described in Q136, Avalanche Foundation has an ecosystem-wide remit across developers, validators, L1 operators, applications, infrastructure providers, institutions, creators, and users. The Avalanche community has no universal membership association or general assembly empowered to express a collective position on a TLD application. The Foundation’s documented institutional determination is therefore the appropriate community-wide expression of support.

Ava Labs, the original developer and a principal technical contributor to Avalanche, separately supports the application. Its letter recognizes AVAX as the community’s established identifier, explains the value of an ICANN-administered namespace to Avalanche developers, applications, validators, enterprises, and users, supports the Foundation’s endorsement of Avax Naming, and looks to Avax Naming to pursue and operate the registry. Ava Labs’ support provides technical and ecosystem corroboration without displacing the Foundation’s organizing role.

Support also extends across independent functional segments. BENQI supports the application from its longstanding roles in lending, liquid staking, and validator participation. LFJ supports it as an Avalanche-native trading and liquidity platform. Pangolin supports it as a community-driven decentralized exchange with an active governance community. Avant separately supports the initiative from its role in stablecoin, liquidity, and DeFi infrastructure. The Arena supports the application from the SocialFi and creator segment of the Avalanche ecosystem; its application serves more than 22ok monthly users across the ecosystem and supports .avax as a trusted DNS identity layer for creators, collectors, digital-asset users, applications, and other participants. Their letters identify Avax Naming by name, recognize .avax as the community’s natural DNS identifier, and describe expected benefits for the participant groups they serve.

These organizations do not acquire ownership or operational control over Avax Naming by endorsing the application. Avax Naming independently retains responsibility for the application and, if delegated, for registry governance, policies, operations, technical providers, and compliance with the Registry Agreement. The endorsements establish community support and anticipated participation while preserving the independent accountability required of the Registry Operator.

Accordingly, Avax Naming’s support comes from the community’s principal ecosystem-wide organizing body, its principal technical contributor, and established organizations operating across major community functions. The written endorsements submitted with this response demonstrate both the institutional basis and the breadth of support for Avax Naming to pursue and operate .avax on behalf of the Avalanche community.

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

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

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

No. As of the date of submission, Avax Naming Limited is not aware of any opposition to the applying entity, this application, or the applied-for .avax string. No person, organization, or Avax community entity has communicated opposition to Avax Naming Limited. Accordingly, there is no known opposition to assess or address.

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

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

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

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