# Who gets a name under your TLD: writing an issuance policy
> The holder of a TLD decides every name beneath it. A short policy on who may ask, who approves, what is reserved and how a name is withdrawn.
Source: https://hush.partners/issuance-policy-for-names-under-a-tld
Category: Acquiring
Published by Hush Partners.
---
The moment you issue the first name under your TLD, you have made a governance decision. You have decided who may hold a name, what that name looks like, and what happens if the holder leaves. Most organizations make that decision without realizing it, and by the time the namespace is crowded the original reasoning is gone. A policy written before the first issuance costs little. Untangling a namespace built without one costs far more.
This article walks through an issuance policy section by section. Each section explains what the clause does and why it belongs in the document. By the end, you will have a structure you can adapt, a set of categories you can populate with your own names, and a set of questions you can put to your legal or IT lead before the policy goes to sign-off. The policy itself need not be long: two pages, clearly drafted, is enough.
A brief note on context. A Freename TLD exists as a token recorded onchain, and it sits in a wallet. Whoever holds that TLD is the only party able to issue names beneath it. The namespace also sits outside the ICANN system, so no ICANN policy decides who receives a name. The rules that govern issuance under `.yourbrand` are the rules you write, within the registry's terms. That makes the issuance policy the central governance document for the namespace.
## Why the first name sets the precedent
Governance documents are easy to dismiss as a later problem. The TLD has just been [transferred and activated](/post-transfer-activation); there are technical tasks to finish, internal announcements to make, a roadmap to build. Writing a policy feels like paperwork. It is not.
Every name you issue before a policy exists is a precedent. If you give `it.yourbrand` to the IT department without a documented process, the finance team will expect `finance.yourbrand` on the same terms. If you give `alex.yourbrand` to a senior employee, you will have difficulty refusing the same to others at the same level. If you give `agency.yourbrand` to a marketing partner, you will have difficulty explaining why a different partner did not receive one.
The policy does three things at once. It records the rules so that decisions can be made consistently. It assigns accountability so that no single person can issue names without a record. And it creates a basis for withdrawal: asking for a name back is an administrative step only when the conditions of its issue were written down and accepted. Without that, the request becomes a negotiation.
There is a further reason to settle the rules early. Your one certain lever is the decision to issue. What can be done to a name after it has been issued depends on the registry's terms and on where the name is held, so the conditions you attach at issuance carry most of the weight. A policy written afterwards can only document names that already exist.
Write the policy before the first name. If you are past that point, write it now and grandfather existing names into the appropriate categories with a note in the register.
## Purpose and scope of the policy
The opening section of the policy states what the document covers and what it does not.
**Purpose.** The policy governs the issuance, maintenance and withdrawal of names under the TLD. It applies to all names regardless of who holds them or what they resolve to. It does not govern the DNS, external domains or names on any other onchain namespace.
**Scope.** The policy covers every name directly under the TLD: names of the form `label.yourbrand`. Nothing deeper is in scope, and the simplest position is to say that the organization issues and recognizes names at that level only.
**Hierarchy.** State which document the policy sits under. In most organizations this is a digital asset policy or a brand governance policy. If neither exists, the issuance policy can stand alone, but it should state who owns it and what approval it received.
**Effective date and version.** A versioned policy with a clear effective date allows you to resolve disputes about what rules applied when a name was issued. Keep a version history even if the document never leaves a shared drive.
## Categories of names
The most useful thing a policy can do early is define a small set of named categories. Categories let you vary the approval threshold, the eligibility rules and the reservation logic by type of name without writing separate policies for each case. Five categories cover most situations.
| Category | What it covers | Examples |
|---|---|---|
| Functional | A service, system or endpoint | `docs.yourbrand`, `status.yourbrand` |
| Organizational | A team, division or location | `legal.yourbrand`, `press.yourbrand` |
| Personal | A name tied to one individual | `firstname.yourbrand` |
| Partner | A name for an external organization | `supplier.yourbrand` |
| Reserved | A name withheld from routine issuance | `admin.yourbrand`, `pay.yourbrand` |
A few notes on this table. The personal category is the most contentious and the most prone to scope creep: define it narrowly or omit it entirely if the TLD is not intended for individual use. The partner category requires a separate clause on the terms under which external parties hold names; that clause is covered later in this article. The reserved category is not an issuance category at all: it is a list of names that may not be requested through the ordinary route, and its rationale is covered below.
A name does not have to stay in one category forever. A functional name that is later decommissioned moves from active to withdrawn; a partner name can become an organizational name when a supplier is acquired. The register should record category changes.
If you are still planning how the TLD will be put to work, the [Launch Roadmap tool](/activation-roadmap) is a practical starting point for mapping categories to phases.
## Who may request and who approves
Each category needs a stated requester class and a stated approver. The policy should name a role, not a person, so that it survives personnel changes.
The table below is a working model. Adjust the approval thresholds to match your organization's governance structure.
| Category | Who may request | First approver | Second approver |
|---|---|---|---|
| Functional | IT lead or product owner | IT director | None required |
| Organizational | Department head | IT director | None required |
| Personal | Employee or HR | Line manager | IT director |
| Partner | Relationship owner | IT director | Legal counsel |
| Reserved | Not requestable | Highest sign-off | See next section |
Two approvers are worth requiring for partner names because those names extend the namespace to parties outside your control. Legal counsel should confirm that the partner agreement covers name use, liability and what happens on termination. Personal names take two approvers for a different reason: the line manager knows whether the person's role justifies a name, and the IT director knows whether the name fits the rules.
The approval process should be documented in a request form or a ticket system, not in email. Email is hard to audit, easy to lose and difficult to produce in a dispute. A simple form that captures the requested name, the category, the business justification, the intended destination of the name, and the approver sign-off is enough.
Approval flow for a new name
Request submittedThe requester completes the name request form, stating the proposed name, the category, the intended use and what the name will point to (a wallet address, a website or another endpoint).
Category confirmedThe IT director confirms which category the name falls into. If the category is unclear, legal counsel is consulted before approval proceeds.
Second approver notified where requiredFor partner names, the file moves to legal counsel for review of the partner agreement. For names that touch payments or AI agents, the same review applies.
Name issuedThe holder of the TLD issues the name onchain. The register is updated with the name, category, name-holder, date of issue, intended use and any review date.
Name-holder notifiedThe name-holder receives written confirmation of the name, the conditions under which it was issued, and the circumstances in which the organization will ask for it to be given up.
This flow works for a closed namespace where the holder decides every name one by one. A market TLD that offers names to the public is governed differently, closer to the model described for [operators of a market namespace](/operators).
## Reserved names and the case for high sign-off
Some names should never be issued under routine approval. The reserved category exists for names whose issuance could mislead users, create security risk, imply authority the holder does not intend to grant, or conflict with technical conventions.
The obvious candidates for reservation are names that carry inherent authority: `admin`, `administrator`, `hostmaster`, `postmaster`, `abuse`, `security`, `support`, `help`, `www`, `mail`, `api`, `pay`, `wallet`, `treasury`. Any user will read `pay.yourbrand` or `wallet.yourbrand` as a payment endpoint. Issuing it carelessly, or allowing it to go to a third party without rigorous review, creates real risk.
The reserved list should be as complete as you can make it and attached as a schedule to the policy. It is easier to remove a name from the reserved list, with appropriate sign-off, than to explain after the fact why a sensitive name was in circulation.
Names on the reserved list that the organization decides to activate should require the highest sign-off your governance structure provides: a named executive or a two-person approval. The policy should state this explicitly, for example: "Reserved names may only be activated by decision of one named role, countersigned by a second named role."
The reason for the higher threshold is the cost of an error. A mistaken organizational name is an inconvenience. A mistaken payment or security name can send money or trust to the wrong place, and because the certain control is at issuance, the review has to happen before the name exists.
For background on what a payment name does in practice, see how [payments to a name](/onchain-tld-payments) work.
## Naming rules: length, character set and refusals
The policy should state the technical and non-technical constraints on what a valid name looks like. This is not the place to be creative: a short, rule-based list is easier to apply consistently.
**Length.** The registry sets the technical limits on the length of a name, and the policy works inside them. Within those limits, decide whether you want a practical minimum. Very short names carry implicit authority: `it.yourbrand` or `hr.yourbrand` reads as a department, and should not go to an individual whose initials happen to match. A long name, on the other hand, is hard to type and easy to mistype, which matters most where the name receives payments.
**Character set.** A conservative default is unaccented letters, digits and hyphens, with no hyphen as the first or last character, which mirrors the convention familiar from DNS host names. Names that are purely numeric should be reserved unless there is a clear use case. If the organization operates in languages that use other scripts, state explicitly whether such names are permitted and, if so, in which scripts. Characters from different scripts can look alike, so a mixed-script name deserves a second look before approval.
**What is refused.** The policy should list categories of names the holder will not issue regardless of who requests them:
- Names identical or confusingly similar to a third-party trademark the organization does not hold, unless legal counsel confirms the use is acceptable.
- Names that contain personal data in a way that would create data protection obligations the organization has not addressed (a full legal name used as a label, for example).
- Names that are obscene, offensive or likely to cause reputational harm to the organization.
- Names that could suggest a function or authority the organization does not have (for example, names that resemble a government body or a financial regulator).
- Names that are identical to a name already in the register for a different name-holder.
The refusal list should also state who decides a refusal and what the appeal path is. A requester who believes their request was wrongly refused should have a route to a second review, but that route should not allow the second reviewer to override the technical or legal grounds for refusal without engaging the relevant adviser.
**Naming conventions.** The policy may recommend or require a naming convention by category: for example, organizational names should match the official short name of the department as recorded in the HR system. This reduces ambiguity and makes the register easier to audit.
## Withdrawal and reassignment of a name
This is the clause that most needs care, because it is the one the holder controls least. Issuing a name is the holder's decision alone. Whether the holder of a TLD can afterwards withdraw, change or reassign a name that has already been issued depends on the registry's terms, and you should read those terms with your counsel before you draft this section. Do not write a policy that assumes a technical power of recall you have not confirmed.
The practical consequence is that withdrawal is designed at issuance, not at the moment you need it. Three choices made when the name is issued decide how easy a later withdrawal will be.
**Where the name is held.** The simplest arrangement for internal names is that the organization keeps every name in a wallet it controls, and the team or person concerned only uses the name. Withdrawal is then an internal act: the organization changes what the name points to or stops using it. A name held in a wallet the organization does not control can only come back through the cooperation of whoever controls that wallet.
**What the name-holder accepted.** For any name held outside the organization's wallets, the conditions of issue should record the name-holder's obligation to stop using the name, clear what it points to and hand it back when one of the grounds below applies. For a partner, that obligation belongs in the partner agreement. The obligation is contractual, and how it can be enforced varies by country.
**What the register says.** A withdrawal is far easier to justify when the register shows the purpose the name was issued for and the grounds on which it could be recalled.
**Grounds for withdrawal.** The following are standard grounds:
- The business justification for the name no longer exists (the department has been closed, the product has been retired, the partner relationship has ended).
- The name-holder has left the organization or the partner organization and no successor has been designated.
- The name is being used for a purpose other than the one stated at issuance.
- The name was issued in error or in breach of the policy.
- Legal counsel has advised withdrawal to manage a trademark conflict or regulatory risk.
**Notice period.** For internal names, a short notice period is reasonable: enough time for the team to update links and inform users. For partner names, the notice period should match the contractual notice period in the partner agreement. Do not rely on a unilateral withdrawal right if the partner agreement does not include one.
**Reassignment.** State who decides what becomes of a withdrawn name: retired for good, placed on the reserved list, or given to a new name-holder, where the registry's terms allow it. Giving a name that pointed to one destination to a new name-holder without a transition period is a risk. People and systems that remember the old meaning of the name may still send messages or money to it. A quiet period before reuse, and none at all for names that received payments, is a sensible default.
**Record-keeping.** The register should record every withdrawal: the name, the date, the grounds, the approver and what became of the name afterwards.
## The register and periodic review
The register is the single source of truth for the namespace. It does not need to be complex. A spreadsheet or a shared document with version control is sufficient for most organizations.
At minimum, each entry in the register should record:
- The name (in full, including the TLD)
- The category
- The name-holder (role and, where relevant, individual)
- The wallet in which the name is held and who controls it
- The date of issue
- The intended use and what the name pointed to when issued
- Any review date
- The date and grounds of any withdrawal
**Periodic review.** The policy should specify a review cycle: annually for most organizations, more frequently if the namespace is growing quickly or if the TLD carries payment or AI agent functions. The review should check that every name in the register still has an active business justification, that the name-holder is still in the relevant role, that each name still points where the register says it does, and that no name has been used outside its stated purpose.
The review is also the moment to catch names that were issued informally before the policy existed and to bring them into the governed register. Grandfathered names should be treated as a separate group in the first review, with a deadline by which each must either be confirmed under the policy or put through the withdrawal process.
**Ownership of the register.** Assign a named role as register owner. In most organizations this is the IT director or a designated member of the IT team. The register owner is responsible for keeping the register current, running the periodic review, and producing the register on request for any internal audit or legal review.
## Names for third parties: partners, customers and members
The decision to issue names to parties outside the organization is the most consequential one the TLD holder makes. It extends the brand namespace to entities the organization does not control, and it creates obligations that survive the business relationship unless the policy addresses them.
**Partners.** A partner name should always be underpinned by a written agreement that covers at minimum: the permitted use of the name, a ban on passing the name to anyone else, the partner's obligation to give the name up when the relationship ends, and the partner's obligation to clear what the name points to at that moment. Legal counsel should review the agreement before the name is issued. The policy should state that no partner name may be issued without a signed agreement.
**Customers.** If the TLD is used to give customers a named identity under the brand (for example, a name that resolves to their wallet, or a profile identifier), the issuance terms should be incorporated into the customer agreement or terms of service. The policy should state the scope of permitted customer use, how long the customer may use the name, and what happens when the account closes. Be realistic about that last point: a name a customer holds in their own wallet is, in practice, theirs to keep using unless the registry's terms say otherwise.
**Members.** An organization that issues names to members of an association, network or community is running a small registry of its own. The same principles apply as for customers, with one addition: a member name carries a reputational signal, because a name under `.yourbrand` implies an association with the brand. The policy should define what a member name represents and what it does not, and the membership terms should give the organization grounds to ask for the name back if the member's conduct becomes incompatible with the brand.
**Names for AI agents.** A name can also identify a piece of software that acts for the organization or for a partner. The request form should record the system the name identifies and the human accountable for it. The page on [identities for AI agents under a TLD](/onchain-tld-ai-agents) covers how such names are used.
**Revenue from third-party names.** Freename operates a royalty program under which part of every registration fee paid for a name under a TLD goes to that TLD's holder. Up to half is the share the registry advertises, and what a given holder receives turns on the registry's current terms and on activation conditions. The income is not free of cost: a Freename TLD has no annual renewal fee, but taking part in the program carries an annual cost set by the registry, unless the TLD was registered under earlier terms that include the program for life. An organization that opens its TLD to registrations by others should factor both into the commercial model and say in the policy who accounts for the income. The [Subname Revenue Calculator](/subname-revenue-calculator) estimates revenue from names issued under a TLD.
**Third-party names and trademark risk.** Issuing a name to a third party does not move the question of trademark use away from the TLD holder. If the partner or customer uses the name in a way that creates confusion with someone else's mark, the complaint may well arrive at the holder's door. The applicable standard varies by country, and legal counsel should advise on it. The policy should require the relationship owner to flag any proposed partner name that is identical or similar to a known trademark before the name is issued. The [Trademark Name Check](/trademark-tlds#check) is a starting point for that assessment.
## Putting the policy into effect
Putting the policy into effect means three things: communicating it, loading the existing namespace into the register, and assigning the approval roles.
**Communication.** The policy should be communicated to every team that holds or is likely to request a name. For most organizations this means IT, legal, brand or communications, finance, and any teams that manage partner relationships. The communication should explain the approval process and the request form, and say which role owns the register.
**Initial register load.** If names already exist under the TLD, document each one against the policy categories before the policy takes effect. Assign each to the nearest matching category, record the original requester and business justification as best they can be reconstructed, and note where each name is held. Names that cannot be accounted for go to the first review as candidates for withdrawal.
**Role assignments.** Confirm in writing who holds each approval role named in the policy. If a role is vacant, name an interim. The policy should also specify what happens when an approver is unavailable: a deputization rule prevents a single absence from blocking a request.
A reasonable first step is to draft the categories table and the reserved list, since every other clause refers to them, and to put the registry's terms on names in front of your counsel at the same time. If terms such as name, TLD or resolution are used loosely inside your organization, fix their meaning in the policy; the [glossary](/glossary) gives definitions you can adopt.
Once the policy is in place, the next question is usually activation: what the names point to, and which uses are ready first. Putting a TLD to work after the transfer is one of the services of Hush Partners, a private desk for onchain TLDs. The desk is reached through the [contact form](/contact) only.
## Questions people ask
### Does the policy need to be a legal document?
It does not need to be a contract or a deed. An internal policy document, signed off by the appropriate executive and version-controlled, is sufficient for most governance purposes. Where names are issued to third parties, the agreement with the third party is the legal instrument; the policy sits behind it as the internal authority. Your own counsel should advise on whether any element of the policy creates obligations that need a more formal instrument in your jurisdiction.
### Can a name-holder pass their name to someone else?
Only if the policy permits it, and the default should be that it does not: passing a name on requires the approval of the register owner and the original approver, and doing so without approval is a ground for withdrawal. A rule on paper is not a technical barrier, though. Whoever controls the wallet in which a name sits may be able to move it, depending on how the registry handles names. That is the strongest argument for keeping internal names in wallets the organization controls.
### What happens to the names when the TLD itself changes hands?
The new holder of the TLD acquires the power to issue names under it. Names issued before the transfer split into two groups. Those the selling organization holds itself can be transferred along with the TLD if the two parties agree; those sold to third parties remain with the parties who hold them. An internal policy written by the previous holder does not bind the new one. A sale agreement should therefore say what the parties intend for existing names, and the register is the document that makes that possible. Work through the implications with legal counsel before closing.
### Do we need a separate policy for AI agents that use names under the TLD?
Not necessarily a separate policy, but the issuance policy should include a clause on names issued to autonomous systems. An AI agent that uses a name under `.yourbrand` to send messages, make requests or receive payments will be read as acting for the organization. Beyond the record of the system and its accountable human, the clause should set a review trigger: when the scope of the system changes, the name goes back through approval.
### How do we handle a dispute about a name with a third party?
Onchain TLDs do not sit within the ICANN system, so the Uniform Domain-Name Dispute-Resolution Policy (UDRP), which binds registrants of ICANN domain names through their registration agreements, does not reach them. A third party with a trademark complaint about a name under your TLD will turn to the applicable law and to you directly. The issuance policy should include a clause on how the organization handles incoming trademark complaints about names in the namespace, and legal counsel should be the first point of contact when one arrives.