Frontmatter
hsp: 028
title: Establish House of Stake as Registrar for the NEAR Top-Level Account Namespace
description: Establishes the NEAR TLA namespace root under House of Stake governance on behalf of NEAR tokenholders and appoints the Security Council as Registrar.
author: @Ozymandius @Filmer @AK_HoG
discussions-to: https://houseofstake.org/proposals/28
status: Final
type: Supermajority
created: 2026-08-25
Track: Decision
Category: Technical Governance, Legitimacy & Engagement
Stakeholders: NEAR Tokenholders, House of Stake Foundation, House of Stake Security Council, nearaccounts.com Platform Operator, Users
Created: TBD
1. Abstract
With the launch of nearaccounts.com, NEAR Top-Level Accounts (“TLAs”) will open for broader use, enabling new namespace economies to develop beneath them.
As TLAs may become an important asset of the NEAR ecosystem, the exceptional authority to create Top-Level Accounts requires a durable and credibly neutral governance model. In particular, this authority should be separated from the commercial platform operations built on top of the namespace.
This proposal establishes that NEAR’s top-level namespace root should be governed by NEAR Tokenholders. To implement this principle, it places governance of the top-level namespace within NEAR House of Stake (“HoS”) and appoints the House of Stake Security Council as Registrar (“Registrar”), authorized to perform Registrar Actions in accordance with the House of Stake Constitutional Documents, and the Registrar Charter in Appendix A (“Registrar Charter”).
nearaccounts.com (“Platform Operator”) will operate as a dedicated NEAR product, with its product team responsible for commercial and operational decisions. The team works closely with NEAR AI, NEAR.com, NEAR Intents, and other ecosystem stakeholders to develop the TLA namespace as shared infrastructure supporting NEAR’s broader ecosystem and economic success.
Once a TLA or sub-account is created, its authorization and use remain outside the Registrar’s control. The applicable on-chain authorization mechanisms determine who may act through the account. Users retain full control over the accounts they lease and the assets held within them for the duration of their lease, neither HoS nor the nearaccounts.com product team has any mechanism to redirect, freeze, or take custody of those assets.
2. Payload
The House of Stake approves the following decisions:
- Establish House of Stake as the governance authority for the NEAR Top-Level Account namespace root and designate the House of Stake Security Council as Registrar for the NEAR Top-Level Account namespace.
- Adopt the NEAR Top-Level Namespace Registrar Charter in Appendix A, defining the permitted Registrar Actions and the Registrar’s rights, duties, limitations, and safeguards.
- Confirm the required signing authority changes under which the House of Stake Security Council will assume control of NEAR’s Top-Level Account namespace root.
- Recognize the expanded House of Stake Mandate described in NEAR Foundation’s mandate update (Aug 2026).
- Authorize and direct the House of Stake Foundation to take the corporate, administrative, technical, and other implementation actions necessary to give effect to the decisions approved by this proposal.
3. Context and Problem
NEAR accounts are hierarchical by design. A Top-Level Account (“TLA”) can serve as the root for potentially large numbers of subaccounts and the economic activity built around them. TLAs have been a design feature of NEAR since day one, but their potential as an ecosystem-wide namespace layer has remained largely unleveraged.
Examples: Top-Level Accounts and Subaccounts
For example, the Top-Level Account:
agent
may be used to create subaccounts such as:
alice.agent
bob.agent
wallet.agent
This capability will soon become broadly accessible through nearaccounts.com, allowing TLAs to be opened and used as namespaces by projects, businesses, communities, and other participants.
The exceptional authority to create TLA’s requires a durable governance model. At the same time, operating a successful namespace platform requires the ability to make product and commercial decisions efficiently.
This proposal therefore separates two fundamentally different responsibilities to balance the long-term interests of NEAR stakeholders:
- Protocol governance should control the exceptional authority to create Top-Level Accounts and ensure that this authority is exercised in the interests of the NEAR Protocol and NEAR’s broader ecosystem, and in accordance with the House of Stake constitutional framework.
- Product operation should retain the freedom to make decisions on namespace allocation, pricing, marketplace rules, recovery, customer experience, and business models, enabling the platform to evolve and contribute to the commercial success of the NEAR ecosystem.
4. Approach
4.1 House of Stake as Protocol Registrar
House of Stake provides the governance framework for NEAR’s protocol-level Registrar function, with the House of Stake Security Council serving as Registrar. The authority to perform Registrar Actions is established through this proposal.
The Registrar account shall be operated by the House of Stake Security Council through the applicable multisig or threshold-signing arrangement.
This proposal does not restructure HoS governance. It is an extension of HoS’s substantive mandate, using an already-existing on-chain execution body to perform a narrowly defined technical function.
The Security Council members remain bound by the applicable House of Stake Constitutional Documents, Foundation Legal Documents, the NEAR Top-Level Namespace Registrar Charter (Appendix A), and conflict-of-interest requirements.
The Security Council does not gain independent discretion over namespace allocation. Its role is to execute valid Top-Level Account creation instructions issued by nearaccounts.com through the approved process.
4.2 Protocol Implementation
No NEAR protocol change is required. The NEAR protocol designates a single account, registrar, as the only account able to create named Top-Level Accounts, and this restriction applies at every name length.
That account already operates a multisig contract. Implementation is therefore a change of membership rather than a rotation of keys. The House of Stake Registrar multisig is added as a member, the incumbent members are removed, the confirmation threshold is set to the value House of Stake adopts, and the FullAccess keys presently on the account are deleted.
The multisig’s membership model accepts an account as a member, so the Security Council can be added directly and confirm through its own governance process. No individual signer keys are placed on the Registrar account and no contract change is required.
Following tokenholder approval of this proposal, execution requires coordination with the parties currently authorized to administer the Registrar account and any necessary security review.
4.3 Scope of Registrar Authority
Under this proposal, the principal permitted Registrar Action is the creation of a valid bare Top-Level Account in response to a valid creation instruction.
For example, the Registrar may create:
universe
ai
intents
Once universe exists, accounts such as alice.universe are created and managed without further involvement of the protocol Registrar.
Creating a TLA does not give House of Stake or the Security Council any authorization to act through, administer, or access the created TLA.
The Registrar therefore has no authority over:
- subaccount leasing or administration;
- registry records or NFT-based rights and entitlements;
- leases or marketplace transfers;
- recovery;
- pricing or commercial terms;
- business namespace administration;
- customer relationships; or
- user assets.
4.4 Platform Operator and the TLA Platform
The Platform Operator funds, develops, and operates nearaccounts.com through its product team.
This includes determining the platform’s product and commercial model, including allocation and eligibility rules, pricing and fees, marketplace functionality, recovery mechanisms, customer relationships, and business namespace products.
These activities are independent of the Registrar function. HoS and the Security Council have no authority over the commercial or operational management of nearaccounts.com.
4.5 Allocation and Registrar Execution
nearaccounts.com determines when a namespace has completed the applicable process for creation.
This process may include submission, classification, publication, challenge, allocation, payment, compliance, or other operational requirements.
Once the process produces a valid creation instruction, the Security Council may perform the corresponding Registrar Action to create the Top-Level Account.
The Registrar verifies that the instruction satisfies the requirements established by the Registrar Charter but does not reconsider the underlying commercial or allocation decision.
4.6 Registry and NFT-Based Ownership
At nearaccounts.com, the registry serves as the on-chain system of record for namespace registration, lease rights, and lifecycle information.
Leased names are represented as NFTs, with each token corresponding to a specific account name and the associated rights defined by the applicable platform contracts. The underlying accounts operate as keyless contract accounts. Each account authorizes actions against its own on-chain control set, which may be updated in response to applicable registry lifecycle events.
This architecture allows lease transfers, marketplace transactions, wallet authorization, and recovery to occur without the Registrar or Platform Operator taking custody of account keys or assets. Authorization to act through an account is determined by its applicable on-chain authorization mechanisms.
The architecture described in this section reflects the TLA Platform implementation as of the date of this proposal. It does not establish a governance requirement for the Platform Operator to maintain any particular registry, lease, account-authorization, or control-set architecture. The Platform Operator may modify, replace, or discontinue these mechanisms without a House of Stake Tokenholder vote, provided such changes do not expand the Registrar’s authority or otherwise modify the governance boundaries established by this proposal and the Registrar Charter.
4.7 Revenues
The Registrar is not a commercial operator.
Revenues may arise from platform activities such as allocation, leases, renewals, marketplace activity, or business namespace services and may be collected and retained by the Platform Operator.
5. End-to-End Value Hypothesis
Objective:
Put ultimate governance of the TLA namespace root in the hands of NEAR tokenholders while preserving Platform Operators’s ability to operate nearaccounts.com efficiently.
Expected outcome:
NEAR can open meaningful bare Top-Level Accounts through a credibly neutral Registrar governed by House of Stake, while nearaccounts.com can be developed with flexibility to achieve product-market-fit.
Dependencies:
Required NEAR Namespace Root Multisig Update executed; production-ready Registrar infrastructure; Security Council procedures; production-ready TLA platform and contracts; security review and smart contract audits; and applicable House of Stake legal implementation.
6. Key Performance Indicators
The proposal is successfully implemented when:
- the TLA root is placed within the approved HoS governance structure;
- the Security Council can perform the Registrar functions in Appendix A;
- HoS and the Security Council cannot control users’ virtual assets; and
- Registrar activities are verifiable onchain.
Commercial product KPIs may be set and adjusted by the nearaccounts.com team independently.
7. Technical Specification
The technical architecture described below reflects the current implementation of the TLA Platform and is provided for explanatory purposes. Except for the protocol Registrar and the governance boundaries applicable to it, these technical components do not form part of the governance framework approved by this proposal. The Platform Operator may modify or replace the Platform architecture without a House of Stake Tokenholder Vote.
The architecture contains distinct authority layers:
- Protocol Registrar:
The account designated as registrar_account_id can create bare Top-Level Accounts and is operated by the House of Stake Security Council. (Note: The platform contract repository also contains a contract that creates subaccounts beneath a Top-Level Account. It is a platform component, unrelated to the protocol Registrar described here.) - Top-Level Account:
Each created TLA is an independent NEAR account and structural namespace root. - Registry:
A central registry contract records namespace registration, lease rights, and lifecycle information used by the TLA platform. - Leased Accounts:
Subaccounts may operate as keyless contract accounts associated with NFTs recorded through the registry. Each account determines authorization against its applicable on-chain control set. - Lease Authority:
A separate platform extension may enforce lease lifecycle rules. It is not the protocol Registrar. - Recovery:
A separate MPC recovery system and watcher quorum may authorize recovery actions independently of the Registrar.
References
https://github.com/houseofstake/tla
https://github.com/houseofstake/tla-contracts
https://github.com/near/nearcore
8. Backwards Compatibility
This proposal does not transfer existing NEAR accounts, applications, or subaccounts to House of Stake and does not modify their existing authorization or access arrangements.
Existing arrangements remain unaffected unless separately modified through an applicable process.
9. Security Considerations
The protocol Registrar represents a high-impact authority because control of the Registrar account enables the creation of bare Top-Level Accounts.
The principal safeguards are:
- Constitutional authority. Registrar Actions are recognized as a defined Security Council authority under the House of Stake constitutional framework.
- Bounded Registrar Actions. The Registrar Charter defines which Registrar Actions are permitted and establishes their conditions, limitations, and safeguards.
- Threshold execution. Registrar Actions are performed through the Security Council’s applicable multisig or threshold-signing arrangements.
- Removal of standing key access. The Registrar account currently holds FullAccess keys in addition to its multisig members. A FullAccess key can create a Top-Level Account without any confirmation, so removing them is part of implementation rather than a hardening step that can follow it. Until they are removed, the threshold arrangement described above is not the only path to Top-Level Account creation.
- Separation of responsibilities. Allocation, platform operation, registry ownership, lease enforcement, account authorization, recovery, and Registrar execution remain separate authority domains.
- No account or asset custody. Performing a Registrar Action to create a TLA does not grant the Registrar authorization to act through or administer the created TLA and does not provide access to assets held within it.
- Transparency. Registrar Actions should be publicly auditable against their corresponding authorization and creation instructions.
- Detailed signing, access-control, and operational procedures are defined through the Registrar Charter and applicable Security Council procedures.
10. Stakeholders / RACI
| Activity | Responsible (R) | Accountable (A) | Consulted (C) | Informed (I) |
|---|---|---|---|---|
| Operate TLA Platform, including e.g. recovery services | Platform Operator | Platform Operator | Namespace Holders | Tokenholders, HoS Foundation Directors |
| Define roadmap, business model and pricing, business terms and customer policies | Platform Operator | Platform Operator | Namespace Holders | Tokenholders, HoS Foundation |
| Manage customer support | Platform Operator | Platform Operator | Namespace Holders | Tokenholders, HoS Foundation |
| Operate the protocol Registrar account through the approved threshold configuration | HoS Security Council (Registrar) | House of Stake Foundation Directors | Platform Operator | Tokenholders |
| Approve creation of new Top-Level Accounts | Platform Operator | Platform Operator | HoS Security Council (Registrar) | Tokenholders |
| Create Top-Level Accounts on-chain, perform authorized Registrar Actions | HoS Security Council (Registrar) | House of Stake Foundation Directors | Platform Operator | Tokenholders |
| Create and administer subaccounts | Namespace Holder | Namespace Holder | Platform Operator | Tokenholders |
| Govern the Registrar Charter, definition of permitted Registrar Actions | Tokenholders | Tokenholders | HoS Security Council (Registrar), Platform Operator | House of Stake Foundation |
RACI Legend: Responsible (R): Performs the activity. Accountable (A): Ultimately accountable for the outcome and decision. Consulted (C): Provides input before decisions or execution. Informed (I): Kept informed of the activity or outcome.
11. Implementation Plan
Implementation consists of three workstreams.
House of Stake
- Adopt this proposal and the NEAR Namespace Registrar Charter.
- Complete any required mandate, legal, Security Council, and operating-procedure changes.
NEAR Protocol
- Add the House of Stake Registrar multisig as a member of the Registrar multisig, and confirm it can execute a request before relying on it.
- Remove the incumbent members and set the confirmation threshold adopted by House of Stake.
- Delete the FullAccess keys currently held on the Registrar account.
- Perform these steps in that order. The FullAccess keys are removed only after the new Registrar configuration has been successfully verified, reducing the risk of losing administrative access during the transition.
TLA Platform
- Complete production deployment and security audits of the platform and related contracts.
- Connect the namespace allocation workflow to Registrar execution.
- Launch the applicable namespace products and reporting.
12. Milestones
| Milestone | Timeline | Success Criteria |
|---|---|---|
| Mandate Updated, Proposal Ratified | Early September 2026 | House of Stake adopts the proposal and Registrar Charter |
| Registrar Charter Implementation Complete | After proposal approved | Registrar Charter Implementation Complete |
| NEAR Namespace Root Multisig Update Executed | After Registrar Charter implementation | House of Stake Registrar multisig added as a member of the Registrar multisig and proven able to execute a request; incumbent members removed; confirmation threshold set to the adopted value; all pre-existing FullAccess keys deleted, leaving only the approved threshold configuration. |
| Registrar Rehearsed | After namespace root multisig update executed | Security Council executes at least one end-to-end creation request against testnet (or an equivalent dry run) using the approved confirmation process before acting on mainnet |
| TLA Platform Security Audit Complete | Independent of the Registrar workstream; before TLA Platform Launch | Independent security audit of tla-contracts completed and material findings resolved, covering the subaccount minting contract, tla-registry, hos-wallet, hos-extension, mpc-recovery, wallet-impl-deployer, etc. |
| TLA Platform Launch (Mainnet) | After audit completion | Namespace allocation and creation workflow deployed and operational on NEAR mainnet |
| Registrar Operational | After both Registrar Rehearsed and TLA Platform Launch | Security Council execution infrastructure live and able to receive valid creation requests from the launched platform |
| First Bare TLA Created | After Registrar Operational | First TLA created through the approved process on mainnet |
| Reporting Operational | Concurrent with first bare TLA creation | Registrar actions and applicable revenues publicly reviewable on-chain |
13. Budget & Resources
Not applicable.
No standalone budget is requested. Should any House of Stake operational expenditure be required to perform the Registrar function in the future, this remains subject to the applicable budgeting and proposal procedures.
14. Governance Framework Lifetime
This Governance Framework takes effect upon ratification and remains in force indefinitely unless amended, superseded, or terminated through the applicable House of Stake governance process.
The Platform Operator may modify the technical architecture, product design, operational processes, commercial model, allocation mechanisms, registry, leasing model, account-authorization mechanisms, recovery mechanisms, or other Platform components without a House of Stake Tokenholder Vote. Such changes do not amend or terminate this Governance Framework, provided they do not expand the Registrar’s authority or otherwise modify the governance boundaries established by this proposal and the Registrar Charter.
15. Conflict of Interest
The proposal authors confirm that they have read and agree with the House of Stake Conflict of Interest Policy. The proposal authors confirm to not gain benefits from a decision on this proposal that are not proportionally available to other NEAR Stakeholders.
The Registrar shall not use its role to influence TLA allocation, pricing, commercial terms, or other decisions reserved to the Platform Operator.
Any additional actual or potential conflicts shall be disclosed under the applicable House of Stake Conflict of Interest Policy.
16. Copyright
This proposal is licensed under CC0 1.0 Universal.
Appendices
Appendix A — NEAR Top-Level Namespace Registrar Charter
Appendix B — Governance and Implementation References
Appendix A — NEAR Top-Level Namespace Registrar Charter
A.1 Purpose
This NEAR Top-Level Namespace Registrar Charter (“Registrar Charter”) defines the authority, duties, and limitations of the NEAR Top-Level Account Registrar (“Registrar”) within the governance framework of NEAR House of Stake (“HoS”).
The House of Stake Security Council (“Security Council”) acts as Registrar and is authorized to perform Registrar Actions in accordance with this Registrar Charter and the House of Stake Constitutional Documents.
The Registrar is an execution function. It administers NEAR’s protocol-level authority to create Top-Level Accounts (“TLAs”) but does not operate the TLA platform or govern individual namespaces after their creation.
A.2 Governance and Accountability
The Registrar operates under the authority of NEAR Tokenholders through House of Stake.
The Security Council shall perform Registrar Actions in accordance with:
- the approved House of Stake proposal establishing the Registrar;
- this Registrar Charter;
- the House of Stake Mandate;
- the House of Stake Constitutional Documents;
- applicable Foundation Legal Documents; and
- valid governance decisions adopted under those documents.
Security Council members obtain no independent authority over the NEAR top-level namespace by virtue of acting as Registrar or being signers of the Registrar account.
A.3 Registrar Actions
A Registrar Action is an on-chain action performed or caused to be performed by the Registrar within the authority granted under this Registrar Charter.
The Registrar may perform only the following Registrar Actions:
A.3.1 Create Top-Level Accounts
Create previously non-existent bare TLAs on the NEAR Protocol where creation has been properly authorized under the applicable TLA governance and operational processes.
For example, the Registrar may create:
universe
which can subsequently serve as the root for accounts such as:
alice.universe
bob.universe
The Registrar’s authority over a TLA ends once the TLA has been successfully created, except for Registrar Actions strictly necessary to complete or verify that creation.
Creation of a TLA does not grant the Registrar, HoS, or the Security Council authorization to act through, administer, or access the created TLA or assets held within it.
A.3.2 Administer the TLA Root
Perform the root-level actions necessary to bring a newly created TLA into service and to maintain the Registrar account itself, limited to:
a) funding a newly created TLA with the storage balance required for it to operate;
b) setting the access key configuration of a TLA at or immediately after creation, so the account is left in its intended state;
c) any action strictly necessary to complete or verify a creation under A.3.1; and
d) maintaining the Registrar account’s own membership, balance and configuration.
This section confers no authority over a TLA once it has been brought into service, and no authority over accounts created beneath it.
A.3.3 Execute Valid TLA Creation Instructions
Where an approved platform process results in a TLA creation instruction requiring a Registrar Action, the Registrar may execute or cause that Registrar Action to be executed.
The Registrar shall execute the instruction where:
- the requested action falls within the Registrar’s authority under this Registrar Charter;
- the applicable process and technical conditions have been satisfied; and
- execution would not violate this Registrar Charter, applicable HoS governance, or applicable law.
The Security Council applies these criteria in determining whether to execute the requested Registrar Action. This determination need not be automated or enforced by smart contracts.
The Registrar does not assess or reconsider the commercial merits of the underlying platform decision.
A.3.4 Protective Registrar Actions
The Registrar may suspend, delay, or take other root-level Registrar Actions reasonably necessary to respond to:
- compromise or suspected compromise of Registrar authority;
- a critical protocol or contract vulnerability;
- malformed, fraudulent, or unauthorized creation instructions;
- an active exploit or material security incident; or
- another circumstance in which execution would create an immediate and material risk to the NEAR Protocol or the Registrar.
Protective Registrar Actions may be used only to protect the integrity of the Registrar, the TLA root, or the NEAR Protocol. They shall not be used to override ordinary allocation decisions, commercial disagreements, or valid rights and authorizations established under the applicable platform and account mechanisms.
A.3.5 Registrar Infrastructure
The Registrar may maintain and upgrade technical infrastructure required to perform Registrar Actions, provided such changes do not materially expand the Registrar’s authority or alter the governance boundaries established by this Registrar Charter.
The Registrar may select, authorize, instruct, and monitor qualified technical experts or infrastructure to execute Registrar Actions on its behalf. Delegating technical execution does not transfer or reduce the Security Council’s responsibilities as Registrar.
Any change that would materially expand the Registrar’s authority, change who acts as Registrar, or alter the separation between the Registrar and TLA platform operation requires authorization through the applicable House of Stake governance process.
A.4 Registrar Duties
In performing Registrar Actions, the Security Council shall:
- act only within the authority granted by this Registrar Charter, and the applicable House of Stake Constitutional Documents and Foundation Legal Documents
- verify that the conditions applicable to a requested Registrar Action have been satisfied;
- safeguard the integrity and security of the Registrar and TLA root;
- maintain appropriate operational and security procedures;
- ensure that Registrar Actions can be publicly reconciled with the corresponding valid instructions; and
- report material incidents, rejected instructions, unauthorized attempts, or material deviations from normal operation in accordance with applicable House of Stake procedures.
A.5 Separation from TLA Platform Operations
nearaccounts.com and the associated TLA platform are operated as a NEAR product by the nearaccounts.com team (“Platform Operator”).
The Platform Operator is responsible for determining and implementing the platform’s product, technical, operational, and commercial policies, including, as applicable:
- namespace allocation processes and classes;
- eligibility and application requirements;
- pricing and fees;
- marketplace rules;
- leasing and renewal terms;
- business models and commercial terms;
- customer relationships;
- registry operations;
- account recovery mechanisms; and
- business namespace functionality.
The Platform Operator may determine and modify these policies, processes, and technical mechanisms without approval by the Registrar or a House of Stake Tokenholder Vote, provided such changes do not expand the Registrar’s authority or otherwise modify the governance boundaries established by this Registrar Charter.
The Registrar does not approve, supervise, or replace the Platform Operator in these functions.
Where an approved platform process results in a valid TLA creation instruction, the Registrar’s role is limited to determining whether the conditions for the corresponding Registrar Action have been satisfied and, if so, executing or causing the Registrar Action to be executed.
A.6 No Account Administration Authority
The Registrar has no authority over the ordinary operation of a TLA or accounts created beneath it.
In particular, the Registrar shall not:
- create or administer ordinary subaccounts on behalf of namespace holders;
- determine or modify the rights or authorizations associated with TLAs or subaccounts;
- hold or manage NFT ownership records on behalf of users;
- operate the TLA registry;
- control leased accounts;
- manage wallet authorization;
- approve marketplace transfers;
- administer account recovery;
- custody user assets; or
- interfere with the lawful operation of a namespace.
These functions are governed by the applicable nearaccounts.com smart contracts, platform rules, account holders, and the NEAR Protocol.
A.7 No Custody of Accounts or Assets
Performance of a Registrar Action does not grant the Registrar authorization to act through or administer individual TLAs, leased accounts, or subaccounts, and does not provide access to assets held within them.
Where nearaccounts.com uses keyless contract accounts, each account determines authorization against its applicable on-chain control set. Registry lifecycle events may cause that control set to be updated in accordance with the applicable platform contracts and authorization mechanisms.
Neither HoS nor the Security Council takes custody of user account keys or acquires access to user accounts or assets by acting as Registrar.
A.8 Neutrality
The Registrar shall remain neutral in performing Registrar Actions.
The Security Council shall not use its Registrar authority to:
- favor or disadvantage particular applicants;
- influence pricing or commercial terms;
- reserve names for its own benefit;
- influence marketplace activity;
- obtain preferential access to namespaces; or
- advance interests inconsistent with its obligations under House of Stake governance.
Any conflicts of interest shall be handled under the applicable House of Stake Conflict of Interest Policy.
A.9 Accountability and Transparency
The Security Council is accountable to House of Stake for its operation of the Registrar.
Registrar activity is subject to the transparency, conflicts, security, and accountability requirements applicable to the Security Council.
Material or repeated failure to comply with this Registrar Charter may result in governance action under the applicable House of Stake Constitutional Documents and Foundation Legal Documents.
A.10 Charter Amendments
This Registrar Charter may be amended only through the governance process applicable to the proposal under which it was adopted or another process authorized by the House of Stake Constitutional Documents.
No operational procedure, platform policy, technical implementation, or Security Council decision may override or expand the authority boundaries established by this Registrar Charter.
Appendix B – Governance and Implementation References
B.1 Purpose
This appendix identifies the governance and implementation documents that support implementation of this proposal.
B.2 House of Stake Mandate Update
In accordance with the House of Stake constitutional framework, the NEAR Foundation has the authority to define and update House of Stake’s mandate.
The NEAR Foundation must confirm an updated mandate reflecting House of Stake’s expanded responsibilities as Registrar of the NEAR Namespace.
The Mandate Update serves as explanatory documentation and provides the strategic context and governance rationale for this proposal. It does not amend or supersede the governance framework established by this proposal.
Our biweekly GM Community Call takes places tomorrow. We’ll be covering governance updates as well as go over the recently published 
Join us tomorrow August 27 4PM UTC
Link to the 
. i DMed it to Meteor and HOT teams on tg. Do you have Telegram or X i can DM you the google doc link as well.
