# Writing an internal policy for onchain names
> A clause-by-clause guide for general counsel: who may register, who holds the wallet, who decides to acquire, who approves a name, departures and review.
Source: https://hush.partners/writing-an-internal-policy-for-onchain-names
Category: Brand protection
Published by Hush Partners.
---
Onchain names usually enter an organization sideways. A product manager registers one for a pilot. An agency registers another for a campaign and keeps it in its own wallet. A founder bought the company name long ago and still holds it personally. Nobody did anything wrong, and nobody can say with confidence what the organization holds, who controls it, or who would be entitled to hand it over.
A domain name policy does not solve this, because most of its machinery assumes a registrar account, a renewal invoice and a corporate login that IT can reset. None of those exist here. An onchain name is held by whoever controls a wallet, and the internal rule has to be written around that fact.
This article is for the general counsel who has been asked to write that rule, or who has decided that it is time. It sets out the clauses a short policy needs, the choices inside each one, and a drafting procedure that gets the text adopted. It does not tell you whether your organization should hold onchain names at all. A policy is useful in either case, because "we do not register these, and here is who to tell if you see one" is also a rule.
## What the general counsel is regulating, in one page
A policy drafted without a clear picture of the asset will regulate the wrong thing. Four features matter for drafting, and each one produces a clause later.
First, control follows the key. On Freename, the registry this article uses for its facts, a TLD exists as a token recorded onchain and sitting in a wallet. Whoever can operate that wallet controls the TLD. There is no account behind it that the organization can reclaim by proving its identity to a help desk.
Second, issuing is reserved to the holder. Names under a TLD, such as `pay.yourbrand` under `.yourbrand`, can only be created by the holder of that TLD. The registry offers no delegated management, so "the marketing team can issue names" really means "the marketing team can ask the person who operates the wallet".
Third, nothing expires on a calendar. A Freename TLD carries no annual renewal fee. That removes a risk, and it also removes the yearly invoice that forces a domain portfolio to be looked at.
Fourth, the record is public and the reach is partial. Anyone can read the registry record on a block explorer. Resolution, on the other hand, works only in software that supports it, and that coverage changes over time. The [capabilities that are live](/whats-live) are the right reference when the policy touches what a name may be used for.
## Scope: which names and which people the rule covers
Scope is where most first drafts fail, usually by being too narrow. A policy that covers "TLDs owned by the company" misses the three situations that cause trouble in practice.
### Names, not only TLDs
The policy should cover three layers. The first is any TLD held for the organization. The second is any name the organization holds under a TLD it does not control, for example a name under a shared suffix operated by someone else. The third is any name issued under the organization's own TLD, whether it is kept internally or given to a third party. One sentence per layer is enough, and the defined term "Onchain Name" can then carry all three through the rest of the text.
### Names that match the brand but sit elsewhere
A name can match one of your marks and be held by a party with no link to you. That name is outside the organization's control, so the policy cannot govern it. What the policy can do is say who is told and who decides on a response. Keep this to a short cross-reference to your brand protection procedure. A first view of how your marks appear onchain, for instance from the [Namespace Exposure Score](/namespace-exposure-score), often changes what the scope clause needs to mention.
### People: employees, founders, agencies, affiliates
State who is bound. Employees and contractors are the obvious group. Add agencies and vendors acting on the organization's instructions, and say that the obligation is passed to them by contract. Add subsidiaries and joint ventures explicitly if the policy is meant to be group-wide, since a local team often assumes that a head office rule about domains stops at head office.
Founders and executives who hold a matching name personally need careful wording. The policy can require disclosure of such a holding. Whether it can require a transfer depends on employment terms, on when the name was acquired and on local law, which varies by country. Draft the disclosure duty firmly and leave the transfer question to an individual agreement reviewed by your own counsel.
## The policy clause by clause
The table below is the skeleton. A complete policy rarely needs more than these eight clauses, and each fits in a short paragraph. The sections that follow take the clauses that require a real decision.
| Clause | What it settles | Usual owner |
| --- | --- | --- |
| Scope and definitions | Which names and which people are covered | Legal |
| Registration authority | Who may register a name, and into which wallet | Legal with brand |
| Custody | Who holds the wallet and how many people must approve | Security or treasury |
| Acquisition decisions | Who may decide to acquire a TLD and at what level | Executive sponsor |
| Issuance approval | Who approves a name under the organization's TLD | Brand with legal |
| Departures and vendors | What happens when a keyholder or agency leaves | HR and security |
| Register and review | Where holdings are recorded and how often checked | Legal |
| Exceptions and breaches | How to ask for an exception and what a breach triggers | Legal |
Name roles, never individuals, so that the text survives a reorganization, and give each clause exactly one owner who answers for it.
## Who may register a name, and in whose wallet
This is the clause that prevents the sideways arrivals described at the start. It has two halves, and both are needed.
The first half is a prohibition. No one registers, buys or accepts an onchain name that contains a mark, a product name or the trading name of the organization, for use in the organization's business, on a personal wallet or on a wallet controlled by a vendor. The wording "for use in the organization's business" matters. Without it, the clause tries to regulate what employees do in their private lives, which is harder to justify and harder to enforce.
The second half is a route. A prohibition with no route produces quiet workarounds. The clause should say how a team asks for a name: a short request to a named role, stating the string wanted, the purpose, the registry and the expected period of use. It should say who answers and within what delay the requester can expect a decision. If the organization has decided to register nothing for the time being, the route is still worth writing. It then ends with "requests are logged and declined pending review", which gives legal a record of demand for the next review.
### Low-value names and the temptation to exempt them
Teams will ask for an exemption for inexpensive names registered for tests. Resist a blanket exemption. The cost of a name tells you nothing about the cost of losing control of it once it has been printed on packaging or placed in an app. A better answer is a fast path: names registered for a declared test go into a designated test wallet controlled by the organization, are recorded in the register on the same day, and are not published outside the test without the normal approval.
## Custody as one clause: who holds the wallet
Custody deserves a full procedure of its own, written by the people who run key management. In the policy it is one clause, and the general counsel's job is to fix the principles that the procedure must respect, not to write the procedure.
Four principles are enough.
The wallet belongs to the organization. The policy states that every wallet holding an Onchain Name is an asset of the organization, set up on the organization's instructions, and that no individual acquires any right in the names by operating it.
No single person can move a TLD alone. The usual way to achieve this is a wallet that requires several keyholders to approve each transaction. The policy sets the principle and the minimum number of approvers. The custody procedure chooses the tooling.
Keyholders are named by role and recorded. The register shows which roles hold approval rights, and a change of keyholder is itself an event that is logged.
Recovery is planned before it is needed. The clause requires a documented way to keep control if a keyholder is unavailable, and it requires that the plan be tested. A plan that has never been run is an assumption.
One further point belongs here because it is new to most custody clauses. Freename publishes a Model Context Protocol server, which lets an AI assistant carry out registry operations in a conversation. An assistant connected in this way acts as the holder. The policy should therefore say that connecting any assistant or automation to a wallet that holds a TLD counts as granting holder authority, and needs the same approval as adding a human keyholder.
## Who decides to acquire a TLD, and who approves a name under it
These are two different decisions, and policies that merge them end up with a board approving a name for a campaign page, or a campaign manager committing the organization to an acquisition. Separate them.
### The decision to acquire
Acquiring a TLD that matches the brand is a one-off purchase of an asset, often from a private holder, sometimes through an intermediary. The policy does not need to describe the transaction. It needs to settle four things: who may open a discussion with a holder or an intermediary, who may sign a confidentiality agreement for that purpose, who approves the spend, and who decides which wallet receives the asset at closing.
The first point is the one most often left out. An informal approach by an enthusiastic employee can disclose the organization's interest before anyone has decided whether there is one. A single sentence fixes it: only the role named in this clause, or an adviser it mandates, contacts a holder about a name. An organization that prefers not to appear at all can mandate a desk to [find and approach the holder](/buy-side-acquisition), and the policy should allow for that route by naming who may give such a mandate.
For the spend, do not invent a new approval ladder. Refer to the existing delegation of authority and state that an Onchain Name is treated as an intangible asset purchase for that purpose. How it is then recorded in the accounts is a question for your finance team and auditors, and the answer varies by country.
### The approval to issue a name
Issuing `pay.yourbrand` is a small act for the keyholders. That is exactly why it needs an approver. Three reasons justify a formal step.
A name under your TLD speaks for the brand. Customers who see `support.yourbrand` will assume it is yours, and they will be right, so what sits behind it carries your responsibility.
Issuing to a third party may be hard to undo. Whether a holder can withdraw or change a name that has already been issued depends on the case, and the policy must not assume that it can. The safe drafting position is that a name given to a distributor, partner or agency is given on written terms, approved before issuance, on the assumption that the technical record may outlast the relationship.
Pricing is also a decision. The holder sets the price of names under its TLD and may price them differently. A brand owner may well issue names internally at no charge and never open registration to the public. If the organization ever does open it, that step should be reserved to the same level that approves an acquisition, because it changes what the TLD is. The same applies to joining the registry's royalty program, which shares registration fees with the holder and carries an annual cost set by the registry: it is a commercial decision with a budget line, not an administrative setting.
### What an approved name may carry and where it is printed
The approval should cover two more things. Any record placed on a name is approved by the function that owns the underlying thing: treasury for a payment address, the owner of the corporate site for a website. A name that resolves to a wallet nobody in finance recognizes is a control failure, whatever the amount.
Publication is the second. Because the ICANN DNS root holds no entry for an onchain name, a browser opens one only where support has been added. For Freename names, that means Bitcoin.com Wallet, MetaMask by way of Freename's resolver, and desktop browsers fitted with the Freename Web3 extension, a partial coverage that changes. The policy should require that any public use of a name states where it works, is tested in that software first, and is accompanied by a conventional address. For reaching the general public by browser or by email, the DNS remains the better tool, and the policy should say plainly that an onchain name supplements the organization's domains and replaces none of them.
### The decision table
The division of decisions can be set out in a second table, which many organizations annex to the policy.
| Decision | Proposes | Approves | Carries out |
| --- | --- | --- | --- |
| Approach a holder | Brand or legal | General counsel | Named role or adviser |
| Acquire a TLD | Executive sponsor | Per delegation of authority | Treasury and custody |
| Issue an internal name | Requesting team | Brand lead | Wallet keyholders |
| Issue to a third party | Business owner | Brand lead and legal | Wallet keyholders |
| Open public registration | Executive sponsor | Same level as acquisition | Wallet keyholders |
In every row that touches the TLD, the people who carry out the decision are the keyholders, because nobody else can. The approval clause and the custody clause therefore have to name compatible roles, and the keyholders need a stated time within which to act.
## Staff departures, role changes and agencies
This clause is the one that will be used most often, and the one that is hardest to retrofit after an incident.
### When a keyholder leaves or changes role
The trigger should be the HR event, not the goodwill of the person leaving. The clause requires that the offboarding checklist include a line for Onchain Names: is this person a keyholder, does this person hold any name on a personal wallet for the organization's business, and has this person connected any tool or assistant to an organization wallet. If the answer to any of these is yes, the custody owner replaces the keyholder before the last working day where that is possible, and records the change.
A change of role is treated the same way: role, not history, is the basis for holding a key.
### When the name sits on a personal wallet
Sooner or later the organization will find a name held personally by a current or former employee. The policy should set the default expectation: names registered for the organization's business are transferred to an organization wallet on request, and reasonable registration costs are reimbursed. Whether that expectation is enforceable against a given person depends on the employment contract, on any intellectual property assignment and on local employment law. The policy states the rule for the future. The individual cases from the past are handled one by one, calmly, with your own counsel.
### Agencies and vendors
Agency contracts should carry a short clause that mirrors the policy: no registration of names containing the client's marks except on the client's written instruction, registration directly into a wallet designated by the client, and transfer of anything already held at the end of the engagement. Procurement can add the clause to its templates once, which is more reliable than relying on each project owner to remember it.
## The register and the review cadence
A domain portfolio gets reviewed because invoices arrive. With no annual renewal fee on a Freename TLD, nothing arrives. The review has to be imposed by the policy itself.
### The register
Require a single register of Onchain Names, kept by legal or by the function that keeps the domain register. For each entry it records the name, the registry, the wallet that holds it, the roles with approval rights, the purpose, the approver, the date of issuance or acquisition, and a link to the public registry record. For names issued to third parties, add the counterparty and a reference to the written terms. The register is the document that an auditor, an acquirer or a new general counsel will ask for first.
### Three kinds of review
A fixed annual review alone is too slow for some events and unnecessary for others. A workable clause uses three triggers.
| Review | Trigger | What is checked |
| --- | --- | --- |
| Periodic | A fixed interval set by the policy | Register against the public record, keyholders against roles |
| Event-driven | Departure, reorganization, new product, acquisition | The affected names and wallets only |
| Policy review | Material change in registry terms or resolution coverage | Whether the clauses still fit |
The periodic review is a reconciliation of the register against the public record, with every difference explained. Since anyone can read that record on a block explorer, the check can be given to a person who holds no key, which is a useful separation of duties.
The policy review is the one that keeps the text honest. Registry terms change, and so does the set of wallets and browsers that resolve a name. A clause that was accurate when adopted can become misleading without anyone inside the organization having done anything. Assign one role to watch for those changes. Where the concern is names that match the brand and are held by others, a [monitoring service](/namespace-watch) can feed the event-driven review without adding work to the legal team.
## A drafting procedure that gets the policy adopted
Policies about unfamiliar assets tend to stall in consultation. The sequence below is designed to keep the text short and to surface the difficult facts before the draft circulates.
From blank page to adopted policy
Take an inventory firstAsk brand, product, IT, marketing and the agencies what they hold or have registered. Check the organization's main marks on the registries you care about. Draft nothing until you know what already exists.
Decide the organization's positionAgree with the executive sponsor on one of three positions: hold nothing, hold defensively, or hold and use. The position determines how long each clause needs to be.
Name the rolesFix the owner of each clause and the approver of each decision before writing sentences. Disagreements about roles are the real negotiation, and they are easier to settle against a table than against prose.
Write the eight clauses shortOne paragraph each, roles and not names, principles and not tools. Move everything operational into the custody procedure and the register.
Test the draft on three casesRun a keyholder who resigns, an agency that registered a campaign name, and a team that wants a name next week. If the draft does not say who does what in each case, revise it. Write the exceptions clause from what the cases reveal: who grants an exception, in writing, with an end date.
Align the neighboring documentsUpdate the domain policy, the offboarding checklist, the agency contract template and the delegation of authority so that each one points to the new rule.
Adopt, publish and scheduleHave the policy approved at the level that approves the domain policy, publish it where staff look for rules, and put the first periodic review in the calendar on the day of adoption.
## Before the first draft: two questions to settle
Do not start with the text. Start with two questions that take a few days and that shape every clause.
The first is what exists. Send the inventory request from step one, and at the same time check whether names matching your principal marks are already registered, and whether any are held by your own people. The free check on the page that explains [what a trademark TLD is](/trademark-tlds) covers the first part for a mark. The answers tell you whether the policy is mainly about preventing future registrations or about regularizing past ones.
The second is who will hold a key. If no function is willing to own custody, the organization is not ready to hold a TLD, and the honest policy for the moment is the short one. Have that conversation with security and treasury before circulating a draft that assumes their agreement.
If the inventory shows that the TLD matching your brand is in someone else's wallet, that is a separate file from the policy and should not delay it. Hush Partners acts for organizations that mandate it to find and approach a holder, under a mutual NDA, and the page for [general counsel and brand protection teams](/brands-and-legal-teams) describes how such a file runs. The policy only needs to say who inside your organization may open that conversation. Terms used in this article are defined in the [glossary](/glossary), which is a convenient source for the definitions clause.
## Questions people ask
### Should this be a separate policy or a chapter of the domain name policy?
Either works. A chapter is easier to maintain where one team already runs domains and is willing to take on the register. A separate policy is clearer where custody sits with treasury or security, because those functions are rarely readers of the domain policy. Whichever form you choose, the two texts must point to each other.
### Who should own the policy if there is no brand protection team?
The general counsel, with the custody clause delegated to whoever manages the organization's most sensitive credentials. In a small organization the same two or three people will appear in several roles. That is acceptable as long as no single person can both approve a decision and carry it out alone.
### Does the policy need board approval?
Usually not for the policy itself, which sits at the level of other operational policies. The decision to acquire a TLD may need it, depending on the amount and on your delegation of authority.