Application Details
Last published on: 7 October 2026 at 15:34 UTC
Application Responses
Section: Applying Entity Information
This question set collects information regarding the legal entity that would enter into a Registry Agreement with ICANN upon successful completion of all relevant application processes. The information collected is intended to be used for background screening.
Provide the full legal name of the applying entity as it appears on the official registration documents. Do not use abbreviations.
Avax Naming Limited
Provide the long form (no acronyms) of the legal entity form/business structure of the applying entity as it appears on the official registration documents. If the original script of the legal entity form/business structure is not English, ONLY provide its official English translation. No additional information should be provided as this will be used for the automatic population of the Registry Agreement.
A company limited by shares
The jurisdiction indicates the location in which the business of the applying entity is registered for legal and financial purposes. This is either 1) a country name, or a 2) state/territory name, depending on where the applying entity is registered. No additional information should be provided as this will be used for the automatic population of the Base Registry Agreement. Examples include "Delaware", "Germany", etc.
British Virgin Islands
Provide the website URL of the applying entity, if available.
https://redrock.foundation/
1. Choose Yes or No. 2. Use the definition of Affiliate from the Base Registry Agreement (see https://www.icann.org/en/registry-agreements/base-agreement).
true
1. Specify if the applying entity is an existing registry operator, ICANN accredited registrar, and/or an Affiliate of a registry operator and/or registrar. 2. If the applying entity is an Affiliate, provide the details of such Affiliate relationship, including the name of the affiliated registry operator and/or registrar. 3. If the applying entity is an ICANN accredited registrar, specify the registrar ID number.
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.
Choose Yes or No.
false
1
Provide the primary business phone number without including the country code.
6024561408
Provide the primary business email address of the applying entity.
admin@redrock.foundation
Enter the street address (no PO Box).
Commerce House
Wickhams Cay 1
Enter the city, village, municipality, etc.
Road Town
Enter the state, province, department, territory, prefecture, oblast, etc., if applicable.
Tortola
1. Enter the postal code, if applicable. 2. If a postal code does not exist, type “Not Applicable”.
VG1110
VG
If applicable, provide the full legal name as it appears on the official registration documents of the Direct Parent Company of the applying entity. Do not use abbreviations.
Red Rock (Cayman) Foundation
Provide the long form (no acronyms) of the legal entity form/business structure of the Direct Parent Company as it appears on the official registration documents. If the original script of the legal entity form/business structure is not English, ONLY provide its official English translation.
Exempted Foundation Company Limited by Guarantee
The jurisdiction indicates the location in which the business of the Direct Parent Company is registered for legal and financial purposes. This is either 1) a country name, or a 2) state/territory name, depending on where the Direct Parent Company is registered. Examples include "Delaware", "Germany", etc.
Cayman Islands
Section: Applying Entity Background and Organization
This question set collects information related to the individuals who will have access to TAMS, manage the application, and receive inquiries.
Derek O'Toole
Derek O'Toole
Red Rock (Cayman) Foundation
Red Rock (Cayman) Foundation
Section: Self-Certification
Provide a single document for Self-Certification question Q4.2-1. The document must include only the SC4.2-1.1, SC4.2-1.2, or SC4.2-1.3 statements. Do not modify any of the Self-Certification statements.
1. Provide a single document for Self-Certification question Q4.2-1. 2. The document must include only the SC4.2-1.1 through SC4.2-1.3 statements. 3. Do not modify any of the Self-Certification statements. 4. If the applying entity cannot Self-Certify the SC4.2-1.1 through SC4.2-1.3 statements, provide a document that explains why the applying entity cannot Self-Certify the SC4.2-1.1 through SC4.2-1.3 statements.
Section: Security Policy and Planning
Provide a single document for Self-Certification question AGB Q220, Q5.1-1. The document must include only the SC5.1-1.1 through SC5.1-1.3 statements. Do not modify any of the Self-Certification statements. If the applicant cannot Self-Certify SC5.1-1.1 through SC5.1-1.3 statements, provide a document that explains why the entity cannot Self-Certify the SC5.1-1.1 through SC5.1-1.3 statements.
1. Provide a single document for Self-Certification question Q5.1-1. 2. The document must include only the SC5.1-1.1 through SC5.1-1.3 statements. 3. Do not modify any of the Self-Certification statements. 4. If the applying entity cannot Self-Certify the SC5.1-1.1 through SC5.1-1.3 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.1-1.1 through SC5.1.1-3 statements.
Section: DNS Abuse
Provide a single document for Self-Certification question AGB Q221, Q5.2-1. The document must include only the SC5.2-1.1 through SC5.2-1.7 statements. Do not modify any of the Self-Certification statements. If the applicant cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements.
1. Provide a single document for Self-Certification question Q5.2-1. 2. The document must include only the SC5.2-1.1 through SC5.2-1.7 statements. 3. Do not modify any of the Self-Certification statements. 4. If the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements.
Section: Primary String
This question set collects basic information regarding the string that is being applied for (for example, a-label, meaning, script). If the applying entity opts to designate a replacement string, it must answer the same set of questions for the replacement string from the AGB Question Set 5 on.
avax
Provide the meaning, or restatement of the string in English, that is, a description of the literal meaning of the string in the opinion of the applying entity. If there is no literal meaning in English (for example, a brand name or a proper noun without a translation) simply state "No English Translation"
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.
Provide a representation of the string according to the International Phonetic Alphabet.
/ˈæv.æks/ (“AV-aks”)
Confirm the statement using a checkbox.
true
1. Describe the mission and purpose of the applied-for gTLD, including the intended registrants and users, and the related activities that have been or will be carried out to achieve this purpose. 1a. If applying for a variant of an existing gTLD, please also describe the mission and purpose of the existing gTLD, including the intended registrants and users, and the related activities that have been or will be carried out to achieve this purpose. 2. Explain how this purpose is sustainable over time.
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.
Section: Community
This question set collects information specific to Community gTLDs. However, question 133 (Mission & Purpose) must be answered by all applying entities.
General
Yes
1. Provide the name of the community that the applying entity is committing to serve. 2. Describe the distinct aspects of the community.
The 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.
Enter a category that best describes your community. Some examples of community categories could include, but are not limited to: activity-based and volunteer groups, online or social media groups, religious or political groups, diasporic communities, linguistic communities, celebrity or sports team supporters.
The 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.
Organization
Describe and provide evidence of the relationship between the applying entity and the identified 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.
Describe and provide evidence related to the community organization, any relevant organizing bodies, and any relevant leaders within 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.
1. Describe any formal membership process, if there is one. 2. If there is no formal membership process, provide evidence related to how an individual can join the identified community (i.e., “self-identify” as a community member).
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.
Provide the primary location of the community.
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.
1. Provide the estimated size of the community. The size should be in number format (e.g., “1,000,000 members”). 2. If the community is divided by group, region, sector, etc., this should include estimated size for each group.
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.
Provide the estimated size of the community that is administered or represented by each relevant organizing body in the identified community.
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
Engagement
1. Provide evidence of any documented practices of community efforts to date 2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission: a) Offering support; b) Sharing information; c) Responding to specific community needs; d) Fostering and strengthening relationships within the community.
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.
1. Describe whether the applying entity has a role in any of the activities listed in Question 141. 2. If the applying entity does play a role, provide evidence of the applying entity’s role. If the applying entity does not play a role, describe why this is the case.
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.
Awareness
1. Provide evidence that demonstrates that community members are aware of the identified community and the different member groups or segments within the identified community. 2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission: a) Surveys conducted; b) Records of activities involving a diversity of community groups, segments, or members.
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.
1. Provide evidence of community members’ awareness of the applying entity and its intent to apply for a community gTLD. 2. If there is no such evidence, explain why not.
Yes. 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.
Established Presence
Provide evidence of the established presence of the community prior to the opening of the application submission period.
1. Provide evidence that demonstrates that individuals and groups outside of the community show an awareness of the identified community. 2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission: a) Media or other public information regarding the community and its activities or members; b) Discussion of the community in various fora, whether online or in person; c) Evidence of partnerships or collaborations with groups outside of the identified community; d) Evidence of the chartering or organization of the community prior to the opening of the application submission window; e) Evidence of contributions (for example, cultural or scientific) to a larger society or population;
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.
Longevity
1. Provide evidence of the longevity of the community. 2. The applying entity should provide documentation of the following practices which should have occurred within the two years leading up to application submission: a) Evidence of recurring or scheduled activities that demonstrate continuity over time; b) Documented records of past activities that demonstrate a long-standing tradition or practice; c) Records of discussions emphasizing the community’s enduring presence or its cultural significance.
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.
Nexus
Explain how the applied-for string matches the name of the community or is a well-known alternative name (whether long or short form) of the community.
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.
1. Explain how the applied-for string clearly relates to or represents the community 2. Explain whether the applied-for string has any other significant meaning beyond identifying the community or community members described in the application. The applying entity may wish to provide pertinent information regarding any particular geography, region, or themes that may be alluded to by the string, of which the community may or may not be a part.
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.
Community Registration Policy
Select from Radio Buttons - Yes/No. Notes: 1. Community Registration Policies are conditions that community gTLD registry operators impose upon registrants within their gTLDs. 2. If you select “Yes” to this question, the applying entity is required to pay the conditional Registry Commitments Evaluation fee, and Community Registration Policies that are approved by ICANN will be scored in the CPE (if the applying entity elects to participate) and included in Specification 12 of the applicable Base RA. 3. If you select “No,” then the application cannot proceed as a community application.
Yes
1. Draft the Community Registration Policy as proposed contract language. Policies that are approved by ICANN will be included in Specification 12 of the applicable Registry Agreement and will be subject to enforcement by ICANN Contractual Compliance. See Appendix 4 Base Registry Agreement, Specification 12 for drafting approach. Consider the usage of defined terms and the definitions of such terms in the 2026 Round Base RA. 2. Enter a single proposed Community Registration Policy with respect to registrant eligibility in each response field. Up to 10 Community Registration Policies can be submitted. 3. Follow this format to propose what the Registry Operator must do and/or must not do: a) “Registry Operator shall___”; and/or b) “Registry Operator shall not___”. 4. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars ,: a) "Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or b) "Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”. 5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements: a) "Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring ___"; and/or b) "Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting ___". 6. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example: a) Registry Operator shall develop and implement a registration eligibility policy and publish this policy on its website no later than the date on which the TLD is delegated in the DNS. b) Registry Operator shall review the registration policy described in (a) at least once per year, and publish the results of such review (including any updates to the registration policy) on its website within thirty (30) days following the anniversary of the Effective Date. 7. If the Community Registration Policy is limited in time, duration, scope, or any other factors, specify the applicable limitations. For example, if a registrant eligibility restriction is time-limited, the applying entity must state if the restriction will apply for the lifetime of the gTLD, only during a specified period, or for some other defined period (such as, Registry Operator shall, for a period of x days from the Effective Date, ___). 8. See Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria for evaluation criteria that ICANN will apply for evaluating each proposed Community Registration Policy.
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.
1. Draft the Community Registration Policy as proposed contract language. Policies that are approved by ICANN will be included in Specification 12 of the applicable Base Registry Agreement and will be subject to enforcement by ICANN Contractual Compliance. See Appendix 4 Base Registry Agreement, Specification 12 for drafting approach. Consider the usage of defined terms and the definitions of such terms in the 2026 Round Base RA. 2. Enter a single proposed Community Registration Policy with respect to name selection criteria or rules for the applied-for string in each response field. Up to 10 Community Registration Policies can be submitted. 3. These criteria or rules should align with the community objectives of the applied-for gTLD string. 4. Follow this format to propose what the Registry Operator must do and/or must not do: a) “Registry Operator shall___”; and/or b) “Registry Operator shall not___”. 5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars: a) ""Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or b) ""Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”. 6. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements: a) ""Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring___""; and/or b) ""Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting ___"". 7. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example: a) Registry Operator shall develop and implement a name selection rule and publish it on its website no later than the date on which the TLD is delegated in the DNS. b) Registry Operator shall review the name selection rule described in (a) at least once per year, and publish the results of such review (including any updates to the rule) on its website within thirty (30) days following the anniversary of the Effective Date. 8. If the Community Registration Policy is limited in time, duration, scope, or any other factors, specify the applicable limitations. For example, if a name selection rule is time-limited, the applying entity must state if the rule will apply for the lifetime of the gTLD, only during a specified period, or for some other defined period (such as, Registry Operator shall, for a period of x days from the Effective Date, ___). 9. See Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria for evaluation criteria that ICANN will apply for evaluating each proposed Community Registration Policy.
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.
1. Draft the Community Registration Policy as proposed contract language. Policies that are approved by ICANN will be included in Specification 12 of the applicable Registry Agreement and will be subject to enforcement by ICANN Contractual Compliance. See Appendix 4 Base Registry Agreement, Specification 12 for drafting approach. Consider the usage of defined terms and the definitions of such terms in the 2026 Round Base RA. 2. Enter a single proposed Community Registration Policy in each response field. Up to 10 Community Registration Policies can be submitted. 3. Follow the format to propose what the Registry Operator must do and/or must not do: a) “Registry Operator shall___”; and/or b) “Registry Operator shall not___”. 4. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars: a) ""Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or b) ""Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”. 5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements: a) ""Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring___""; and/or b) ""Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting___"". 6. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example: a) Registry Operator shall develop and implement a Community Registration policy and publish this policy on its website no later than the date on which the TLD is delegated in the DNS. b) Registry Operator shall review the Community Registration Policy described in (a) at least once per year, and publish the results of such review (including any updates to the registration policy) on its website within thirty (30) days following the anniversary of the Effective Date. 7. If the Community Registration Policy is limited in time, duration, scope, or any other factors, specify the applicable limitations. For example, if a commitment is time-limited, the applying entity must state if the rule will apply for the lifetime of the gTLD, only during a specified period, or for some other defined period (such as, Registry Operator shall, for a period of x days from the Effective Date, ___). 8. See Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria for evaluation criteria that ICANN will apply for evaluating each proposed Community Registration Policy.
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.
1. If you are proposing any limitation to a proposed Community Registration Policy in Questions 151-153, please provide a rationale in this response field. Please see Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria. 2. If you are not proposing any limitation to a proposed Community Registration Policy in Questions 151-153, please type ""Not Applicable"" in this response field.
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.
1. Provide an explanation of how the proposed Community Registration Policies meet the Registry Commitments Evaluation criteria 4 and 5 using the considerations in the Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria. 2. Consider whether the proposed Community Registration Policy could be argued to be duplicative of a requirement under applicable law, ICANN agreements, or ICANN Consensus Policies or Temporary Policies. There may be circumstances in which a Community Registration Policy that would duplicate requirements under applicable consensus policy or law could be approved at ICANN’s sole discretion. If not duplicative, please explain why you believe the Community Registration Policy is not duplicative. If yes, please specify such a requirement and explain why you believe duplication in the Base RA is necessary. 3. Consider whether the proposed Community Registration Policy could be argued to be contrary to a requirement under applicable law, ICANN agreements, or ICANN Consensus Policies or Temporary Policies. ICANN will not approve any Community Registration Policies that are found to be contrary to applicable laws, ICANN agreements and policies. Please share your views on this issue in the answer to this question. 4. Consider whether the proposed Community Registration Policy could be argued to be incompatible with ICANN’s Bylaws. ICANN will not approve any Community Registration Policies that are found to be incompatible with the ICANN Bylaws. See background at the ICANN Board resolution 2024.06.08.08-2024.06.08.10. Please share your views on this issue in the answer to this question. 5. Consider whether the proposed Community Registration Policy requires the operation of an additional Registry Service. The applying entity shall engage its selected RSP to discuss the implementation of such an additional Registry Service, which must be evaluated through the RSP Program and approved by ICANN.
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.
Community Endorsement
Please provide evidence of support for the applying entity’s application by attaching written endorsements from the organizing bodies relevant to the identified community (related to Question 136).
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.
Provide an explanation of why opposition may or may not be relevant or how the applying entity intends to address or resolve the opposition, if applicable.
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.
Section: Safeguard Identification
This question set collects information related to determining whether certain Safeguard Public Interest Commitments (Safeguard PICs) are required for the applied-for gTLD string. See Section 7.8.2.3 Safeguard PICs. Answers to these questions will inform assessment by ICANN on whether and which Safeguard PICs must be incorporated in the applicable Registry Agreement (RA) if the string proceeds to delegation. The answers themselves will not automatically make such a determination.
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. I-2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. I-2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
Select Yes or No. Notes: 1. ICANN will evaluate whether an applied-for gTLD string requires one or more Safeguard Public Interest Commitments (Safeguard PICs) to be included in the Base RA). 2. In addition to the Mandatory Public Interest Commitments (PICs) that must be included in each Base RA, a subset of Base RAs must include Safeguard PICs based on ICANN’s Safeguard Assessment. See Section 7.8.2.3 Safeguard PICs. 3. Applying entities for TLDs that are not found to require Safeguard PICs can elect to add them to the applicable Base RAs voluntarily to, for example, further their business objectives, help address issues or concerns that are raised or could be raised with respect to their applications, or avoid the need for the evaluation and implementation of customized Registry Voluntary Commitment (RVC). See Section 7.8.3 Registry Voluntary Commitments (RVCs).
No
Section: Registry Voluntary Commitments (RVCs)
This question set collects information related to any Registry Voluntary Commitments (RVCs) that the applying entity is submitting. The decision to submit an RVC is typically voluntary, except for those recognized by ICANN to resolve an objection or to address GAC Consensus Advice. See Section 7.8.3 Registry Voluntary Commitments for more information.
1. Select Yes or No. 2. In addition to Safeguard Public Interest Commitments (PICs), an applying entity will be permitted to propose one or more Registry Voluntary Commitments (RVCs) to provide additional safeguards with regard to the registry operator’s operation of an applied-for gTLD string. See Section 7.8.3 Registry Voluntary Commitments (RVCs). 3. RVCs are separate from Community Registration Policies. See Section 7.8.3 Registry Voluntary Commitments (RVCs) and Section 7.8.4 Community Registration Policies for more information. If you are applying for a Community gTLD, please submit the Community Registration Policies by answering Questions 150-155. However, if you propose to include additional Registry Voluntary Commitments in the RA beyond the Community Registration Policies, you may answer "yes" and proceed to answer the following questions. 4. You are encouraged to consider whether there are other means, separate from including commitment(s) in the Base RA, that could be used to further your business objectives or help resolve any anticipated or actual issue(s) raised regarding the applied-for gTLD string or application. See Section 7.8.3 Registry Voluntary Commitments (RVCs). Notes: If you select “yes” to this question, you are required to pay the conditional Registry Commitments Evaluation fee, and commitments that are approved by ICANN will be included in Specification 11 of the applicable Base RA as specific voluntary public interest commitments as contractual obligations.
No
Section: Brand & Code of Conduct Exemptions
This question set collects information related to whether the applied-for gTLD string is a .Brand (see Section 7.3) or if the applying entity is seeking a Code of Conduct exemption (see Section 7.4).
Select Yes or No
No
This serves as an indication of intent to apply for an exemption to Specification 9 and that the applying entity is NOT requesting to be designated a .Brand TLD, pursuant to Specification 13.
No
Section: Additional Information and Supporting Materials
This question set collects any additional information that the applying entity would like to provide, including any supporting materials.
Section: Bona Fide Intent and Prohibited Communications
This question set contains attestations related to the applying entity’s acknowledgment of bona fide intent and prohibited communications.
Confirm the statement using the checkbox.
true
Confirm the statement using the checkbox.
true