Terms of use for names issued under your TLD
A clause-by-clause guide for the operator of an onchain TLD who must write the terms a registrant accepts, with the limits of what an operator can promise.
You hold a TLD, you intend to issue names under it to people you do not know, and at some point one of them will ask what exactly they bought. Another will use a name in a way you did not expect. A third party will write to say that a name under your TLD harms them. In each case the first thing anyone reaches for is the document the registrant accepted. If that document does not exist, or was copied from a domain registrar whose situation is not yours, you will be improvising at the worst moment.
This article is for the operator who has to write that document. It goes through the clauses one at a time: what the registrant receives, what use is acceptable, how complaints are handled, what you can and cannot do to a name once it is issued, how the terms change, and which law governs them. It is written for a namespace such as .yoursector, open to registrants outside your own organization, though most of it applies to a brand that issues name.yourbrand to partners.
Two limits apply throughout. First, this is information in general terms: contract and consumer rules differ from one country to the next, and the lawyer who advises you decides the wording. Second, an onchain name does not behave like a DNS domain in the ways that matter most to a terms document, and the honest version of your terms says so.
What a registrant agreement under .yoursector is for
A short reminder of the object. On Freename, a TLD exists as a token recorded onchain and sitting in a wallet. Whoever holds that token is the only party able to issue names beneath it, and that holder also decides what each name costs. A name issued to a registrant is in turn held in the registrant’s wallet. None of these names is part of the ICANN DNS root, so a browser with no added support will not open one.
Your terms of use sit on top of that technical layer. They do three jobs.
They describe the thing. A registrant who thinks name.yoursector works like a web address everywhere has been misled even if nobody intended it. The terms are where the description is fixed in writing.
They set the conduct you expect. The technical layer does not know whether a name is used honestly. Only a rule the registrant has agreed to gives you a basis to object.
They allocate risk between you and the registrant: what you are responsible for, what you are not, and what happens when something outside your control changes.
Notice what the terms are not. They do not replace the registry’s own terms, which bind you as holder and usually bind the registrant as a user of the registry. Your document is a second layer between you and your registrant, and it cannot promise anything the registry’s terms or the technology do not let you deliver. Read the registry’s current terms before drafting a line of your own, and keep a dated copy of the version you read.
The clauses, and the purpose each one serves
Operators who start from a registrar’s template tend to end up with a long document, much of it about renewal grace periods and transfer locks that may have no equivalent here. Start instead from the questions a registrant, a complainant and a later buyer of your TLD would each ask. Eight clauses answer nearly all of them.
| Clause | Purpose | Common drafting slip |
|---|---|---|
| Parties and scope | Says who the operator is and which names are covered | Naming a person where a company is meant |
| What the registrant receives | Describes the name and its limits | Promising resolution everywhere |
| Eligibility | States who may register | Rules nobody will ever verify |
| Acceptable use | Sets the conduct expected | A long list no one can apply |
| Complaints | Tells third parties how to reach you | A promise of a fixed outcome |
| Operator’s actions | States what you may do to a name | Claiming powers you may not have |
| Changes to the terms | Sets how a new version takes effect | Silent replacement of the text |
| Law, liability, disputes | Allocates risk and names a forum | Copying another country’s clause |
What the registrant receives, stated without overpromising
This clause is the one registrants read. Write it as a plain description, in the second person if your counsel allows it, and cover five points.
The name and where it sits
Say that the name is issued by you as holder of the TLD, that it is recorded onchain, and that it is held in the wallet the registrant designates. Say that this record is public and can be looked up on a block explorer.
What it costs and for how long
State the price and whether the payment is made once or recurs. Do not assume the answer from the TLD itself. A Freename TLD carries no annual renewal fee for its holder, but that is a statement about the TLD. How names beneath it are charged over time depends on the registry’s terms for those names and on the pricing you set, so check both and write down exactly what applies. If you price names differently from one another, which a holder is free to do, say that prices vary by name and that the price shown at registration is the one that binds.
Where the name works, and where it does not
This is the sentence most templates lack. Support for Freename names exists in three places: Bitcoin.com Wallet, MetaMask (through the resolver Freename provides) and desktop browsers running the Freename Web3 extension. That coverage is partial and it changes over time. Your clause should say that the name works in software that supports it, point to a page you keep up to date, and state that you do not promise resolution in any particular wallet, browser or application. The page on what works with onchain TLDs shows the kind of sourced inventory a registrant can be pointed to, and the one on names in wallets covers the most common use.
Add, in one line, that the name is not a DNS domain and does not carry ordinary internet email. A registrant who expected a mailbox will be less upset by a clause than by a discovery.
What the name does not give
A name is not a trademark and confers no right in the word it contains. It does not mean you endorse the registrant, and it does not make the registrant your agent, member or partner unless a separate agreement says so. If your namespace implies membership of a profession or a sector, this sentence deserves care, because the public will read a name under .yoursector as a credential whether or not you intended one.
What the registrant may do with it
Say whether the registrant may transfer the name to another wallet or another person, and that whoever receives it is bound by the same terms. In practice a token moves when its holder moves it. A clause that forbids transfer without your consent is a promise you may not be able to enforce technically, so prefer a clause that binds the new holder over one that pretends to prevent the move.
Acceptable use for names in your namespace
The acceptable use clause is where operators write too much. A list of forty forbidden behaviors reads as thorough and works badly, because every complaint becomes an argument about which line applies. Five or six categories, each defined in a sentence, are easier to apply and easier to defend.
A workable set for most namespaces:
- Using a name to pass as another person or organization, or to suggest an affiliation that does not exist.
- Using a name to deceive people into sending funds or disclosing credentials.
- Using a name, or content reached through it, for activity that is unlawful where the registrant or the affected person is located.
- Using a name in a way that infringes the rights of others, including trademark rights.
- Registering names in bulk with no intent to use them, where your namespace is meant for practitioners of a sector.
- Giving false information at registration, where you ask for any.
Then add what is specific to your namespace. A sector TLD may require that the registrant actually works in the sector. A brand TLD issued to partners will tie the name to the partnership. Keep each of these to something you can check. A rule you cannot verify gives you nothing when a complaint arrives, and it gives a registrant grounds to say that you never applied it to anyone else.
Two drafting points keep the clause fair. Describe conduct, not opinions: forbid deception, not content you dislike. And say that the registrant is responsible for the use of the name, including use by anyone they let manage it.
The complaints clause: who may write, and what you will do
Someone who believes a name under your TLD harms them needs a way to reach you. In the DNS, an established set of dispute procedures exists for this, and a trademark owner has a known path. No such procedure binds an onchain TLD by default, so for names under your TLD the path is whatever you write. That is a responsibility, and it is also the clause that most reassures a later buyer of your TLD.
The clause should name a single channel, such as a form on your website, and say what a complaint must contain. It should say what you will do with it, in terms of process and never of outcome. It should also say what the registrant can expect: to be told, and to be heard, before you act, except where telling them would cause harm.
- Receive through one channelAccept complaints only through the form you publish. Ask for the name concerned, who is complaining, what the harm is and what supports the claim.
- Acknowledge and recordConfirm receipt and open a file. Save the public record of the name as it stands, because records under a name can change.
- Sort by typeSeparate deception aimed at the public, rights claims such as trademarks, and disagreements between two parties that are not yours to settle.
- Hear the registrantPass on the substance of the complaint and give a stated period to answer. Skip this step only where your terms say you may, for clear deception.
- Decide against the written clauseName the line of the acceptable use clause you rely on, or say that none applies. Write the reasoning in a few lines and keep it.
- Act within your real meansUse the measures your terms describe and that you are in fact able to take, then tell both sides what was done and what was not.
Two choices have to be made in the wording. The first is how you treat rights claims. You are not a court, and a clause that makes you the judge of two competing trademark positions puts you in a role you cannot fill. Say that you act on a decision of a competent court or authority when one is shown to you, that you may act on clear cases without one, and that in contested cases you will tell the parties to resolve the matter between themselves.
The second is repeat complaints and bad faith. Reserve the right to decline complaints that repeat a matter already decided, or that are plainly made to obtain a name and not to stop a harm. A complaints channel should protect people, and it should not become a way to take names from registrants who did nothing wrong.
What you can and cannot do to a name once it is issued
This is the clause where an onchain namespace differs most from the DNS, and where copying a registrar’s wording does real damage. A DNS registry can suspend or delete a domain because it controls the zone the domain lives in. An issued onchain name is a token in the registrant’s wallet. Whether the holder of the TLD can withdraw that name, or alter it, after issuance is not something to assume. It is settled case by case, by the registry’s terms and by how the name was issued, and you confirm it with the registry before you write the clause.
What you write therefore depends on the answer you receive. Where the registry confirms that some action on an issued name is available to you, describe it precisely, state the grounds on which you would use it, and tie it to the complaints procedure. Where it does not, say plainly that a name once issued stays in the registrant’s wallet, and build the clause from the measures that are yours in any case.
| Measure | When it is available | What it achieves |
|---|---|---|
| Refusing to issue | Before issuance, always | Prevents the problem |
| Ending the agreement | When the terms are breached | Removes the registrant’s rights under the contract |
| Removal from your directory | If you publish one | Withdraws your endorsement |
| Refusing further names | Always | Stops repetition |
| Notifying platforms | Where a platform accepts reports | Lets those who run software act |
| Public notice | Where your terms allow it | Warns the people affected |
The first row is the strongest. Since only the holder issues names, every name passes through you once, and that moment is the one where your control is complete. Terms that let you decline a registration without giving a reason, combined with a short reserved list, do more for the health of a namespace than any revocation clause.
The second row needs an honest sentence. Ending the agreement means the registrant no longer has your permission to use the name, may no longer present it as a name in good standing under your TLD, and loses any service you provide around it. It does not by itself move the token. Say that. Then add a contractual duty: a registrant whose agreement has ended undertakes to stop using the name and, where you ask, to transfer it back to you. That duty is enforceable the way any contract is, through the courts of the place your governing law clause points to, and not through a switch.
Write also what you will not do. You will not take a name back in order to sell it to someone who offers more. You will not change the records a registrant has set. Stating these limits costs nothing, and it is a commitment registrants look for.
Changing the terms after names have been issued
Four points belong in the changes clause, which decides whether you can repair the document later.
Versions. Give each version a number, and keep every past version available at a stable address. A registrant, a complainant or a buyer of your TLD should be able to see which text applied when a given name was issued.
Notice. Say how you will announce a change and how long before it takes effect. Here an onchain namespace has a practical difficulty: you may know a registrant only as a wallet. If you want to be able to reach registrants, ask for a contact at registration and say in the terms that notices go there. If you choose not to collect one, say that changes are announced on your website and that the registrant is responsible for checking it.
Effect on names already issued. Decide whether a new version applies to existing names or only to names issued afterward. Changes that describe reality, such as where names resolve, can apply to everyone. Changes that take something away from a registrant, such as a new eligibility rule, are safer applied to future registrations only, and in many countries the law limits one-sided changes to a contract, especially with consumers. Your counsel decides where that line falls.
A change of operator. If you sell the TLD, the buyer becomes the holder and the only issuer of names. Names you sold to third parties remain theirs. The terms should say that your rights and duties pass to whoever holds the TLD after you, so that registrants are not left with a contract whose other party has gone, and so that the buyer inherits a complaints procedure and not a silence.
Governing law, liability and the registrant who is a consumer
No clause varies more between countries, and no clause is more often copied unread. Treat what follows as a list of questions to bring to your counsel.
Which law, and which courts. The usual choice is the law of the place where the operator is established. That choice is not always the last word. Where your registrant is a consumer, many countries give them the protection of their own law and their own courts whatever your terms say. If you issue names to individuals across borders, assume that some of your clauses will not apply as written to some registrants, and have counsel tell you which.
Who the operator is. The clause is empty if the operator cannot be identified. State the legal entity behind the namespace. An operator who wishes to stay personally discreet can do so by operating through a company, and should not do so by publishing terms with no party on the other side.
Limits of liability. You will want to exclude responsibility for things you do not control: changes in software support, the registry’s own decisions, loss of the registrant’s keys, the acts of other registrants. Say each of these plainly. Broad exclusions of all liability tend to be struck down or read narrowly, and a list of specific, true statements about what you do not control holds up better than a sweeping sentence.
Where the terms live and how acceptance is recorded
A clause accepted by nobody binds nobody. The practical question is how a registrant comes to agree, and you need to settle it before the wording.
There are two routes, and they lead to different documents. Where names under your TLD are registered through the registry’s own purchase flow, the registrant deals with that flow and may never see your website. Ask the registry how an operator’s own terms can be presented in that flow, and do not assume they can. Where instead you issue each name yourself, after the registrant has applied to you directly, you control the moment of agreement: the registrant reads the terms, confirms acceptance on your form, and you issue the name afterward. This second route is slower, and it suits a namespace with eligibility rules.
Whichever route applies, keep a record of what was accepted: the version number, the date, the name concerned and the wallet it was issued to. Store it outside the onchain record.
Publish the terms where a person without special software can read them. A site built with the registry’s website builder and reached through your onchain name opens only in browsers that support the name, so a complainant using an ordinary browser would not find it. The complaints form and the terms belong at an address anyone can open. You can still mirror them on a website under your own TLD for the registrants who use one.
From outline to a published first version
The work fits in a few sessions if you take it in order. The sequence below puts the facts before the wording, which is what keeps the document true.
- Read the registry's termsNote what binds you as holder and what binds a registrant directly. Keep a dated copy.
- Put your questions to the registryAsk what a holder can do to an issued name, how names under your TLD are charged over time, and how your terms can be shown at registration.
- Fill the eight clauses in plain wordsWrite one paragraph per clause before any legal drafting, stating only what you know to be true.
- Hand the outline to counselAsk for the governing law, liability and consumer points for the countries your registrants are in.
- Test it on three casesRun an imagined impersonation complaint, a trademark claim and a lost wallet through the text and see whether it tells you what to do.
If you are still planning the opening of your namespace, the terms are one line of a longer plan, and the launch roadmap tool builds that plan for a newly acquired TLD. The page for operators of a market TLD sets out the wider picture of running a namespace.
The wording itself is work for your own counsel. Hush Partners, a private desk for onchain TLDs, comes in where a TLD is sold or acquired, and a namespace with clear, versioned terms and a working complaints channel is simpler for a buyer to take over. If you have just acquired a TLD and are setting it up, activation after the transfer describes that stage, and questions can be sent through the contact form.
Questions people ask
Do I need terms of use if I only issue names inside my own organization?
A full registrant agreement is usually unnecessary when every name stays with the organization that holds the TLD. An internal rule on who may ask for a name and who approves it does the job. Terms become necessary once a name goes to anyone outside, including a partner, a contractor or an affiliate with its own legal identity.
Do the terms need to say anything about personal information?
If you collect a contact or proof of eligibility, privacy rules apply in many countries, and the terms should point to a notice saying what you hold and why. Keep that information off the onchain record, which is public and cannot be assumed to be erasable.
What happens to my terms if the registry changes its own?
Your terms cannot give more than the registry allows, so a change at the registry can make one of your clauses inaccurate. Include a sentence saying that your terms operate within the registry’s terms as they stand from time to time, and review your text each time the registry publishes a new version.
