Application Details
Last published on: 7 October 2026 at 15:34 UTC
Application Responses
Section: Applying Entity Information
This question set collects information regarding the legal entity that would enter into a Registry Agreement with ICANN upon successful completion of all relevant application processes. The information collected is intended to be used for background screening.
Provide the full legal name of the applying entity as it appears on the official registration documents. Do not use abbreviations.
Mask Naming Limited
Provide the long form (no acronyms) of the legal entity form/business structure of the applying entity as it appears on the official registration documents. If the original script of the legal entity form/business structure is not English, ONLY provide its official English translation. No additional information should be provided as this will be used for the automatic population of the Registry Agreement.
A company limited by shares
The jurisdiction indicates the location in which the business of the applying entity is registered for legal and financial purposes. This is either 1) a country name, or a 2) state/territory name, depending on where the applying entity is registered. No additional information should be provided as this will be used for the automatic population of the Base Registry Agreement. Examples include "Delaware", "Germany", etc.
British Virgin Islands
Provide the website URL of the applying entity, if available.
https://redrock.foundation/
1. Choose Yes or No. 2. Use the definition of Affiliate from the Base Registry Agreement (see https://www.icann.org/en/registry-agreements/base-agreement).
true
1. Specify if the applying entity is an existing registry operator, ICANN accredited registrar, and/or an Affiliate of a registry operator and/or registrar. 2. If the applying entity is an Affiliate, provide the details of such Affiliate relationship, including the name of the affiliated registry operator and/or registrar. 3. If the applying entity is an ICANN accredited registrar, specify the registrar ID number.
The applying entity is an Affiliate of Interstellar Registrar Limited, a British Virgin Islands company and ICANN-accredited registrar (IANA ID 3784). The applying entity and Interstellar Registrar Limited are under the common control of their parent, Red Rock (Cayman) Foundation. The applying entity is not itself an existing registry operator or ICANN-accredited registrar.
Choose Yes or No.
false
1
Provide the primary business phone number without including the country code.
6024561408
Provide the primary business email address of the applying entity.
admin@redrock.foundation
Enter the street address (no PO Box).
Commerce House
Wickhams Cay 1
Enter the city, village, municipality, etc.
Road Town
Enter the state, province, department, territory, prefecture, oblast, etc., if applicable.
Tortola
1. Enter the postal code, if applicable. 2. If a postal code does not exist, type “Not Applicable”.
VG1110
VG
If applicable, provide the full legal name as it appears on the official registration documents of the Direct Parent Company of the applying entity. Do not use abbreviations.
Red Rock (Cayman) Foundation
Provide the long form (no acronyms) of the legal entity form/business structure of the Direct Parent Company as it appears on the official registration documents. If the original script of the legal entity form/business structure is not English, ONLY provide its official English translation.
Exempted Foundation Company Limited by Guarantee
The jurisdiction indicates the location in which the business of the Direct Parent Company is registered for legal and financial purposes. This is either 1) a country name, or a 2) state/territory name, depending on where the Direct Parent Company is registered. Examples include "Delaware", "Germany", etc.
Cayman Islands
Section: Applying Entity Background and Organization
This question set collects information related to the individuals who will have access to TAMS, manage the application, and receive inquiries.
Derek O'Toole
Derek O'Toole
Red Rock (Cayman) Foundation
Red Rock (Cayman) Foundation
Section: Self-Certification
Provide a single document for Self-Certification question Q4.2-1. The document must include only the SC4.2-1.1, SC4.2-1.2, or SC4.2-1.3 statements. Do not modify any of the Self-Certification statements.
1. Provide a single document for Self-Certification question Q4.2-1. 2. The document must include only the SC4.2-1.1 through SC4.2-1.3 statements. 3. Do not modify any of the Self-Certification statements. 4. If the applying entity cannot Self-Certify the SC4.2-1.1 through SC4.2-1.3 statements, provide a document that explains why the applying entity cannot Self-Certify the SC4.2-1.1 through SC4.2-1.3 statements.
Section: Security Policy and Planning
Provide a single document for Self-Certification question AGB Q220, Q5.1-1. The document must include only the SC5.1-1.1 through SC5.1-1.3 statements. Do not modify any of the Self-Certification statements. If the applicant cannot Self-Certify SC5.1-1.1 through SC5.1-1.3 statements, provide a document that explains why the entity cannot Self-Certify the SC5.1-1.1 through SC5.1-1.3 statements.
1. Provide a single document for Self-Certification question Q5.1-1. 2. The document must include only the SC5.1-1.1 through SC5.1-1.3 statements. 3. Do not modify any of the Self-Certification statements. 4. If the applying entity cannot Self-Certify the SC5.1-1.1 through SC5.1-1.3 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.1-1.1 through SC5.1.1-3 statements.
Section: DNS Abuse
Provide a single document for Self-Certification question AGB Q221, Q5.2-1. The document must include only the SC5.2-1.1 through SC5.2-1.7 statements. Do not modify any of the Self-Certification statements. If the applicant cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements.
1. Provide a single document for Self-Certification question Q5.2-1. 2. The document must include only the SC5.2-1.1 through SC5.2-1.7 statements. 3. Do not modify any of the Self-Certification statements. 4. If the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements.
Section: Primary String
This question set collects basic information regarding the string that is being applied for (for example, a-label, meaning, script). If the applying entity opts to designate a replacement string, it must answer the same set of questions for the replacement string from the AGB Question Set 5 on.
mask
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"
“Mask” is the distinctive identifying element of “MetaMask,” the name of a global community and ecosystem organized around the MetaMask wallet. In English, “mask” means a face covering or something that conceals or protects.
Provide a representation of the string according to the International Phonetic Alphabet.
/mæsk/
Confirm the statement using a checkbox.
true
1. Describe the mission and purpose of the applied-for gTLD, including the intended registrants and users, and the related activities that have been or will be carried out to achieve this purpose. 1a. If applying for a variant of an existing gTLD, please also describe the mission and purpose of the existing gTLD, including the intended registrants and users, and the related activities that have been or will be carried out to achieve this purpose. 2. Explain how this purpose is sustainable over time.
The mission of .mask is to establish a trusted, stable, and enduring Internet namespace for the global MetaMask community. MetaMask publicly describes itself as “a global community of developers and designers” and states a shared mission of democratizing access to the decentralized web. The .mask TLD will carry that established identity into the ICANN-administered Domain Name System, providing DNS identities for community websites, applications, resources, services, and organizations. The community is open, global, and participation-based. Members develop software, applications, developer tools, and integrations; use MetaMask wallets and services; contribute documentation, security research, and education; participate in grants, events, forums, and regional activities; and provide infrastructure and partnerships. Shared technology, public channels, resources, programs, and institutions connect these participants under the MetaMask identity. ntended registrants are persons and organizations participating in or affiliated with the ecosystem, including wallet users, developers, application builders and integrators, creators, grant recipients, educators, security and infrastructure providers, regional organizations, and ecosystem partners. Eligibility will be governed by the Community Registration Policies in Q151-Q153. Intended users include community members and the public seeking to discover and interact with MetaMask-aligned participants and resources. The namespace will complement the community’s wallet, identity, application, and on-chain infrastructure while remaining technically distinct from it. A .mask domain will be delegated through the ICANN root and resolve authoritatively through the Domain Name System. A registration may also be paired with a corresponding on-chain identifier or associated with other ecosystem functionality. Any such on-chain counterpart or integration will remain technically distinct from the DNS registration and will not alter the authoritative operation of .mask in the DNS or establish an alternative naming root. Consensys, the primary stewardship organization for the MetaMask ecosystem, selected and endorsed Mask Naming Limited as the community’s applicant and ICANN operating partner after reviewing the registry structure, relevant ICANN and domain-industry experience, Identity Digital RSP arrangement, and community registration framework. Mastercard, Aave Labs, and Blockaid separately support the application from their roles in payments, decentralized finance, and security. Their letters demonstrate recognition of the broader community and expected utility for its participants. Mask Naming independently retains responsibility for the application and, if delegated, registry governance, policies, operations, and compliance. Activities undertaken or planned include pursuing the ICANN application; consulting with Consensys and organizations serving important segments; developing and enforcing community eligibility, name-selection, and review policies; establishing registry infrastructure through Identity Digital; distributing registrations through ICANN-accredited registrars; conducting community-priority and limited registration periods; publishing verification procedures; and maintaining DNS security, abuse mitigation, data escrow, continuity, and ICANN compliance. The purpose is sustainable because the community’s activities create continuing needs for trusted identity, discoverability, authentication, and navigation. Ongoing wallet use, application integrations, open-source development, education, security initiatives, developer activity, and partnerships create recurring demand for Internet identifiers. Registration and renewal revenue will fund registry operations, while Identity Digital’s infrastructure, registrar distribution, and ICANN continuity requirements provide an operational framework independent of any single application, market cycle, or participant.
Section: Community
This question set collects information specific to Community gTLDs. However, question 133 (Mission & Purpose) must be answered by all applying entities.
General
Yes
1. Provide the name of the community that the applying entity is committing to serve. 2. Describe the distinct aspects of the community.
The MetaMask community: a global, online, activity-based community of wallet users, open-source developers, dapp builders and integrators, educators, contributors, security providers, and partners who use, build, extend, secure, or support MetaMask.
Enter a category that best describes your community. Some examples of community categories could include, but are not limited to: activity-based and volunteer groups, online or social media groups, religious or political groups, diasporic communities, linguistic communities, celebrity or sports team supporters.
The MetaMask community is best categorized as a global, online, activity-based open-technology community. It is organized around active participation in MetaMask’s wallet technology, developer platform, open-source projects, applications, extensions, programs, and official channels. MetaMask’s own About page expressly describes MetaMask as “a global community of developers and designers,” providing direct institutional evidence that MetaMask identifies the people participating around its technology and mission as a community. The community includes wallet users, open-source developers and maintainers, decentralized-application builders and integrators, creators, educators, security researchers, grant and program participants, regional contributors, infrastructure and service providers, and ecosystem partners. These groups perform different but complementary activities: users adopt and test the technology; developers build and maintain it; applications integrate it; researchers and security providers protect participants; and educators, community contributors, and partners support adoption and collaboration. Affiliation follows from MetaMask-specific participation rather than admission by one universal membership body. Participation may be demonstrated through use of an official MetaMask client; contributions to MetaMask software, documentation, security, education, or support; development of a MetaMask integration, developer tool, or interoperable service; participation in an official forum, event, grant, or ecosystem program; or provision of infrastructure or services directly supporting MetaMask users and applications. These connections are observable. Software repositories record contributors, maintainers, issues, and accepted changes. Dapp integrations and released developer tools or services can be technically examined. The official MetaMask Community Forum records interaction among users, developers, Consensys moderators, and volunteer Guides through support discussions, feature requests, voting, and developer channels. Grants, programs, events, security initiatives, and institutional partnerships generate public or administrator-maintained records. These MetaMask-specific activities distinguish community participants from persons with only a general interest in blockchain technology. The community is primarily online because its shared technology, repositories, documentation, applications, support channels, and forums operate through the Internet. It is global because participation is not limited by geography and the wallet, developer tools, applications, and contribution channels are available internationally. It is activity-based because affiliation results from using, building, extending, securing, teaching, supporting, or otherwise contributing to MetaMask and its ecosystem. Consensys provides ecosystem-wide stewardship, while independent developers, users, applications, security providers, infrastructure providers, and partners participate through their respective activities. This distributed structure is characteristic of an open-technology community: participants share technology, standards, resources, channels, institutions, and a common mission without belonging to a single closed membership association. Accordingly, the MetaMask community is an established open-technology community defined by MetaMask-specific participation and continuing interaction, rather than merely a customer audience, brand following, or collection of unrelated blockchain users.
Organization
Describe and provide evidence of the relationship between the applying entity and the identified community.
Mask Naming Limited’s connection to the MetaMask community arises from documented institutional endorsement. Consensys, the primary stewardship organization for the MetaMask ecosystem, evaluated the .mask initiative and formally endorsed Mask Naming as the appropriate applicant and ICANN operating partner for the community. That endorsement followed deliberate and documented review. Consensys evaluated the ICANN new gTLD opportunity and the role a MetaMask-aligned DNS namespace could play in the ecosystem’s long-term development. It reviewed Mask Naming’s proposed structure, the ICANN and domain-industry experience of its leadership and advisers, its intended use of Identity Digital as Registry Services Provider, and its proposed community-based registration framework. Following internal review and leadership discussion, Consensys approved the endorsement on May 22, 2026. Its written endorsement records Consensys’s determination that Mask Naming is the appropriate applicant, supports operation of .mask for the MetaMask community, and urges approval of the application. Mask Naming is a dedicated special-purpose registry entity by design. Operating a gTLD is a specialized and regulated function requiring a contracting party accountable to ICANN under the Registry Agreement, qualified registry infrastructure, accredited-registrar distribution, data escrow, security and abuse-mitigation systems, and continuing technical and contractual compliance. The initiative was therefore placed in an entity formed to pursue the application and, if successful, operate the registry for the community. Mask Naming’s leadership and advisers provide relevant ICANN, domain-name, and web3 infrastructure experience, while Identity Digital will provide established registry infrastructure and operational capabilities. The connection is corroborated by organizations serving important community functions. Mastercard, a MetaMask Card partner, supports .mask from its role connecting self-custodial wallet users with global payment infrastructure. Aave Labs supports the application from its role as a major decentralized application whose users commonly connect through MetaMask. Blockaid supports it as a security provider whose technology is integrated into the MetaMask environment to protect users from scams, phishing, and malicious transactions. Each organization identifies the broader MetaMask community, recognizes .mask as its proposed ICANN-administered DNS namespace, supports Consensys’s endorsement of Mask Naming, and looks to Mask Naming to pursue and operate the TLD. Mask Naming is not a corporate affiliate or subsidiary of Consensys, Mastercard, Aave Labs, or Blockaid, and no endorsement confers ownership, control, or decision-making authority over the applicant or registry. Mask Naming independently retains sole responsibility for the application and, if delegated, ultimate responsibility for registry governance, policies, operations, and compliance with the Registry Agreement. Consensys and the supporting organizations provide community endorsement, knowledge, and anticipated participation without directing registry decisions. This structure connects a community-supported initiative with the specialized applicant and operating capability required by ICANN. It preserves Mask Naming’s independent accountability while allowing Consensys and organizations serving payments, decentralized applications, and security to support the namespace and the community commitments made in Q151-Q153. Evidence of the relationship is submitted with this response: Consensys’s written endorsement and the supporting letters of Mastercard, Aave Labs, and Blockaid.
Describe and provide evidence related to the community organization, any relevant organizing bodies, and any relevant leaders within the community.
The MetaMask community is organized functionally rather than through a single membership association or leader. Responsibility is distributed among an ecosystem-wide stewardship institution, technical contributors, official community channels and programs, independent organizations serving particular activities, and Mask Naming Limited for the limited ICANN and DNS function. Consensys is the principal organizing body and stewardship institution for the MetaMask ecosystem. It develops and supports MetaMask products and developer tools; maintains official documentation, repositories, support resources, and communications; and supports grants, education, events, security initiatives, community growth, and partnerships. MetaMask’s About page places the community within the wider Consensys product family, and the Consensys endorsement describes Consensys as responsible for advancing the interests of the ecosystem as a whole. Consensys provides ecosystem-wide coordination without controlling the independent developers, users, applications, researchers, or partners that participate. Technical participation is organized through public repositories and developer resources. MetaMask documentation provides paths to build application integrations, smart accounts, agent wallets, SDK-based services, and other developer tools, and invites participants to join the developer community and contribute through GitHub. Repositories identify maintainers, contributors, issues, proposed changes, and accepted code. Community interaction is organized through official channels. The MetaMask Community Forum connects users and developers with Consensys/MetaMask moderators and volunteer Guides through support, feature requests and voting, developer discussion, announcements, and educational information. MetaMask’s security program separately organizes independent researchers through published bug-bounty rules and reporting procedures. Independent organizations serve important functional segments. Mastercard participates through the MetaMask Card and related payment infrastructure; Aave Labs serves decentralized-finance users who access applications through MetaMask; and Blockaid provides security technology integrated into the MetaMask environment. Their letters demonstrate service to payments, application, user, and security constituencies and recognition of the broader community. They are supporting participants, not ecosystem-wide organizing bodies, and do not claim authority to govern or represent the community as a whole. For the limited DNS function, Consensys formally endorsed Mask Naming Limited as the appropriate applicant and ICANN operating partner, as described in Q135. If .mask is delegated, Mask Naming will administer the registry under its Registry Agreement and the Community Registration Policies in Q151-Q153. Mask Naming does not govern MetaMask products, software development, community programs, or participating organizations. Consensys and the supporting organizations do not control Mask Naming or its registry decisions. Relevant leaders include Joseph Lubin, Founder and Chief Executive Officer of Consensys, who signed the community endorsement, and Gal Eldar, MetaMask Chief Product Officer. MetaMask co-founder Dan Finlay helped lead MetaMask’s development from 2016 until his departure from Consensys in 2026 and remains relevant to the community’s development history. Maintainers, forum moderators, volunteer Guides, security researchers, and leaders of participating organizations provide additional leadership within their defined functions. None claims personal authority over the community as a whole.
1. Describe any formal membership process, if there is one. 2. If there is no formal membership process, provide evidence related to how an individual can join the identified community (i.e., “self-identify” as a community member).
The MetaMask community has no single universal admission, licensing, or membership-registration process. It is an open, participation-based community in which individuals and organizations join through conduct connecting them to MetaMask’s wallet technology, software, developer platform, official channels, programs, or ecosystem services. Members self-identify through participation, but affiliation does not depend solely on an unsupported assertion. The underlying activity is observable and exists independently of the .mask application. People and organizations join through several established paths. They may: 1. Install and use an official MetaMask client and control one or more accounts through it; 2. Develop, publish, or maintain a decentralized application or other integration using MetaMask developer tools or interfaces; 3. Develop or maintain a publicly released software tool, service, or extension designed to interoperate with MetaMask; 4. Contribute software, documentation, security research, education, feature proposals, testing, or support through MetaMask repositories or official channels; 5. Create an account and participate in the official MetaMask Community Forum or another recognized community activity; 6. Receive a MetaMask or Consensys ecosystem grant or participate in a recognized developer, security, education, or ecosystem program; or 7. Provide documented infrastructure, security, payment, application, or other services directly supporting MetaMask participants. The degree of formality depends on the path. Installing and using an official client, reviewing public resources, and beginning development are open and self-directed. Repository contributions follow published technical and contribution processes. Forum participants create accounts and agree to forum terms and community rules; some posting functions require documented reading or participation thresholds. MetaMask’s security program has published submission and responsible-disclosure requirements. Grants and other programs use applicable application, evaluation, and selection procedures. Institutional integrations and partnerships are documented by the participating organizations. Participation can therefore be evidenced in several ways. Use of an official client may be demonstrated through a client-initiated verification process. Public repositories record contributors, issues, proposed changes, and accepted code. Released developer tools, services, extensions, and application integrations can be technically examined. Forum accounts and posts document community interaction. Security reports, grant records, program records, event materials, and institutional documentation identify other forms of participation. These records distinguish active or affiliated participants from persons who merely recognize the MetaMask brand or have a general interest in blockchain technology. Members do not receive a uniform package of membership rights. The opportunities and benefits associated with participation depend on the activity and may include use of wallet and developer infrastructure, access to documentation and public channels, collaboration with other participants, the ability to submit support requests or feature proposals, contribution to open-source projects, and, where applicable, program-specific funding, mentorship, recognition, or technical support. The Community Registration Policy in Q151 does not create or define the MetaMask community. It draws from the subset of established participation paths that can be verified under a published methodology and translates them into eligibility requirements for .mask registrations. The broader community therefore remains open and participation-based, while registry eligibility is restricted to persons and entities that satisfy the published community criteria.
Provide the primary location of the community.
Global and primarily online, with no single geographic center. MetaMask is available in approximately 190 countries, with community participation through wallet clients, dapps, repositories, forums, programs, events, and partner networks.
1. Provide the estimated size of the community. The size should be in number format (e.g., “1,000,000 members”). 2. If the community is divided by group, region, sector, etc., this should include estimated size for each group.
100,000,000+ annual MetaMask users worldwide (Consensys, March 2025), with 100,000,000+ downloads and availability in approximately 190 countries reported in July 2026. Developer, forum, security, and partner groups overlap the user base.
Provide the estimated size of the community that is administered or represented by each relevant organizing body in the identified community.
Consensys serves the estimated 100,000,000+ annual users ecosystem-wide. Mask Naming represents the community solely for the .mask application and registry. Moderators and Guides administer an overlapping forum subset; its size is unpublished.
Engagement
1. Provide evidence of any documented practices of community efforts to date 2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission: a) Offering support; b) Sharing information; c) Responding to specific community needs; d) Fostering and strengthening relationships within the community.
Yes. During the two years preceding submission, the MetaMask community maintained continuous, publicly documented engagement through complementary participants and channels. Consensys and MetaMask teams provided ecosystem-wide stewardship, infrastructure, and formal programs; moderators and volunteer Guides supported community channels; and developers, researchers, users, and partners contributed through development, reporting, feedback, integrations, and peer support. OFFERING SUPPORT. The community’s support structure includes free wallet software, public repositories, developer documentation, an official Community Forum, a support knowledge base, and technical assistance. The MetaMask HackerOne program enables independent researchers to improve the ecosystem and receive compensation. An August 2024 security report recorded 120 vulnerability reports over 90 days, an average of three days and fifteen hours from submission to bounty, and $266,000 paid cumulatively. In June 2026, the Embedded Wallets Startups Program began offering qualifying teams credits, integration assistance, technical guidance, and a free tier supporting up to 1,000 monthly active wallets. SHARING INFORMATION. Information flows through official and community-created channels. MetaMask teams publish releases, roadmaps, developer documentation, SDK references, guides, audit reports, support articles, security warnings, and educational materials. Members exchange support, feature requests, and developer guidance through the official forum. In October 2025, Builder Hub consolidated developer communications, direct team and peer support, official documentation, community-created guides, and mentorship opportunities. Monthly Crypto Security Reports throughout 2025 and 2026 kept users, builders, and researchers informed about exploits, phishing, malicious extensions, supply-chain attacks, and protective practices. RESPONDING TO SPECIFIC COMMUNITY NEEDS. Needs are surfaced through support interactions, feature requests, builder discussions, vulnerability reports, and partner integrations. MetaMask provides an in-wallet route to its public feature-request forum, where members propose and upvote improvements and submissions are regularly considered by developers. Its December 2025 product report organized work around three needs: making transactions easier, interconnectivity seamless, and self-custody more powerful and secure. It documented multichain accounts and native support for Solana, Bitcoin, Monad, and Sei; integrated bridging and network fees in swaps; and social login, device synchronization, and redesigned screens. Security responses combine internal work with partner intelligence, researcher reports, and community reporting. In 2025, these protections blocked more than 6.5 million malicious-site visits and nearly 150,000 malicious transactions, helping users avoid more than $500 million in losses. Independent testing corroborates that security work: Coinspect’s January 2026 ranking evaluated 77 wallets across iOS, Android, and browser extensions through 2,233 individual security checks and reported MetaMask in the #1 position on all three platforms. Embedded Wallets’ login and recovery options also addressed onboarding and seed-phrase risks. FOSTERING AND STRENGTHENING RELATIONSHIPS. The Community Forum, Builder Hub, public repositories, bug-bounty program, support channels, developer programs, and partner integrations create recurring contact among users, developers, moderators, researchers, dapp teams, and service providers. Builder Hub connects developers with MetaMask personnel and peers; the Startups Program adds implementation support; and public repositories and common developer tooling enable independent teams to contribute and build for the wider user community. These mechanisms demonstrate sustained collaboration rather than one-way company communications across the principal segments identified in Q132.
1. Describe whether the applying entity has a role in any of the activities listed in Question 141. 2. If the applying entity does play a role, provide evidence of the applying entity’s role. If the applying entity does not play a role, describe why this is the case.
Mask Naming Limited's role in the engagement described in Q141 is specific and complementary. It is the entity through which the community-supported .mask Internet-naming initiative is carried into the ICANN system and, if approved, through which .mask will be established and operated as a durable DNS resource for the MetaMask community. Within the activities described in Q141, Mask Naming's contribution has been consultative and preparatory. Mask Naming and the principals and advisers supporting its application engaged with Consensys and organizations serving significant community functions to understand naming, identity, security, application-integration, and user-access needs; define the proposed DNS initiative; and develop the community-based framework reflected in Q151-Q153. That engagement connects the initiative with the ecosystem-wide stewardship, developer activity, security research, community feedback, and partner relationships documented in Q141. Consensys formally endorsed Mask Naming for the ICANN role after reviewing the proposed applicant structure, the ICANN and domain-industry experience supporting it, the intended use of Identity Digital as Registry Services Provider, and the proposed community registration framework. That engagement is further evidenced by written letters from Mastercard, Aave Labs, and Blockaid. Each identifies Mask Naming and the .mask application, describes the organization's relationship with MetaMask and the participants it serves, and explains the anticipated community benefit of establishing .mask in the DNS. Together, the letters document consultation and support across ecosystem stewardship, payments, decentralized finance, application access, and user security. The recurring engagement mechanisms described in Q141 continue through the participants equipped to administer them. Consensys and MetaMask teams maintain the products, documentation, formal programs, and support infrastructure; moderators and volunteer Guides support community channels; developers contribute code and extensions; researchers participate in vulnerability reporting; and partners provide integrations and services. Mask Naming's ICANN and registry role complements those functions by providing the community they sustain with a dedicated Internet-naming channel. Mask Naming's continuing contribution will be to translate that consultation into published and enforceable Community Registration Policies, qualified registry infrastructure, accredited-registrar distribution, DNS security and abuse controls, communications concerning .mask, and continuing ICANN compliance. As the initiative progresses, it will engage prospective registrants, ecosystem organizations, developers, partners, and service providers concerning eligibility, launch, adoption, and appropriate use of the namespace. Mask Naming will independently make and remain accountable for all application and registry decisions. Consensys and the supporting organizations contribute community knowledge, evidence, endorsement, and anticipated participation; their support does not confer ownership of Mask Naming or authority to approve, direct, or veto registry decisions.
Awareness
1. Provide evidence that demonstrates that community members are aware of the identified community and the different member groups or segments within the identified community. 2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission: a) Surveys conducted; b) Records of activities involving a diversity of community groups, segments, or members.
Yes. Members recognize the MetaMask community as a shared ecosystem and the principal groups within it. Awareness does not require each member to know every participant personally; it is demonstrated by recurring channels and activities through which wallet users, developers, moderators, researchers, dapp teams, and partners identify their roles, interact, and observe one another's contributions. The official MetaMask Community Forum provides direct evidence. It describes itself as a platform for community support and contributions and maintains channels for announcements, user support, feature requests, developer discussions, integrations, and translations. Activity during 2025 and 2026 records users exchanging assistance, moderators and Guides responding, developers discussing integrations and technical problems, members proposing and upvoting changes, and multilingual participants submitting translations. These exchanges occur under a common MetaMask identity while making different segments visible to one another. Builder Hub provides a parallel developer record. Launched in October 2025, it was created for MetaMask developers to connect, collaborate, learn, obtain assistance from MetaMask teams and peers, contribute guides and best practices, and discover mentorship opportunities. It brings together builders using MetaMask SDK, Smart Accounts, Embedded Wallets, and related tools rather than isolating them in separate product channels. Public repositories and developer resources demonstrate awareness through shared technical activity. Maintainers, independent contributors, dapp teams, SDK users, and integration partners work through common MetaMask repositories, documentation, interfaces, and issue trackers. Those records identify contributors, applications, proposed changes, accepted code, and integration paths, making the roles and work of different technical segments visible across the community. Security activity connects additional segments. MetaMask's HackerOne program receives reports from independent researchers, recognizes participating researchers, and documents remediation and bounties. Monthly Crypto Security Reports identify threats, researchers, security partners, affected applications, and protective responses for users and developers. In 2025, MetaMask protections blocked more than 6.5 million malicious-site visits and nearly 150,000 malicious transactions, reflecting interaction among users, MetaMask teams, researchers, reporting communities, and security providers. Records of in-person and virtual activity provide further evidence of diverse participation. At Devcon 7 and ETHGlobal Bangkok in November 2024, MetaMask and Consensys personnel joined developers, researchers, founders, creators, and users through presentations, panels, mentoring, technical support, judging, and hackathon bounties. Developer programs, support channels, and integrations with Mastercard, Aave Labs, and Blockaid continue relationships across payments, DeFi, application access, and security. No general membership-awareness survey was conducted during the two-year period. The community has no universal membership roll, and the self-custodial wallet does not require collection of identifying information from users. A conventional survey would reach only a self-selected subset and would not reliably measure the community as a whole. Forum records, Builder Hub participation, repository activity, security reporting, events, and partner activities instead provide direct, contemporaneous evidence involving diverse community groups.
1. Provide evidence of community members’ awareness of the applying entity and its intent to apply for a community gTLD. 2. If there is no such evidence, explain why not.
Yes. Community awareness is demonstrated by documented support for the .mask initiative and by the community's endorsement of Mask Naming Limited as the dedicated entity through which that initiative will be pursued. The community's awareness therefore encompasses both the objective—establishing .mask as its ICANN-administered DNS namespace—and the mechanism for achieving it: Mask Naming as the applicant and prospective registry operator. Consensys, the MetaMask community's principal stewardship institution, evaluated the ICANN opportunity and the role a MetaMask-aligned DNS namespace could play in the ecosystem's long-term development. It reviewed the proposed applicant structure, the ICANN and domain-industry experience of the leadership and advisers supporting the initiative, the intended use of Identity Digital as Registry Services Provider, and the proposed community registration framework. Following internal review and leadership discussion, Consensys approved its endorsement on May 22, 2026. Its written endorsement identifies Mask Naming, confirms that it is the appropriate applicant and ICANN operating partner for the MetaMask community, supports its application, and urges ICANN to approve it. Mask Naming is the special-purpose legal vehicle through which that endorsed community initiative is implemented. Its intention to apply is not separate from the community support documented here: pursuing the application and, if approved, operating the registry are the functions for which the entity was formed and endorsed. Consensys's letter therefore demonstrates awareness of the initiative, the applicant, and the applicant's intended role as one integrated undertaking. That awareness and support extend beyond Consensys. Mastercard, Aave Labs, and Blockaid each executed a separate letter specifically identifying Mask Naming and supporting its .mask application. Mastercard does so as a MetaMask Card partner connecting wallet users with payment infrastructure; Aave Labs as a major decentralized application whose users commonly access DeFi through MetaMask; and Blockaid as a security provider whose technology is integrated into the MetaMask environment. Each describes its relationship with MetaMask, recognizes the expected community benefit of .mask, and supports Mask Naming's pursuit and operation of the TLD. These letters are not generic endorsements of the string or statements that any applicant should obtain .mask. Every endorsement submitted with the application is directed specifically to Mask Naming and supports it as the entity responsible for completing the ICANN process and operating the namespace. Together, they demonstrate that the community's principal stewardship institution and organizations participating in payments, applications, DeFi, and security understand who the applicant is, what it intends to do, and why that role serves the community. This institutional evidence is appropriate for the open, distributed community described in Q136 and Q137. The MetaMask community has no universal membership roll or general assembly through which every participant could receive formal notice or adopt a collective resolution. Its positions are expressed through its stewardship institution and through organizations with documented participation in important community functions. Each supporting organization speaks from its own participation and does not purport to bind every member. Mask Naming will independently remain responsible to ICANN for the application and registry. That operational independence implements the community's endorsement; it does not alter the community-supported origin and purpose of the .mask initiative.
Established Presence
Provide evidence of the established presence of the community prior to the opening of the application submission period.
1. Provide evidence that demonstrates that individuals and groups outside of the community show an awareness of the identified community. 2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission: a) Media or other public information regarding the community and its activities or members; b) Discussion of the community in various fora, whether online or in person; c) Evidence of partnerships or collaborations with groups outside of the identified community; d) Evidence of the chartering or organization of the community prior to the opening of the application submission window; e) Evidence of contributions (for example, cultural or scientific) to a larger society or population;
Yes. The MetaMask community is widely recognized beyond its own participants. During the two years preceding submission, financial institutions, independent media, academic researchers, conference audiences, and independently operated technology organizations consistently identified MetaMask as an ecosystem connecting wallet users, developers, applications, infrastructure providers, and partners. MEDIA AND PUBLIC INFORMATION. Independent reporting has regularly covered the community's activities and technical development. In February 2025, CoinDesk reported MetaMask's roadmap announcements from ETHDenver, including smart-account capabilities, simplified transactions, the MetaMask Card, and expansion to additional networks. Forbes examined the MetaMask Card and MetaMask's global reach, while Bloomberg reported its stablecoin initiative and collaboration with Bridge and M0. This reporting presents MetaMask to external audiences as an established platform with users, developers, integrations, and continuing technical activity. DISCUSSION IN PUBLIC FORA. MetaMask's roadmap was presented and discussed during ETHDenver 2025, a major public Ethereum conference. MetaMask and independently operated organizations also engaged participants through product demonstrations, developer programming, and collaborative activities at events including EthCC and Cannes in 2025. Aave's published events recap records a MetaMask-Aave activation that helped introduce the MetaMask Card and the Linea Aave market. These activities exposed the community and its work to developers, businesses, media, and users outside its existing participant base. PARTNERSHIPS AND COLLABORATIONS. Mastercard's August 2024 account of developing the MetaMask Card describes a cross-industry coalition involving MetaMask, Mastercard, Baanx, issuers, program managers, and technology providers across multiple regions. Mastercard subsequently identified MetaMask among the wallet partners enabling stablecoin use through traditional cards at more than 150 million merchant locations. Aave integrated its lending infrastructure into MetaMask Earn and the MetaMask Card, while Blockaid supplies security alerts protecting users from scams, phishing, and malicious transactions. Signed letters from Mastercard, Aave Labs, and Blockaid independently recognize the MetaMask community, identify participant groups within it, and describe their continuing relationships with those groups. PRIOR ORGANIZATION. MetaMask originated in 2016. By September 2022, its Community Forum Manifesto documented an official forum in which users and developers interacted with one another and with the MetaMask team, supported by Consensys moderators and volunteer Community Guides. This evidence predates the application period and demonstrates that the community's organization and communications were not created for this application. CONTRIBUTION TO THE LARGER PUBLIC. MetaMask's open-source wallet and developer infrastructure provide public means to access decentralized applications and participate in blockchain networks. The MetaMask Card extends self-custodial assets to ordinary commerce, while Blockaid's integrated alerts address fraud and transaction safety. A 2025 IEEE/ACM study treated MetaMask as a significant open-source project within the Ethereum ecosystem, described it as a widely used interface for wallets and decentralized applications, and analyzed its substantial repository activity and contributor network. That independent scholarly attention further demonstrates recognition of the community's technical and social contribution. Together, this evidence shows awareness that is institutional, public, and practical: external organizations do not merely recognize the MetaMask name; they report on, study, collaborate with, and build services for the community and its members.
Longevity
1. Provide evidence of the longevity of the community. 2. The applying entity should provide documentation of the following practices which should have occurred within the two years leading up to application submission: a) Evidence of recurring or scheduled activities that demonstrate continuity over time; b) Documented records of past activities that demonstrate a long-standing tradition or practice; c) Records of discussions emphasizing the community’s enduring presence or its cultural significance.
Yes. The MetaMask community's pursuits are enduring because they concern the continuing development, security, support, extension, and use of self-custodial wallet and developer infrastructure rather than a finite campaign, event, or product release. LONGEVITY. MetaMask originated in 2016 and marked its tenth anniversary in 2026. It developed from an Ethereum browser extension into a global wallet and developer ecosystem with more than 100,000,000 annual users and availability in approximately 190 countries. Public repositories preserve years of software contributions, issues, and technical discussion. The official Community Forum, whose 2022 Manifesto describes interaction among users, developers, Consensys moderators, and volunteer Guides, reflects an established practice of support and participation predating this application. RECURRING ACTIVITIES. Continuity is demonstrated by public software releases and roadmaps, repository contributions, developer documentation, the Community Forum, support resources, feature-request processes, security reporting, vulnerability bounties, developer programs, and events. These activities continued throughout the two years preceding submission. Monthly Crypto Security Reports documented threats and protective responses during 2025 and 2026. The HackerOne program continued to receive and reward reports from independent researchers. MetaMask and Consensys personnel also engaged builders through recurring conferences, hackathons, technical support, and developer programming. Programs and development activity continue across multiple cycles. Builder Hub, launched in October 2025, established a continuing channel for developer collaboration, documentation, peer support, and mentorship. The Embedded Wallets Startups Program added integration assistance and technical guidance for qualifying builders in 2026. MetaMask’s 2025 review documented continuing releases addressing user needs, including multichain support, improved transactions, simplified onboarding, and strengthened security. FUNCTIONAL AND INSTITUTIONAL DURABILITY. The community is not dependent on one activity. Participants build and use wallet clients, dapp integrations, SDKs, smart accounts, payment tools, DeFi integrations, educational resources, support systems, and security protections. Consensys provides continuing ecosystem-wide stewardship, while independent developers, moderators, researchers, applications, and partners perform complementary functions. Mastercard’s payment infrastructure, Aave’s decentralized-finance integrations, and Blockaid’s security protections demonstrate durable relationships with independently operated institutions serving distinct needs. The institutional relationship supporting this application provides additional evidence of long-term stewardship. Consensys's endorsement describes its continuing responsibility for the MetaMask ecosystem and supports a dedicated applicant with relevant ICANN and domain-industry experience and Identity Digital registry infrastructure to establish and maintain .mask for the community. The Mastercard, Aave Labs, and Blockaid letters likewise express an interest in the community's continued growth and long-term success. The .mask registry will add a sustainable Internet-identity function to these existing pursuits. Registration and renewal revenue, accredited-registrar distribution, Identity Digital's infrastructure, and ICANN's continuity, security, data-escrow, and compliance requirements provide a durable operating model. The registry therefore extends an established community with a continuing DNS resource; it is not the source of the community or the condition of its survival.
Nexus
Explain how the applied-for string matches the name of the community or is a well-known alternative name (whether long or short form) of the community.
Yes, as a recognized short-form representation rather than an exact reproduction of the community's full name. The identified community is the MetaMask community. “MetaMask” is a compound name, and the applied-for string matches its second component, “Mask,” exactly. That component is not an arbitrary truncation. MetaMask's published origin history explains that “Meta” refers to the self-referential and that “Mask,” in the sense of a decorative or dramatic mask, is a metaphor for identity. The combined name was intended to convey “the identity of your identities” and the management of multiple identities. “Mask” therefore carries the identity-bearing concept at the center of the MetaMask name, technology, and community. The community's principal stewardship institution deliberately adopted .mask as the short DNS representation of that community. Consensys reviewed the proposed namespace, applicant structure, registry infrastructure, and community registration framework and formally endorsed Mask Naming Limited's application. Its written endorsement describes .mask as the natural DNS representation and a natural and established identifier for the MetaMask community. That recognition is independently corroborated across important community functions. Mastercard, Aave Labs, and Blockaid each executed a letter identifying .mask as the MetaMask community's proposed ICANN-administered domain space. Those organizations participate from different perspectives—payments, decentralized applications and DeFi, and user security—but each recognizes the same connection between “mask” and the MetaMask community and supports its use as the community's DNS identifier. The selection of .mask rather than .metamask is intentional. The shorter form preserves the distinctive, identity-related element of the community name while creating a concise Internet namespace suitable for users, developers, applications, integrations, and services. The application does not assert that “mask” is textually identical to the full name “MetaMask.” Its string-match basis is that .mask is a documented and community-recognized short-form representation of that name, formally endorsed by the institution responsible for ecosystem-wide stewardship and corroborated by organizations serving distinct community segments. Accordingly, the applied-for string matches the “Mask” component of “MetaMask” exactly and functions as the community's recognized short-form DNS name.
1. Explain how the applied-for string clearly relates to or represents the community 2. Explain whether the applied-for string has any other significant meaning beyond identifying the community or community members described in the application. The applying entity may wish to provide pertinent information regarding any particular geography, region, or themes that may be alluded to by the string, of which the community may or may not be a part.
In the context of an Internet top-level domain associated with wallets, digital identity, decentralized applications, and web3 participation, the public would associate .mask with the MetaMask community. MetaMask is a globally recognized name used consistently for the wallet, developer platform, open-source projects, community channels, integrations, and ecosystem programs described throughout this application. “Mask” is the exact second component of that name and carries its central identity meaning. MetaMask's published origin account explains that the mask is a metaphor for identity and that MetaMask was conceived as a means of managing a person's multiple identities. The applied-for string therefore relates directly to the community's recognized name, function, and identity theme; it is not an invented acronym or unrelated label. The association is supported institutionally. Consensys, the principal stewardship organization for the MetaMask ecosystem, expressly identifies .mask as the community's natural DNS representation. Mastercard, Aave Labs, and Blockaid independently describe .mask as the MetaMask community's proposed ICANN-administered domain space and identify its intended users as MetaMask developers, applications, wallet users, and ecosystem participants. Their agreement across payments, DeFi, applications, and security demonstrates that the association is understood beyond the applicant itself. Operation of the namespace will reinforce that meaning. Registration eligibility will be limited to persons and entities satisfying published criteria tied to participation in, affiliation with, or a qualifying intent to participate in the MetaMask ecosystem. The naming, launch, registrar, and communications framework will present .mask as the DNS namespace for MetaMask-aligned users, builders, applications, and services. Registrations used for wallets, dapps, developers, support resources, identity, and integrations will create a consistent community signal rather than an unrestricted collection of unrelated uses. The word “mask” also has significant meanings outside this community. In ordinary English it refers to a covering for the face, an object used for protection or disguise, or a representation of identity or role. That identity-related meaning helped inspire the MetaMask name but is not exclusive to it. “Mask” and “MASK” are also used by other persons, products, and organizations, including the distinct Mask Network project and its MASK token. Mask Naming does not claim that every use of the ordinary word identifies MetaMask, that MetaMask owns the word in all contexts, or that those unrelated uses are part of the identified community. The relevant association is the applied-for string as an operated Internet namespace. In that context, the combination of MetaMask's public recognition, the exact inclusion of “Mask” in its name, the identity meaning documented by its founders, the community's deliberate endorsement of .mask, and community-restricted operation makes the MetaMask community the clearest intended organized-community association.
Community Registration Policy
Select from Radio Buttons - Yes/No. Notes: 1. Community Registration Policies are conditions that community gTLD registry operators impose upon registrants within their gTLDs. 2. If you select “Yes” to this question, the applying entity is required to pay the conditional Registry Commitments Evaluation fee, and Community Registration Policies that are approved by ICANN will be scored in the CPE (if the applying entity elects to participate) and included in Specification 12 of the applicable Base RA. 3. If you select “No,” then the application cannot proceed as a community application.
Yes
1. Draft the Community Registration Policy as proposed contract language. Policies that are approved by ICANN will be included in Specification 12 of the applicable Registry Agreement and will be subject to enforcement by ICANN Contractual Compliance. See Appendix 4 Base Registry Agreement, Specification 12 for drafting approach. Consider the usage of defined terms and the definitions of such terms in the 2026 Round Base RA. 2. Enter a single proposed Community Registration Policy with respect to registrant eligibility in each response field. Up to 10 Community Registration Policies can be submitted. 3. Follow this format to propose what the Registry Operator must do and/or must not do: a) “Registry Operator shall___”; and/or b) “Registry Operator shall not___”. 4. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars ,: a) "Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or b) "Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”. 5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements: a) "Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring ___"; and/or b) "Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting ___". 6. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example: a) Registry Operator shall develop and implement a registration eligibility policy and publish this policy on its website no later than the date on which the TLD is delegated in the DNS. b) Registry Operator shall review the registration policy described in (a) at least once per year, and publish the results of such review (including any updates to the registration policy) on its website within thirty (30) days following the anniversary of the Effective Date. 7. If the Community Registration Policy is limited in time, duration, scope, or any other factors, specify the applicable limitations. For example, if a registrant eligibility restriction is time-limited, the applying entity must state if the restriction will apply for the lifetime of the gTLD, only during a specified period, or for some other defined period (such as, Registry Operator shall, for a period of x days from the Effective Date, ___). 8. See Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria for evaluation criteria that ICANN will apply for evaluating each proposed Community Registration Policy.
Registry Operator shall restrict registrant eligibility for second-level domain names in the .mask TLD to persons or entities that demonstrate participation or affiliation with the MetaMask ecosystem at the time of initial registration or an intent to participate within 90 days after registration. An eligible registrant shall satisfy at least one of the following criteria pursuant to the Verification Methodology described below: (a) Uses an official MetaMask client and demonstrates control of one or more accounts through a verification flow initiated using that client; (b) Has developed, published, or maintains a decentralized application, application integration, or other service using an official MetaMask developer interface, tool, or API; (c) Has developed or maintains a publicly released software tool, service, or extension designed to interoperate with MetaMask; (d) Has made a documented contribution to a public MetaMask software repository, documentation project, security program, educational initiative, forum, or other community channel; (e) Has received a Consensys or MetaMask ecosystem grant within the 36 months preceding registration; (f) Is a verified participant in a Consensys- or MetaMask-recognized ecosystem program included on the Programs List described below; (g) Promotes the MetaMask ecosystem; (h) Can provide other objectively verifiable evidence of participation in the MetaMask ecosystem upon request; or (i) Intends to satisfy one or more of criteria (a)-(h) within 90 days after registration. Registry Operator shall maintain and publish on its website a sample list of programs eligible under criterion (f) (the “Programs List”). Registry Operator shall independently administer the Programs List and may add, remove, or recognize substantially equivalent programs in accordance with the published Verification Methodology. Registry Operator shall publish the Verification Methodology on its website no later than commencement of the first registration period. The Verification Methodology shall identify the information or records used to evaluate each criterion, the party responsible for verification, and the procedures through which compliance with the eligibility requirements will be evaluated. Registry Operator shall administer eligibility verification in accordance with the published Verification Methodology and maintain records sufficient to demonstrate compliance with this Community Registration Policy. Records or confirmation supplied by Consensys, MetaMask, 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 .mask TLD. Registry Operator shall permit a trademark holder to register a second-level domain name that is identical to its trademark at any time, even if the holder does not otherwise satisfy criteria (a)-(i), as part of Registry Operator’s efforts to create a safe and reputable namespace.
1. Draft the Community Registration Policy as proposed contract language. Policies that are approved by ICANN will be included in Specification 12 of the applicable Base Registry Agreement and will be subject to enforcement by ICANN Contractual Compliance. See Appendix 4 Base Registry Agreement, Specification 12 for drafting approach. Consider the usage of defined terms and the definitions of such terms in the 2026 Round Base RA. 2. Enter a single proposed Community Registration Policy with respect to name selection criteria or rules for the applied-for string in each response field. Up to 10 Community Registration Policies can be submitted. 3. These criteria or rules should align with the community objectives of the applied-for gTLD string. 4. Follow this format to propose what the Registry Operator must do and/or must not do: a) “Registry Operator shall___”; and/or b) “Registry Operator shall not___”. 5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars: a) ""Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or b) ""Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”. 6. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements: a) ""Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring___""; and/or b) ""Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting ___"". 7. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example: a) Registry Operator shall develop and implement a name selection rule and publish it on its website no later than the date on which the TLD is delegated in the DNS. b) Registry Operator shall review the name selection rule described in (a) at least once per year, and publish the results of such review (including any updates to the rule) on its website within thirty (30) days following the anniversary of the Effective Date. 8. If the Community Registration Policy is limited in time, duration, scope, or any other factors, specify the applicable limitations. For example, if a name selection rule is time-limited, the applying entity must state if the rule will apply for the lifetime of the gTLD, only during a specified period, or for some other defined period (such as, Registry Operator shall, for a period of x days from the Effective Date, ___). 9. See Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria for evaluation criteria that ICANN will apply for evaluating each proposed Community Registration Policy.
Registry Operator shall not permit registration of a second-level domain name in the .mask TLD that is identical, without regard to letter case, to a label included on the Reserved Names List unless Registry Operator provides written authorization. Registry Operator shall maintain and publish on its registrar portal a Reserved Names List containing second-level labels that may correspond to documented names, trademarks, or commonly used identifiers of persons or entities with a documented connection to the MetaMask ecosystem. Registry Operator shall independently establish and administer the Reserved Names List under this policy. Registry Operator shall create the initial Reserved Names List no later than commencement of the first registration period for the TLD. An addition to the Reserved Names List shall apply prospectively and shall not affect a Registered Name created before the addition unless required by applicable ICANN policy, an applicable dispute-resolution proceeding, court order, or agreement with the Registered Name Holder.
1. Draft the Community Registration Policy as proposed contract language. Policies that are approved by ICANN will be included in Specification 12 of the applicable Registry Agreement and will be subject to enforcement by ICANN Contractual Compliance. See Appendix 4 Base Registry Agreement, Specification 12 for drafting approach. Consider the usage of defined terms and the definitions of such terms in the 2026 Round Base RA. 2. Enter a single proposed Community Registration Policy in each response field. Up to 10 Community Registration Policies can be submitted. 3. Follow the format to propose what the Registry Operator must do and/or must not do: a) “Registry Operator shall___”; and/or b) “Registry Operator shall not___”. 4. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars: a) ""Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or b) ""Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”. 5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements: a) ""Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring___""; and/or b) ""Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting___"". 6. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example: a) Registry Operator shall develop and implement a Community Registration policy and publish this policy on its website no later than the date on which the TLD is delegated in the DNS. b) Registry Operator shall review the Community Registration Policy described in (a) at least once per year, and publish the results of such review (including any updates to the registration policy) on its website within thirty (30) days following the anniversary of the Effective Date. 7. If the Community Registration Policy is limited in time, duration, scope, or any other factors, specify the applicable limitations. For example, if a commitment is time-limited, the applying entity must state if the rule will apply for the lifetime of the gTLD, only during a specified period, or for some other defined period (such as, Registry Operator shall, for a period of x days from the Effective Date, ___). 8. See Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria for evaluation criteria that ICANN will apply for evaluating each proposed Community Registration Policy.
Registry Operator shall maintain a process through which a registrant or prospective registrant may request review of an adverse determination made under the .mask registrant eligibility or name-selection policies. Registry Operator shall permit a request for review to be submitted within seven (7) days after notice of the adverse determination and shall provide the requesting party with a written decision within thirty (30) days after receiving the request. Registry Operator shall publish the review process on its website no later than commencement of General Availability. Registry Operator shall independently establish, following appropriate consultation with MetaMask community participants, a Reserved Names List and policy for community-priority names that may be allocated to qualified community members. Registry Operator shall publish the applicable qualifications, allocation method, and priority period on its website before the period begins. Registry Operator shall hold one or more Limited Registration Periods before General Availability, with eligibility restricted to qualified MetaMask community members. Registry Operator shall publish the applicable qualifications and launch dates on its website before each period begins.
1. If you are proposing any limitation to a proposed Community Registration Policy in Questions 151-153, please provide a rationale in this response field. Please see Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria. 2. If you are not proposing any limitation to a proposed Community Registration Policy in Questions 151-153, please type ""Not Applicable"" in this response field.
The proposed Community Registration Policies contain limited temporal and scope qualifications, each tailored to the purpose of the applicable policy. Q151 evaluates community eligibility at initial registration rather than at each renewal. This permits a Registered Name to remain a stable Internet identifier after a registrant establishes a qualifying connection to the community, even if the particular form of participation later changes. The 90-day intent pathway allows a good-faith new participant to obtain an identity for an activity it is preparing to undertake within the MetaMask ecosystem. The 36-month period for grant-based eligibility ensures that a grant used as evidence reflects a reasonably current community connection. The trademark-holder exception is limited to registration of the holder’s trademark and supports a safe and reputable namespace without creating a broader exception to community eligibility. Under Q152, an addition to the Reserved Names List applies prospectively. This protects the reasonable expectations of an existing Registered Name Holder and avoids retroactively impairing a registration that was permitted when created. The written-authorization exception permits Registry Operator to authorize an otherwise reserved registration when appropriate. Under Q153, the seven-day period for requesting review promotes prompt resolution of adverse determinations, while the 30-day decision period provides sufficient time to evaluate the request and issue a reasoned written decision. Community-priority allocation periods and Limited Registration Periods are time-limited because they serve launch and priority-allocation purposes before the ordinary registration process applies. Except for these expressly identified temporal and scope qualifications, the proposed Community Registration Policies are not time-limited and are intended to apply throughout the term of the Registry Agreement.
1. Provide an explanation of how the proposed Community Registration Policies meet the Registry Commitments Evaluation criteria 4 and 5 using the considerations in the Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria. 2. Consider whether the proposed Community Registration Policy could be argued to be duplicative of a requirement under applicable law, ICANN agreements, or ICANN Consensus Policies or Temporary Policies. There may be circumstances in which a Community Registration Policy that would duplicate requirements under applicable consensus policy or law could be approved at ICANN’s sole discretion. If not duplicative, please explain why you believe the Community Registration Policy is not duplicative. If yes, please specify such a requirement and explain why you believe duplication in the Base RA is necessary. 3. Consider whether the proposed Community Registration Policy could be argued to be contrary to a requirement under applicable law, ICANN agreements, or ICANN Consensus Policies or Temporary Policies. ICANN will not approve any Community Registration Policies that are found to be contrary to applicable laws, ICANN agreements and policies. Please share your views on this issue in the answer to this question. 4. Consider whether the proposed Community Registration Policy could be argued to be incompatible with ICANN’s Bylaws. ICANN will not approve any Community Registration Policies that are found to be incompatible with the ICANN Bylaws. See background at the ICANN Board resolution 2024.06.08.08-2024.06.08.10. Please share your views on this issue in the answer to this question. 5. Consider whether the proposed Community Registration Policy requires the operation of an additional Registry Service. The applying entity shall engage its selected RSP to discuss the implementation of such an additional Registry Service, which must be evaluated through the RSP Program and approved by ICANN.
CRITERION 4: DUPLICATION AND CONTRARY REQUIREMENTS. The proposed Community Registration Policies do not duplicate, and are not contrary to, requirements under applicable law, the Base Registry Agreement, ICANN Consensus Policies, or ICANN Temporary Policies. Q151 establishes a .mask-specific eligibility framework based on participation or affiliation with the MetaMask ecosystem, evidence of community participation, promotion of the ecosystem, or an intent to participate within 90 days. No applicable law or ICANN requirement establishes or administers these community-specific eligibility conditions. The limited trademark-holder exception is an eligibility provision and does not replace or duplicate the Trademark Clearinghouse, Sunrise, Trademark Claims, UDRP, URS, or any other applicable rights-protection mechanism. Q152 establishes a .mask-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 MetaMask ecosystem. The policy supplements those requirements without replacing or limiting them. Q153 establishes an internal review procedure for determinations made under the .mask 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 MetaMask community. These processes operate subject to, and do not limit, any rights or remedies available under applicable law, the Registry Agreement, or ICANN policies. Nothing in Q151-Q153 authorizes conduct prohibited by, excuses compliance with, or alters any obligation imposed by applicable law, the Registry Agreement, an ICANN Consensus Policy, or an ICANN Temporary Policy. CRITERION 5: ICANN BYLAWS COMPATIBILITY. The proposed policies concern who may register a .mask 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 .mask TLD. The policies do not restrict or require evaluation of website content, communications, applications, products, or services. References to MetaMask clients, accounts, developer integrations, Snaps, repositories, and programs are used solely to identify evidence of community participation. The policies do not require DNS resolution through MetaMask or a blockchain, create interoperability with an on-chain identifier, or establish an alternative naming root. ADDITIONAL REGISTRY SERVICE CONSIDERATIONS. Registry Operator is coordinating implementation with its selected Registry Service Provider. The policies can be implemented through ordinary registration, reservation, verification, and launch workflows. Eligibility may be evaluated using client-initiated cryptographic proof, public software or program records, or documentary evidence without altering DNS, DNSSEC, EPP, RDDS, or data-escrow services and without providing a wallet-based or on-chain resolution service. On the proposed implementation, the policies do not require an additional Registry Service. If ICANN or the selected Registry Service Provider determines that a particular implementation would constitute an additional Registry Service, Registry Operator shall complete the required RSP Program evaluation and obtain ICANN approval before offering that service.
Community Endorsement
Please provide evidence of support for the applying entity’s application by attaching written endorsements from the organizing bodies relevant to the identified community (related to Question 136).
Mask Naming Limited has written support from Consensys, the principal organizing and stewardship institution for the MetaMask ecosystem, and from organizations serving important functional segments of the identified community: Mastercard, Aave Labs, and Blockaid. CONSENSYS. Consensys provides the primary institutional endorsement. As described in Q136, Consensys supports the MetaMask ecosystem through product and developer infrastructure, open-source software, documentation, education, grants, events, security initiatives, community growth, and strategic partnerships. Its letter identifies Consensys as the primary stewardship organization for the MetaMask ecosystem and describes its responsibility for advancing the interests of the ecosystem as a whole. Consensys evaluated the proposed .mask initiative, Mask Naming’s structure, the relevant ICANN and domain-industry experience supporting the application, the intended use of Identity Digital as Registry Services Provider, and the proposed community registration framework. Following that review, Consensys formally endorsed Mask Naming as the appropriate applicant and ICANN operating partner for the MetaMask community. Its letter recognizes .mask as the community’s natural DNS representation, supports operation of the TLD for the community, and urges ICANN to approve the application. MASTERCARD. Mastercard supports the application from its role as a MetaMask Card partner connecting self-custodial wallet users with established global payment infrastructure. Its letter identifies Mask Naming and the proposed .mask community gTLD, supports Consensys’s endorsement, and describes the potential for .mask to provide trusted identities and improve recognition and discoverability for MetaMask users and ecosystem participants. AAVE LABS. Aave Labs supports the application from its role as the contributor supporting a major decentralized-finance protocol accessed by many users through MetaMask. Its letter identifies the relationship between MetaMask users and decentralized applications, supports Mask Naming’s application, and recognizes the value of a trusted DNS namespace for applications, builders, and users participating in the ecosystem. BLOCKAID. Blockaid supports the application from its role as a security provider whose technology is integrated into the MetaMask environment to protect users from scams, phishing, malicious applications, and harmful transactions. Its letter identifies Mask Naming, supports the .mask application, and recognizes the value of a trusted namespace operated with appropriate security and abuse-prevention controls. BREADTH AND NATURE OF SUPPORT. The MetaMask community is organized functionally rather than through a single membership association. Consensys therefore provides the principal ecosystem-wide endorsement, while Mastercard, Aave Labs, and Blockaid corroborate support from payments, application access, decentralized finance, and security functions. Each letter specifically supports Mask Naming; none is merely a general endorsement of the string or a statement that any applicant should operate .mask. Mask Naming is not owned or controlled by Consensys, Mastercard, Aave Labs, or Blockaid. Their endorsements do not confer registry ownership, governance rights, or authority to direct, approve, or veto registry decisions. Mask Naming independently retains sole responsibility for the application and, if .mask is delegated, ultimate responsibility for registry governance, policies, operations, security, and compliance with the ICANN Registry Agreement. The letters demonstrate that the community’s principal stewardship institution and organizations serving important community functions support Mask Naming in undertaking that independent ICANN and registry role.
Provide an explanation of why opposition may or may not be relevant or how the applying entity intends to address or resolve the opposition, if applicable.
No. As of the date of submission, Mask Naming Limited is not aware of any opposition to the applying entity, this application, or the applied-for .mask string. No person, organization, or Mask community entity has communicated opposition to Mask Naming Limited. Accordingly, there is no known opposition to assess or address.
Section: Safeguard Identification
This question set collects information related to determining whether certain Safeguard Public Interest Commitments (Safeguard PICs) are required for the applied-for gTLD string. See Section 7.8.2.3 Safeguard PICs. Answers to these questions will inform assessment by ICANN on whether and which Safeguard PICs must be incorporated in the applicable Registry Agreement (RA) if the string proceeds to delegation. The answers themselves will not automatically make such a determination.
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. I-2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. I-2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
Select Yes or No. Notes: 1. ICANN will evaluate whether an applied-for gTLD string requires one or more Safeguard Public Interest Commitments (Safeguard PICs) to be included in the Base RA). 2. In addition to the Mandatory Public Interest Commitments (PICs) that must be included in each Base RA, a subset of Base RAs must include Safeguard PICs based on ICANN’s Safeguard Assessment. See Section 7.8.2.3 Safeguard PICs. 3. Applying entities for TLDs that are not found to require Safeguard PICs can elect to add them to the applicable Base RAs voluntarily to, for example, further their business objectives, help address issues or concerns that are raised or could be raised with respect to their applications, or avoid the need for the evaluation and implementation of customized Registry Voluntary Commitment (RVC). See Section 7.8.3 Registry Voluntary Commitments (RVCs).
No
Section: Registry Voluntary Commitments (RVCs)
This question set collects information related to any Registry Voluntary Commitments (RVCs) that the applying entity is submitting. The decision to submit an RVC is typically voluntary, except for those recognized by ICANN to resolve an objection or to address GAC Consensus Advice. See Section 7.8.3 Registry Voluntary Commitments for more information.
1. Select Yes or No. 2. In addition to Safeguard Public Interest Commitments (PICs), an applying entity will be permitted to propose one or more Registry Voluntary Commitments (RVCs) to provide additional safeguards with regard to the registry operator’s operation of an applied-for gTLD string. See Section 7.8.3 Registry Voluntary Commitments (RVCs). 3. RVCs are separate from Community Registration Policies. See Section 7.8.3 Registry Voluntary Commitments (RVCs) and Section 7.8.4 Community Registration Policies for more information. If you are applying for a Community gTLD, please submit the Community Registration Policies by answering Questions 150-155. However, if you propose to include additional Registry Voluntary Commitments in the RA beyond the Community Registration Policies, you may answer "yes" and proceed to answer the following questions. 4. You are encouraged to consider whether there are other means, separate from including commitment(s) in the Base RA, that could be used to further your business objectives or help resolve any anticipated or actual issue(s) raised regarding the applied-for gTLD string or application. See Section 7.8.3 Registry Voluntary Commitments (RVCs). Notes: If you select “yes” to this question, you are required to pay the conditional Registry Commitments Evaluation fee, and commitments that are approved by ICANN will be included in Specification 11 of the applicable Base RA as specific voluntary public interest commitments as contractual obligations.
No
Section: Brand & Code of Conduct Exemptions
This question set collects information related to whether the applied-for gTLD string is a .Brand (see Section 7.3) or if the applying entity is seeking a Code of Conduct exemption (see Section 7.4).
Select Yes or No
No
This serves as an indication of intent to apply for an exemption to Specification 9 and that the applying entity is NOT requesting to be designated a .Brand TLD, pursuant to Specification 13.
No
Section: Additional Information and Supporting Materials
This question set collects any additional information that the applying entity would like to provide, including any supporting materials.
Section: Bona Fide Intent and Prohibited Communications
This question set contains attestations related to the applying entity’s acknowledgment of bona fide intent and prohibited communications.
Confirm the statement using the checkbox.
true
Confirm the statement using the checkbox.
true