{"applicationHumanReadableId":"ANL2619T-T13025","applicationDetails":{"applicationHumanReadableId":"ANL2619T-T13025","applicationType":"New gTLD","primaryString":{"aLabel":"avax","uLabel":""},"tldVariants":[],"originalTldVariants":[],"tldTypes":["Community"],"priorityNumber":-1,"applicationStatus":"Active","processingStage":"Pre-Evaluation Processing","hasClarifyingQuestions":false,"hasChangeRequests":false,"hasObjections":false,"lastPublishedAt":"2026-10-07T15:34:14.920Z"},"questionAndResponses":{"applicationHumanReadableId":"ANL2619T-T13025","sections":[{"displayOrder":1,"sectionId":"1","sectionTitle":"Applying Entity Information","sectionInstructions":"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.","questions":[{"displayOrder":1,"questionText":"AGB Q1. Full Legal Name","instructions":"Provide the full legal name of the applying entity as it appears on the official registration documents. Do not use abbreviations.","responseText":"Avax Naming Limited","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":3,"questionText":"AGB Q3. Legal Entity Form/Business Structure","instructions":"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.","responseText":"A company limited by shares","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":4,"questionText":"AGB Q4. Jurisdiction","instructions":"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.","responseText":"British Virgin Islands","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":10,"questionText":"AGB Q10. Website URL","instructions":"Provide the website URL of the applying entity, if available.","responseText":"https://redrock.foundation/","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":11,"questionText":"AGB Q11. Is the applying entity an existing registry operator, ICANN accredited registrar, or an Affiliate of either?","instructions":"1. Choose Yes or No. \n2. Use the definition of Affiliate from the Base Registry Agreement (see  https://www.icann.org/en/registry-agreements/base-agreement).","responseText":"true","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":12,"questionText":"AGB Q12. If \"Yes\", explain.","instructions":"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.\n2. 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.\n3. If the applying entity is an ICANN accredited registrar, specify the registrar ID number.","responseText":"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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":13,"questionText":"AGB Q13. Is the applying entity a back-end registry service provider (RSP), an ICANN-approved data escrow agent, an emergency back-end registry operator, a Uniform Rapid Suspension (URS) service provider, an ICANN dispute resolution service provider, a Privacy or Proxy Service Provider, or a Reseller?","instructions":"Choose Yes or No.","responseText":"false","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":17,"questionText":"AGB Q17. Phone Country Code","instructions":"","responseText":"1","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":18,"questionText":"AGB Q18. Primary Business Phone","instructions":"Provide the primary business phone number without including the country code.","responseText":"6024561408","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":19,"questionText":"AGB Q19. Primary Business Email Address","instructions":"Provide the primary business email address of the applying entity.","responseText":"admin@redrock.foundation","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":20,"questionText":"AGB Q20. Address Line 1","instructions":"Enter the street address (no PO Box).","responseText":"Commerce House","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":21,"questionText":"AGB Q21. Address Line 2","instructions":"","responseText":"Wickhams Cay 1","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":22,"questionText":"AGB Q22. Locality","instructions":"Enter the city, village, municipality, etc.","responseText":"Road Town","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":23,"questionText":"AGB Q23. State/Province/Region","instructions":"Enter the state, province, department, territory, prefecture, oblast, etc., if applicable.","responseText":"Tortola","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":24,"questionText":"AGB Q24. Postal Code","instructions":"1. Enter the postal code, if applicable.\n2. If a postal code does not exist, type “Not Applicable”. ","responseText":"VG1110","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":25,"questionText":"AGB Q25. Country Code of Location","instructions":"","responseText":"VG","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":26,"questionText":"AGB Q26. Full Legal Name","instructions":"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. ","responseText":"Red Rock (Cayman) Foundation","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":28,"questionText":"AGB Q28. Legal Entity Form/Business Structure","instructions":"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.","responseText":"Exempted Foundation Company Limited by Guarantee ","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":29,"questionText":"AGB Q29. Jurisdiction","instructions":"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.","responseText":"Cayman Islands","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":2,"sectionId":"1","sectionTitle":"Applying Entity Background and Organization","sectionInstructions":"This question set collects information related to the individuals who will have access to TAMS, manage the application, and receive inquiries.","questions":[{"displayOrder":1,"questionText":"AGB 104. List all directors of the applying entity.","instructions":"","responseText":"Derek O'Toole","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":2,"questionText":"AGB 105. List all officers & partners of the applying entity.","instructions":"","responseText":"Derek O'Toole","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":3,"questionText":"AGB 106. List all Material Shareholders","instructions":"","responseText":"Red Rock (Cayman) Foundation","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":5,"questionText":"AGB 108. Disclose Ultimate Control of applying entity","instructions":"","responseText":"Red Rock (Cayman) Foundation","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":4,"sectionId":"16","sectionTitle":"Self-Certification","sectionInstructions":"Provide a single document for Self-Certification question Q4.2-1.\r\nThe document must include only the SC4.2-1.1, SC4.2-1.2, or SC4.2-1.3 statements.\r\nDo not modify any of the Self-Certification statements.","questions":[{"displayOrder":1,"questionText":"AGB Q212. Q4.2-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. If financial statements are provided by a Qualified Parent Entity (QPE), the CEO, President, CFO, and/or equivalent officer of the QPE must co-sign the certification document. The self-certification document must represent and warrant: SC4.2-1.1 - The applying entity and/or a QPE will fund the startup and long-term operation of all applied-for gTLD strings and (if applicable) currently operated gTLDs of a QPE. SC4.2-1.2 - The applying entity or QPE has at a minimum of US$50,000 plus 25% of the application base fee for each applied-for gTLD string in Cash and Cash Equivalents on the balance sheet of the provided financial statements, up to a maximum of US$300,000, designated to support the startup and operation of all of the applying entity’s applied-for gTLD strings. SC4.2-1.3 - The applying entity and/or its officers are bound by law in its jurisdiction to represent financial statements accurately and the applying entity is in good standing in that jurisdiction.","instructions":"1. Provide a single document for Self-Certification question Q4.2-1.\n2. The document must include only the SC4.2-1.1 through SC4.2-1.3 statements.\n3. Do not modify any of the Self-Certification statements.\n4. 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.","responseText":"","hasResponseDocuments":true,"hasCr":false,"hasCq":false}]},{"displayOrder":6,"sectionId":"18","sectionTitle":"Security Policy and Planning","sectionInstructions":"Provide a single document for Self-Certification question AGB Q220, Q5.1-1.\r\nThe document must include only the SC5.1-1.1 through SC5.1-1.3 statements.\r\nDo not modify any of the Self-Certification statements.\r\nIf 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.","questions":[{"displayOrder":1,"questionText":"AGB Q220. Q5.1-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. The self-certification document must represent and warrant:\nSC5.1-1.1 - The applying entity will appropriately protect confidentiality of data and prevent unauthorized access to data and services.\nSC5.1-1.2 - The applying entity will maintain a mature, appropriately funded and staffed security program, following a recognized, modern security framework based on risk management (such as the ISO27000 series, COBIT, HITRUST CSF, legally required security frameworks, or equivalent).  The security program must be in place prior to delegation, and exist through at least the period of the registry agreement.\nSC5.1-1.3 - The applying entity is aware of and has designed its systems and business to comply with the relevant privacy and security regulations for all countries in which it operates.","instructions":"1. Provide a single document for Self-Certification question Q5.1-1.\n2. The document must include only the SC5.1-1.1 through SC5.1-1.3 statements.\n3. Do not modify any of the Self-Certification statements.\n4. 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.","responseText":"","hasResponseDocuments":true,"hasCr":false,"hasCq":false}]},{"displayOrder":7,"sectionId":"19","sectionTitle":"DNS Abuse","sectionInstructions":"Provide a single document for Self-Certification question AGB Q221, Q5.2-1.\r\nThe document must include only the SC5.2-1.1 through SC5.2-1.7 statements.\r\nDo not modify any of the Self-Certification statements.\r\nIf 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.","questions":[{"displayOrder":1,"questionText":"AGB Q221. Q5.2-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. The self-certification document must represent and warrant:\nSC5.2-1.1 - The applying entity will, no later than delegation of the Top Level Domain (TLD), establish a dedicated abuse point of contact responsible for addressing matters requiring expedited attention and providing a timely response to abuse complaints concerning any name registered in the TLD.\nSC5.2-1.2 - The applying entity will, no later than delegation of the TLD, establish, publish, and provide to ICANN the location of a mechanism for members of the public to submit reports of abuse in accordance with the current obligations of the Base RA and any Consensus Policies.\nSC5.2-1.3 - The applying entity has developed proposed measures for removal of orphan glue records for names removed from the zone when provided with evidence in written form that the glue is present in connection with malicious conduct (see Specification 6).\nSC5.2-1.4 - The applying entity has or will have at time of delegation, established policies for handling complaints regarding abuse. Such policies are to be maintained and posted publicly so that anyone can review the policies via the Internet and any other means deemed appropriate by the applying entity. The applying entity’s policies at a minimum should contain appropriate confirmation of the receipt of the abuse report, the process of review of the report, and actions that will be taken if the applying entity confirms the report is legitimate.\nSC5.2-1.5 - The applying entity understands that DNS Abuse is Phishing, Malware, Botnets, Pharming and Spam (when used to deliver other forms of DNS Abuse). The applying entity understands and is prepared to contribute to the mitigation or disruption of DNS Abuse in domains in the TLD zone.\nSC5.2-1.6 - The applying entity’s abuse response capabilities are resourced appropriately to ensure a timely and adequate investigation and response to reports of DNS Abuse. This includes capabilities to receive and evaluate evidence of DNS Abuse in reports, and to take action to stop or disrupt the DNS Abuse.\nSC5.2-1.7 - The applying entity is prepared to conduct periodic scans of its zone to identify if domains are being used to perpetrate DNS Abuse, and to maintain statistical reports of the scans, the findings, and actions taken.","instructions":"1. Provide a single document for Self-Certification question Q5.2-1.\n2. The document must include only the SC5.2-1.1 through SC5.2-1.7 statements.\n3. Do not modify any of the Self-Certification statements.\n4. 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.","responseText":"","hasResponseDocuments":true,"hasCr":false,"hasCq":false}]},{"displayOrder":8,"sectionId":"16","sectionTitle":"Primary String","sectionInstructions":"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.","questions":[{"displayOrder":4,"questionText":"AGB Q118. What is the meaning/definition of the applied-for gTLD string?","instructions":"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\"","responseText":"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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":6,"questionText":"AGB Q120.  Phonetic Representation","instructions":"Provide a representation of the string according to the International Phonetic Alphabet.","responseText":"/ˈæv.æks/ (“AV-aks”)","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":7,"questionText":"AGB Q121. As per Section 3(d) of Specification 11 of the Base Registry Agreement, a registry operator of a “generic string” may not impose eligibility criteria for registering names in the TLD that limit registrations exclusively to a single person or entity and/or that person’s or entity’s “Affiliates” (as defined in Section 2.9(c) of the Registry Agreement). “Generic String” means a string consisting of a word or term that denominates or describes a general class of goods, services, groups, organizations or things, as opposed to distinguishing a specific brand of goods, services, groups, organizations or things from those of others. Confirm that the applied-for string is not a “generic string” in which the applying entity intends to limit registrations exclusively to a single person or entity.","instructions":"Confirm the statement using a checkbox.","responseText":"true","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":8,"questionText":"AGB Q133. What is the mission and purpose of the applied-for gTLD?","instructions":"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.\n\n1a. 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.\n\n2. Explain how this purpose is sustainable over time.","responseText":"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.\n\nThe 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.\n\nIntended 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.\n\nThe 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.\n\nAvalanche 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.\n\nActivities 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.\n\nThe 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.","hasResponseDocuments":true,"hasCr":false,"hasCq":false},{"displayOrder":1,"questionText":"AGB Q116. Applied-for Primary String (ASCII Label)","instructions":"","responseText":"avax","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":10,"sectionId":"5","sectionTitle":"Community","sectionInstructions":"This question set collects information specific to Community gTLDs. However, question 133 (Mission & Purpose) must be answered by all applying entities.","subsections":[{"displayOrder":1,"subsectionTitle":"General","questions":[{"displayOrder":2,"questionText":"AGB Q132. What community will the applied-for string serve?","instructions":"1. Provide the name of the community that the applying entity is committing to serve. \r\n2. Describe the distinct aspects of the community.","responseText":"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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":3,"questionText":"AGB Q134. How would you categorize your community?","instructions":"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.","responseText":"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.\n\nThe 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.\n\nLike 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.\n\nParticipation 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.\n\nAvalanche 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.\n\nThese 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.\n\nAccordingly, 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.","hasResponseDocuments":true,"hasCr":false,"hasCq":false},{"displayOrder":1,"questionText":"AGB Q131. Is this application for a community TLD?","instructions":"","responseText":"Yes","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":2,"subsectionTitle":"Organization","questions":[{"displayOrder":3,"questionText":"AGB Q135. What is the applying entity's connection to the community?","instructions":"Describe and provide evidence of the relationship between the applying entity and the identified community.","responseText":"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.\n\nThat 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.\n\nThe 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.\n\nThe 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.\n\nAvax 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.\n\nThis 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.\n\nCorresponding documentation includes the Foundation’s written endorsement and supporting letters from organizations serving the identified functional segments.","hasResponseDocuments":true,"hasCr":false,"hasCq":false},{"displayOrder":4,"questionText":"AGB Q136. How is the community organized? Are there one or multiple organizations (\"organizing body\") that represent or administer the community?","instructions":"Describe and provide evidence related to the community organization, any relevant organizing bodies, and any relevant leaders within the community.","responseText":"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.\n\nAvalanche 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.\n\nFor 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.\n\nAva 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.\n\nA 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.\n\nIndependent 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.\n\nThe 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.\n\nRelevant 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.","hasResponseDocuments":true,"hasCr":false,"hasCq":false},{"displayOrder":5,"questionText":"AGB Q137. Does the community have defined membership requirements, such as registration, licensing, or use of specific communication? Or, do community members self-identify as part of the community? ","instructions":"1. Describe any formal membership process, if there is one.\r\n2. 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).","responseText":"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.\n\nPeople 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.\n\nThe 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.\n\nFoundation 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.\n\nParticipation 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.\n\nMembers 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.\n\nThe 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.","hasResponseDocuments":true,"hasCr":false,"hasCq":false},{"displayOrder":6,"questionText":"AGB Q138. Where is the community located?","instructions":"Provide the primary location of the community.","responseText":"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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":7,"questionText":"AGB Q139. What is the estimated size of the community? This should take into account any regions listed in Question 138.","instructions":"1. Provide the estimated size of the community. The size should be in number format (e.g., “1,000,000 members”).\r\n2. If the community is divided by group, region, sector, etc., this should include estimated size for each group.","responseText":"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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":8,"questionText":"AGB Q140. What portion of the community do any organizing bodies represent or administer to?","instructions":"Provide the estimated size of the community that is administered or represented by each relevant organizing body in the identified community.","responseText":"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","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":3,"subsectionTitle":"Engagement","questions":[{"displayOrder":9,"questionText":"AGB Q141. Do the organizing bodies demonstrate active and consistent efforts to engage and connect with the identified community and its members?","instructions":"1. Provide evidence of any documented practices of community efforts to date\r\n2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission: \r\na) Offering support; \r\nb) Sharing information; \r\nc) Responding to specific community needs;\r\nd) Fostering and strengthening relationships within the community.","responseText":"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.\n\nOFFERING 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.\n\nSHARING 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.\n\nRESPONDING 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.\n\nFOSTERING 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.\n\nTogether, these continuing practices engage developers, validators, L1 operators, infrastructure providers, researchers, founders, DeFi and gaming participants, enterprises, regional groups, and users across the community.","hasResponseDocuments":true,"hasCr":false,"hasCq":false},{"displayOrder":10,"questionText":"AGB Q142. What is the role of the applying entity in the engagement efforts listed in Question 141?","instructions":"1. Describe whether the applying entity has a role in any of the activities listed in Question 141.\r\n2. 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.","responseText":"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.\n\nWithin 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.\n\nAvalanche 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.\n\nThe 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.\n\nThe 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.\n\nAvax 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.\n\nAvax 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.","hasResponseDocuments":true,"hasCr":false,"hasCq":false}]},{"displayOrder":4,"subsectionTitle":"Awareness","questions":[{"displayOrder":11,"questionText":"AGB Q143. Are community members aware of the identified community and each other?","instructions":"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. \r\n2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission:\r\na) Surveys conducted;\r\nb) Records of activities involving a diversity of community groups, segments, or members.","responseText":"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.\n\nThe 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.\n\nRetro9000 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.\n\nBuilder 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.\n\nAvalanche 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.\n\nPublic 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.\n\nThe 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.\n\nNo 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.","hasResponseDocuments":true,"hasCr":false,"hasCq":false},{"displayOrder":12,"questionText":"AGB Q144. Are community members aware of the applying entity and its intention to apply for a community gTLD?","instructions":"1. Provide evidence of community members’ awareness of the applying entity and its intent to apply for a community gTLD. \r\n2. If there is no such evidence, explain why not.","responseText":"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.\n\nAvalanche 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.\n\nAva 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.\n\nAwareness 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. \n\nThe 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.\n\nInstitutional 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.","hasResponseDocuments":true,"hasCr":false,"hasCq":false}]},{"displayOrder":5,"subsectionTitle":"Established Presence","questions":[{"displayOrder":13,"questionText":"AGB Q145. Was there an established presence of the identified community prior to the opening of the application submission period?","instructions":"Provide evidence of the established presence of the community prior to the opening of the application submission period.","responseText":"Yes","hasResponseDocuments":true,"hasCr":false,"hasCq":false},{"displayOrder":14,"questionText":"AGB Q146. Are individuals and groups outside of the identified community aware of the existence of the identified community?","instructions":"1. Provide evidence that demonstrates that individuals and groups outside of the community show an awareness of the identified community. \r\n2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission:\r\na) Media or other public information regarding the community and its activities or members; \r\nb) Discussion of the community in various fora, whether online or in person; \r\nc) Evidence of partnerships or collaborations with groups outside of the identified community;\r\nd) Evidence of the chartering or organization of the community prior to the opening of the application submission window;\r\ne) Evidence of contributions (for example, cultural or scientific) to a larger society or population;","responseText":"AGB Q146. Are individuals and groups outside of the identified community aware of the existence of the identified community?\n\nYes. 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.\n\nMEDIA 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.\n\nDISCUSSION 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.\n\nPARTNERSHIPS 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.\n\nPRIOR 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.\n\nCONTRIBUTIONS 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.\n\nTogether, 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.","hasResponseDocuments":true,"hasCr":false,"hasCq":false}]},{"displayOrder":6,"subsectionTitle":"Longevity","questions":[{"displayOrder":15,"questionText":"AGB Q147. Are the pursuits of the identified community enduring and sustainable?","instructions":"1. Provide evidence of the longevity of the community. \r\n2. The applying entity should provide documentation of the following practices which should have occurred within the two years leading up to application submission:\r\na) Evidence of recurring or scheduled activities that demonstrate continuity over time;\r\nb) Documented records of past activities that demonstrate a long-standing tradition or practice;\r\nc) Records of discussions emphasizing the community’s enduring presence or its cultural significance.","responseText":"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.\n\nLONGEVITY. 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.\n\nRECURRING 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.\n\nCONTINUING 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.\n\nENDURING 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.\n\nSUSTAINABILITY. 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.\n\nThe .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.\n\nMore 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.","hasResponseDocuments":true,"hasCr":false,"hasCq":false}]},{"displayOrder":7,"subsectionTitle":"Nexus","questions":[{"displayOrder":16,"questionText":"AGB Q148. Does the string match the name of the identified community?","instructions":"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.","responseText":"Yes. The identified community’s full name is the Avalanche community, and “AVAX” is its official and well-known short-form identifier.\n\nAVAX 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).”\n\nThe 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.\n\nThe 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.\n\nHistorical 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.\n\nAccordingly, .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.","hasResponseDocuments":true,"hasCr":false,"hasCq":false},{"displayOrder":17,"questionText":"AGB Q149. Will the general public instinctively think of the community when thinking of the applied-for string?","instructions":"1. Explain how the applied-for string clearly relates to or represents the community \r\n2. 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.","responseText":"Yes. When encountered as the Internet identifier .avax, the general public would instinctively associate the string with the Avalanche network and community.\n\nThat 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.\n\nThe 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.\n\nHistorical 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.\n\n“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.\n\nIn 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.","hasResponseDocuments":true,"hasCr":false,"hasCq":false}]},{"displayOrder":8,"subsectionTitle":"Community Registration Policy","questions":[{"displayOrder":18,"questionText":"AGB Q150. Are you proposing to include one or more Community Registration Policies in the Registry Agreement (RA) that are unique to the applying entity's applied-for community gTLD?","instructions":"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.","responseText":"Yes","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":19,"questionText":"AGB Q151.1. Please state a specific Community Registration Policy with respect to registration eligibility for community members.","instructions":"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.\n\n2. 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.\n\n3. Follow this format to propose what the Registry Operator must do and/or must not do:\na) “Registry Operator shall___”; and/or\nb) “Registry Operator shall not___”.\n\n4. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars ,:\na) \"Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or\nb) \"Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”.\n\n5. Follow this format to propose  any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements:\na) \"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\nb) \"Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting ___\".\n\n6. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example:\na) 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.\nb) 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.\n\n7. 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, ___).\n\n8. 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.","responseText":"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:\n\n(a) Operates and controls an Avalanche wallet address on Avalanche Mainnet;\n(b) Operates an active validator of the Avalanche Primary Network or an Avalanche L1;\n(c) Has deployed one or more smart contracts, applications, or Avalanche L1s to Avalanche Mainnet;\n(d) Holds one or more .avax on-chain names issued through documented Avalanche naming infrastructure, as recognized under the Verification Methodology;\n(e) Has received an Avalanche Foundation grant within the 36 months preceding registration;\n(f) Is a verified participant in an Avalanche Foundation-recognized ecosystem program included on the Programs List described below;\n(g) Promotes the Avalanche ecosystem;\n(h) Can provide other objectively verifiable evidence of participation in the Avalanche ecosystem upon request; or\n(i) Intends to satisfy one or more of criteria (a)-(h) within 90 days after registration.\n\nRegistry 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.\n\nRegistry 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.\n\nRegistry 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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":20,"questionText":"AGB Q152.1. State a specific Community Registration Policy with respect to name selection criteria or rules for the applied-for string.","instructions":"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.\n\n2. 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. \n\n3. These criteria or rules should align with the community objectives of the applied-for gTLD string.\n\n4. Follow this format to propose what the Registry Operator must do and/or must not do:\na) “Registry Operator shall___”; and/or\nb) “Registry Operator shall not___”.\n\n5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars:\na) \"\"Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or\nb) \"\"Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”.\n\n6. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements:\na) \"\"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\nb) \"\"Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting ___\"\".\n\n7. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example:\na) 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.\nb) 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.\n\n8. 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, ___).\n\n9. 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.","responseText":"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.\n\nRegistry 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.\n\nRegistry Operator shall independently establish and administer the Reserved Names List under this policy.\n\nRegistry Operator shall create the initial Reserved Names List no later than commencement of the first registration period for the TLD.\n\nAn 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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":21,"questionText":"AGB Q153.1. State a specific Community Registration Policy with respect to an additional commitment besides registration eligibility for community members and naming selection criteria or rules for the applied-for string.","instructions":"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.\n\n2. Enter a single proposed Community Registration Policy in each response field. Up to 10 Community Registration Policies can be submitted.  \n\n3. Follow the format to propose what the Registry Operator must do and/or must not do:\na) “Registry Operator shall___”; and/or\nb) “Registry Operator shall not___”.\n\n4. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars:\na) \"\"Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or\nb) \"\"Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”.\n\n5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements:\na) \"\"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\nb) \"\"Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting___\"\".\n\n6. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example:\na) 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.\nb) 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.\n\n7. 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, ___).\n\n8. 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.","responseText":"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.\n\nRegistry 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.\n\nRegistry Operator shall publish the review process on its website no later than commencement of General Availability.\n\nRegistry 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.\n\nRegistry 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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":22,"questionText":"AGB Q154. Explain the rationale for any limitations to the Community Registration Policy proposed by the applying entity in Questions 151-153.","instructions":"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.\n2. 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.","responseText":"The proposed Community Registration Policies contain limited temporal and scope qualifications, each tailored to the purpose of the applicable policy.\n\nQ151 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.\n\nUnder 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.\n\nUnder 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.\n\nExcept 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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":23,"questionText":"AGB Q155. Explain how the proposed Community Registration Policies of the applying entity meets the Registry Commitments Evaluation criteria 4 and 5?","instructions":"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.\n2. 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.\n3. 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.\n4. 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.\n5. 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.","responseText":"CRITERION 4: DUPLICATION AND CONTRARY REQUIREMENTS. \nThe 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.\n\nQ151 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.\n\nQ152 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.\n\nQ153 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.\n\nNothing 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.\n\nCRITERION 5: ICANN BYLAWS COMPATIBILITY. \nThe 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.\n\nThe 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.\n\nADDITIONAL 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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":9,"subsectionTitle":"Community Endorsement","questions":[{"displayOrder":24,"questionText":"AGB Q156. From where does the applying entity have the support to run the applied-for string on behalf of the identified community?","instructions":"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).","responseText":"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.\n\nAvalanche 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.\n\nThat 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.\n\nAva 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.\n\nSupport 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.\n\nThese 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.\n\nAccordingly, 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.","hasResponseDocuments":true,"hasCr":false,"hasCq":false},{"displayOrder":25,"questionText":"AGB Q157. Is there any opposition to the applying entity, application, or applied-for string that the applying entity is aware of? If yes, please explain.","instructions":"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.","responseText":"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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]}]},{"displayOrder":13,"sectionId":"2","sectionTitle":"Safeguard Identification","sectionInstructions":"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.","questions":[{"displayOrder":1,"questionText":"AGB Q164. Will people see a domain name as more trustworthy because it is registered in your TLD?\r\nThink about how people around the world will understand the TLD string(s) in the application, including literal and informal meanings in different languages and regions.","instructions":"1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts:\r\na. Literally as described in the application\r\nb. Literally in any other language in which the string is a recognized word or phrase.\r\nc. Informally in any language or regional variant, where alternative meanings exist.\r\n2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":2,"questionText":"AGB Q165. Is it likely that consumers will face significant risks if domain names in the TLD(s) in the application are abused?\r\nThink about how people around the world will understand the TLD string(s) in the application, including literal and informal meanings in different languages and regions.","instructions":"1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts:\r\na. Literally as described in the application\r\nb. Literally in any other language in which the string is a recognized word or phrase.\r\nc. Informally in any language or regional variant, where alternative meanings exist.\r\n2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":3,"questionText":"AGB Q166. Would people generally think that this TLD will be used by entities that require strict licensing or accreditation to do business?\r\nThink about how the TLD string(s) in the application will be understood around the world, including both literal and informal meanings in different languages and regions.","instructions":"1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts:\r\na. Literally as described in the application\r\nb. Literally in any other language in which the string is a recognized word or phrase.\r\nc. Informally in any language or regional variant, where alternative meanings exist.\r\n2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":4,"questionText":"AGB Q167. Would most people think that (domains in) the TLD(s) in the application are used for activities that require regular government reporting, inspections, and oversight in various countries?\r\nThink about how the TLD string(s) in the application will be understood around the world, including both literal and informal meanings in different languages and regions.","instructions":"1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts:\r\na. Literally as described in the application\r\nb. Literally in any other language in which the string is a recognized word or phrase.\r\nc. Informally in any language or regional variant, where alternative meanings exist.\r\n2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":5,"questionText":"AGB Q168. Could people reasonably believe that (domains in) your TLD will cause or lead to harassment, harm, aggression, complaints, criticism, distress, or embarrassment?\r\nThink about how the TLD string(s) in the application will be understood globally, including different languages and cultures.","instructions":"1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts:\r\na. Literally as described in the application\r\nb. Literally in any other language in which the string is a recognized word or phrase.\r\nc. Informally in any language or regional variant, where alternative meanings exist.\r\nI-2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":6,"questionText":"AGB Q169. Would most people think that the TLD is used for something usually done by governments?\r\nThink about how the TLD string(s) in the application will be understood globally, including different languages and cultures.","instructions":"1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts:\na. Literally as described in the application\nb. Literally in any other language in which the string is a recognized word or phrase.\nc. Informally in any language or regional variant, where alternative meanings exist.\nI-2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":7,"questionText":"AGB Q170. Are you proposing to include one or more of the Safeguard Public Interest Commitments (Safeguard PICs) in the Registry Agreement (RA) voluntarily regardless of ICANN’s Safeguard Assessment outcomes?","instructions":"Select Yes or No.\n\nNotes:\n1. 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).\n2. 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.\n3. 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).","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":14,"sectionId":"12","sectionTitle":"Registry Voluntary Commitments (RVCs)","sectionInstructions":"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.","questions":[{"displayOrder":1,"questionText":"AGB Q172. Are you proposing to include one or more Registry Voluntary Commitments (RVCs) in the Registry Agreement (RA) that are unique to your applied-for string?","instructions":"1. Select Yes or No.\n2. 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).\n3. 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.\n4. 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).\n\nNotes:\nIf 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.","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":16,"sectionId":"11","sectionTitle":"Brand & Code of Conduct Exemptions","sectionInstructions":"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).","questions":[{"displayOrder":1,"questionText":"AGB Q179. Are you applying for a Brand TLD?","instructions":"Select Yes or No","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":7,"questionText":"AGB Q185. Does the applying entity request a Code of Conduct Exemption?","instructions":"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.","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":17,"sectionId":"13","sectionTitle":"Additional Information and Supporting Materials","sectionInstructions":"This question set collects any additional information that the applying entity would like to provide, including any supporting materials.","questions":[]},{"displayOrder":18,"sectionId":"14","sectionTitle":"Bona Fide Intent and Prohibited Communications","sectionInstructions":"This question set contains attestations related to the applying entity’s acknowledgment of bona fide intent and prohibited communications.","questions":[{"displayOrder":1,"questionText":"AGB Q223. By submitting this Application, the applying entity confirms that it is submitting this Application with a good faith (“bona fide”) intent to operate the gTLD for which it has applied, and that the applying entity has read and understands the provisions of Section 5.2.3.1 Prohibited Communications and Activities of the Applicant Guidebook regarding the New gTLD Program rules prohibiting certain communications and activities to prevent parties from privately resolving string contention among themselves.","instructions":"Confirm the statement using the checkbox.","responseText":"true","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":2,"questionText":"AGB Q224. By submitting this Application, the applying entity confirms that it has read and understands the provisions of Section 5.2.3.1  Prohibited Communications and Activities of the Applicant Guidebook regarding the New gTLD Program rules prohibiting certain communications and activities to prevent parties from privately resolving string contention among themselves.","instructions":"Confirm the statement using the checkbox.","responseText":"true","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]}]}}