Onchain today

The reserved list: names to hold back before launch

Which names an operator keeps out of open registration under a sector TLD, how the list is built and signed off, and how a reserved name is later released.

The reserved list: names to hold back before launch

You are about to open registrations under .yoursector. The prices are set, the page that explains the namespace is drafted, and the first registrants are waiting. One document is usually still missing, and it is the one that is hardest to write after the fact: the list of names nobody can register on opening day.

A reserved list is a plain file. Each line is a name under your TLD that you have decided to hold back, with a reason and a rule for how it could one day be released. It does not say who may register the other names, at what price, or under which terms. Those questions belong to your issuance policy, your price grid and your terms of use. The reserved list answers only one question: which names are not on the shelf.

This article covers that list and nothing else: the four families of names that belong on it, how to build it in an orderly way, who should approve it, and how a name leaves it. It is written for the operator of a sector TLD, but most of it applies to any holder who lets third parties register names.

What a reserved list does for the operator of .yoursector

On Freename, a TLD is a token in a wallet, and the wallet that holds it is the only one that can create names beneath it. That gives you complete control at the moment of issue and much less afterward. Once a name sits in a registrant’s wallet it is theirs. Whether a holder can withdraw or alter a name that has already been issued is decided case by case, so you should plan as if you could not.

That asymmetry is the whole argument for the list. Every decision you fail to take before launch is taken for you by the first person who types the name. If that person is a stranger who now holds support.yoursector, you have a problem you cannot fix alone.

The list has four jobs, and each matches a family of names.

Family What it holds Why it is reserved Usual outcome
Operator functions Names your own service needs So nobody else can speak as you Issued to your wallet
Sector organizations Names of known bodies in the field To prevent harm to them and their public Held, released to them only
Offensive terms Slurs, abuse, harmful words To keep the namespace usable Held permanently
Generic premium words The short common words of the sector To decide their use deliberately Released by a set process

Only the fourth family has a commercial dimension, and it is the one operators spend the most time on, usually at the expense of the other three.

Why the list has to exist before the first registration

There are three reasons to finish the list before opening, and none of them is about revenue.

The first is the asymmetry described above. A reservation costs nothing to undo: you release the name. An issue may not be undoable at all.

The second is fairness. If you remove names from availability after people have started registering, the registrants who came early will read it as a change of rules. A list fixed before launch, with a date and a version number, lets you say truthfully that every registrant faced the same shelf.

The third is the public record. Names issued under a TLD can be read by anyone, and whatever appears under .yoursector in the first days is the first impression the sector gets of you.

One limit should be stated plainly. A reserved list governs your TLD and nothing beyond it. It does not stop the same word from being registered under another TLD, on another registry, or in the DNS.

How a reservation is actually held

The mechanics depend on the tools your registry gives you, and you should confirm them with the registry before you rely on them. Two general approaches exist, and they are not equivalent.

The first is to issue the name to a wallet you control. This needs no special feature, because issuing names is exactly what a holder does. The name then exists onchain, is visibly held, and cannot be taken by anyone else. It suits names you will use yourself and names you want to be certain of.

The second is to keep the name out of open registration without issuing it. A holder can price names differently from one another, so a name can be treated differently from the standard grid. Whether your registry lets you block a name outright, and how reliable that block is, is a question for the registry, not an assumption to make. Where the answer is unclear, issue the name to your own wallet.

Record which approach applies to each line. The difference matters later: a name issued to your wallet is a name you hold, and if the TLD is ever sold, names the seller holds under it can move with the TLD by agreement between the parties.

Names the operator needs for its own functions

Start with yourself. These are the names a registrant, a journalist or a wallet user would assume belong to the operator of .yoursector. If someone else held them, that person could plausibly pass for you.

Think in functions, not in vocabulary:

  • Service functions. Help, support, registration, billing, status, the names under which you would answer a question or take a payment, such as pay.yoursector.
  • Authority functions. Words that suggest an official voice: admin, official, registry, operator, team, security, legal, abuse, and the word for the TLD itself where it makes a sensible name.
  • Trust functions. Verify, verified, trust, safe, and similar words. They are attractive precisely because they borrow credibility, which is the reason to keep them.
  • Technical functions. Names that software or habit gives a meaning to in the DNS world: www, mail, api, app, test, and close relatives. They may have no technical role under an onchain TLD, but people expect them to belong to the operator.
  • Your own identity. The name of the entity that operates the TLD, its short form, and the names of your products.

Decide which of these names you will use, because a function name put to work is worth more to your registrants than one that sits idle. Keep in mind that onchain names resolve outside the DNS and only where software supports them, and that this coverage is partial and changes, so test each function name in the wallets and browsers your registrants use before you print it anywhere. The page on what is live sets out what works and where.

Names of well-known organizations in the sector

This is the family that needs the most care, and the purpose must be clear from the first line of your file: these names are held back to prevent harm, not to be sold to the organizations they belong to.

The harm is easy to describe. Under a sector TLD, the name of a known organization reads as that organization. A member of the public who sees the name of a major body of the field followed by .yoursector will assume it is genuine. If a stranger registers it, the stranger inherits that trust. The organization is harmed, the public may be misled, and your namespace becomes the place where it happened.

Who goes on this part of the list depends on your sector, but the categories are stable:

  • the regulators, supervisors and public agencies of the field;
  • its professional bodies, associations and standard setters;
  • its largest and best-known companies and institutions, by their common names;
  • well-known products, schemes or certifications that the public treats as names in their own right.

You are not building a trademark register and you should not pretend to. You cannot enumerate every mark in a sector, and a reserved list is not a legal clearance. What a trademark protects, and against what, varies by country and by the goods and services concerned, and those are questions for counsel. Your test is narrower and more practical: would a reasonable person in this sector, seeing this name under .yoursector, believe it was the organization? If yes, hold it.

That rule protects you as much as them. An operator who reserves the names of sector organizations and then markets those names back to them has turned a protective measure into pressure on a rights owner. It is a poor way to enter a sector, and it invites exactly the legal attention the list was meant to avoid.

Accept that some of these names will stay on the list forever, unused. That is a normal result. The reservation has done its job if nobody else holds the name.

If your TLD is itself a word that matches a brand, the question is a different one, and the page on trademark TLDs is the place to start.

Offensive and harmful terms under your TLD

The third family is the least interesting to compile and the one you will be judged on fastest.

A sector TLD adds meaning to whatever stands in front of it. A slur under .yoursector is not a neutral string. It ties an insult to a profession, a community or a trade, with your namespace as the frame. The same goes for terms that promote violence, terms that sexualize minors, and terms that name a crime as a service.

Three sources give you most of the list:

  1. General word lists. Lists of abusive and profane terms are widely available for content moderation. Use one as a base, in each language your registrants use.
  2. Sector knowledge. Every field has its own insults: derogatory names for its practitioners, its clients or its competitors, and words associated with its scandals. No general list contains them. People who work in the sector do.
  3. Combinations with the TLD. Read candidate names aloud with the TLD attached. Some harmless words become harmful only in combination. This step cannot be automated well, so give it unhurried time.

Then set the edges of the family, because it can grow without limit. Two cautions help.

Do not reserve words merely because they are critical. A name that expresses disagreement with a practice of your sector is not an offensive term. If your list starts to hold back criticism, it has become an editorial policy, and you will have to defend it as one.

Do not treat the list as a filter that makes abuse impossible. People evade word lists with spellings, digits and characters that resemble letters. The reserved list removes the plain forms. What happens when a harmful name is registered anyway is a matter for your terms of use and your complaints procedure, which are separate documents. The list only reduces how often you need them.

This family is normally held permanently, with no release route. Say so in the file.

Generic premium words of the sector

The fourth family is the vocabulary of the field itself: the one-word nouns for what the sector makes, whom it serves, where it operates and what it promises. Under a sector TLD these are the names that read as categories, and a category name carries an implied claim to speak for the category.

There are two honest reasons to reserve them.

The first is use. Some of these names are better kept as shared infrastructure than issued to one registrant. A name that means “the directory” or “the standard” of the sector may serve every registrant if you run it yourself, and only one of them if you issue it.

The second is allocation. If a generic word is going to one registrant, you may want to choose how: to the first applicant, to the applicant with the best plan for it, or at a price above the standard grid. Pricing under your TLD is yours to set, name by name if you wish, so a higher tier for generic words is within your power. How to set those tiers is a pricing question and is not treated here. The subname revenue calculator can help you test assumptions about it.

What the reserved list contributes is the pause. A generic word on the list is a word whose fate you have decided to decide, not one that went to whoever was awake at the opening minute.

Keep this family small. The temptation is to reserve every attractive word and release them slowly. The cost is real: a namespace where every good name is unavailable looks closed, and early registrants are the people who make a namespace worth joining. A workable discipline is to reserve a generic word only if you can write, next to it, either the use you intend or the process by which it will be released. If you can write neither, let it go on opening day.

Be honest about value, too. A generic word under an onchain TLD is not a generic word in the DNS: it resolves only where software supports it, and no ordinary browser opens it without help.

Building the list for .yoursector step by step

A reserved list for a sector TLD is a long file, and its length depends on the size of the field. The work stays manageable for a small team if the method is fixed at the start.

From blank file to signed version one
  1. Open one file with fixed columnsName, family, reason in one sentence, how it is held, release rule, who proposed it, date added. Every later decision depends on these columns being filled.
  2. Fill the operator functions firstWalk through your own service from a registrant's point of view and write down every name under which you would be expected to answer. Add your entity and product names.
  3. Compile the sector organizations from public sourcesUse the membership pages of the sector's associations, the public registers of its regulators and the trade directories people in the field already consult. Apply the reasonable-person test and note the source for each line.
  4. Add the offensive termsMerge a general word list for each language with the sector's own terms, then review combinations with the TLD by reading them aloud.
  5. Select the generic wordsDraft the candidates, then delete every one for which you cannot write an intended use or a release process.
  6. Normalize and extendLowercase everything, remove duplicates, then add plurals, hyphenated forms and the plain spelling variants of the names that matter most.
  7. Have an outsider read itGive the file to someone who works in the sector but not for you, and ask two things: what is missing, and what should not be there.
  8. Freeze, sign and loadGive the file a version number and a date, obtain the approvals, apply the reservations with the registry's tools, and check a sample of names to confirm they cannot be registered.

Two steps go wrong most often.

The normalize step should include characters that look alike. Many scripts contain letters that resemble Latin ones, and digits stand in for letters easily. You will not catch every case, and you should not try to enumerate them by hand for the whole list. Do it for the operator function names and the best-known organizations, where an imitation would do the most damage.

The final check is the one people skip. A list that exists in a spreadsheet but was never applied protects nothing. After loading, try to register a handful of reserved names from an ordinary account, the way a stranger would. The launch plan produced by the activation roadmap is a natural place to schedule that test.

Who signs off the reserved list

A reserved list is a set of decisions with legal, commercial and reputational effects, and it should carry names of people, not only names under a TLD. Even a small operator can separate the roles, if only by having one person wear two hats on different days.

Role Reviews Question it answers
Product or community lead Operator functions, generic words Does this serve registrants?
Legal counsel Sector organizations, release rules Is the reason and the route defensible?
Sector adviser Organizations, sector insults What did insiders spot that we missed?
Holder of the TLD The whole file Do I accept this as the launch state?

The last line matters more than it looks. Because only the wallet that holds the TLD can issue names, and management cannot be delegated to another party, the person or entity controlling that wallet is the one who will in practice carry out every reservation and every release. If the wallet is controlled by several people through a multisignature arrangement, meaning that a set number of keys must approve each action, agree in advance that releasing a reserved name requires the same approvals as any other issue. If you manage the TLD through an AI assistant connected to the registry, remember that the assistant acts as the holder: it can issue a reserved name as easily as any other, so the list must be part of its instructions.

Counsel’s review is about reasons and process, not about certifying that the list clears every right in the sector. No list does. Ask counsel for three things: that each family has a stated purpose, that the release routes treat like cases alike, and that nothing in the file could be read as holding names in order to extract payment from the organizations they evoke. Rules differ between countries, and your own counsel decides what applies to you.

Sign-off produces a version. Keep the signed file unchanged and make every later change in a new version with its own date and approval.

Releasing a reserved name: routes and conditions

A list with no way out is a pile. Each family needs a release rule, written before the first request arrives, because the first request always comes from someone you would like to say yes to.

Route Applies to Condition Who approves
Own use Operator functions A working use is ready Product lead
Verified request Sector organizations Request confirmed as genuine Counsel and holder
Published process Generic words Criteria stated in advance Holder
No release Offensive terms None Not applicable

Release to a sector organization

The request comes from the organization, never from you. Confirm that it is genuine through a channel you find yourself: a contact published on the organization’s own official DNS website, or a letter from a person whose role you can check. Do not rely on contact details supplied in the request. Issue the name to the wallet the organization designates, on your published conditions or more favorable ones, and record who asked, how you confirmed it and when. If two bodies with the same name ask, which happens across countries, do not arbitrate on instinct. Keep the name held and take advice.

Release of a generic word

Publish the process before you run it: which words, in what order, on what criteria, and by what date decisions are made. Then follow it. The worst outcome for a namespace is not a generic word that went cheaply. It is the belief among registrants that the good names go to friends of the operator.

Release by removal

Sometimes a line simply should not be on the list: the organization no longer exists, the word proved harmless, or the function was never built. Remove it in a new version, with the reason, and let it join the open pool on a stated date so that nobody has advance knowledge.

Every release is an issue, and an issue should be treated as final.

Keeping the reserved list accurate after launch

The list is finished on opening day and out of date soon after. Sectors change: organizations merge and rename, new bodies appear, new products become household words within the field, and new insults are coined. Set a review rhythm that you will keep, tied to something that already happens, such as each revision of your terms or each new batch of generic releases.

Be careful with additions. Adding a name to the list after launch only affects names not yet issued. If the name is already in a registrant’s wallet, the list cannot reach it, and the matter belongs to your terms and to the specific facts. Never present a late addition as if it had applied from the start.

What to publish

Publish the existence of the list, its four purposes and its release rules. That tells registrants why a name is unavailable and tells sector organizations how to ask for theirs. Publishing the lines is another matter: a public catalog of organization names held under your TLD can look like an invitation to negotiate, which is the opposite of the intent. A common middle course is to publish the rules in full and to answer individual questions about a given name. Any name you issued to your own wallet is visible in any case: the registry’s record is open, and a block explorer shows it to whoever looks.

If you acquired the TLD from a previous holder, begin by reading what is already issued under it before you write a single line. Your reserved list can only cover what remains, and the names the seller held and passed to you by agreement may already be the core of your first family.

Draft your first version before you set a launch date

Open the file with its seven columns and fill the operator functions before you do anything else. That part is the quickest to write and removes the most damaging risk. Then give the sector organizations to the person on your team who knows the field best, with the reasonable-person test written at the top of the sheet. Set the launch date only once version one is signed and a stranger’s test registration of a reserved name has failed.

If you are preparing a sector namespace, the page for operators is written for holders who run a TLD as a namespace, and the post-transfer activation service covers putting a TLD to work after an acquisition. Hush Partners is reached through the contact form, and a standard mutual NDA applies to whatever you send.

The Hush Partners desk

Notes from the desk. Written by the people who run the files.

Tell us what you hold. Quietly.

One named partner reads every request. Holders start with a private valuation. Organizations start with a confidential brief.