How much do names under a TLD add to its value
A TLD can earn from the names registered beneath it. How to model that revenue honestly, and how much weight a buyer gives it.
Projected revenue from names registered under a TLD is one of the figures most often cited in a sale conversation, and one of the most often misread. The arithmetic is not complex. The difficulty is in the inputs: three numbers that look precise on a spreadsheet, each carrying a range of plausible values wide enough to change the conclusion entirely.
This article builds the model step by step, using a single worked example with every assumption stated. It then tests each assumption in turn, identifies which one dominates the result, and explains how a buyer reads the projection when the time comes to negotiate. The goal is not to tell you what your TLD will earn. It is to give you the tools to reason honestly about what it could earn, and to understand the discount a buyer will apply to that figure.
If you want to run the numbers against your own assumptions before going further, the Subname Revenue Calculator on this site estimates revenue from names issued under a TLD.
Royalty share and renewal fee as published by Freename, subject to the registry's current terms.
Where the money comes from
On Freename, a TLD is recorded onchain as a token held in a wallet, and only the holder of that TLD can issue names under it. The registry also runs a royalty program: the holder of a TLD receives a share of each registration fee for names registered under that TLD.
The share is advertised at up to half of the registration fee. It is subject to the registry’s current terms and to activation conditions. Do not model the ceiling as a certainty. Model it as the upper bound of a range, and confirm the terms that apply to your TLD before presenting any figure.
The price of a name is not handed to you by the registry. The holder of a TLD sets the registration fee for the names issued under it, and can price names differently, a short name above a long one for example. The fee is therefore the one input of the three that you decide, which is a reason to justify it and not a licence to inflate it. The holder also controls the work around the TLD: whether the royalty program is active, and whether anyone has a reason to register. The operators page explains what running a market TLD as an active namespace involves.
One feature helps the arithmetic. There is no annual renewal fee on a Freename TLD, so no recurring registry charge on the TLD itself is set against the royalty income. That does not make the income free. Taking part in the royalty program carries an annual cost, set by the registry, and it comes off the top of whatever the program pays. Some TLDs were registered under earlier terms that include the program for life; whether those terms pass to a buyer is to be confirmed with the registry before closing. Marketing, integration work and the time of the people who run the namespace are real costs, and a buyer will ask about them. They sit outside the registry, so they are easy to leave out of a model.
The three inputs and what makes each one hard
Every honest revenue model for a market TLD rests on three numbers.
Population. The count of people or organizations that could plausibly register a name under this TLD. For a TLD that matches a brand, such as .yourbrand, the population is bounded by the holder’s own organization. For a market TLD, one open to registrations by third parties, the population is the slice of people or organizations who find the word meaningful or useful. Defining that slice without inflating it is where most projections go wrong.
Adoption rate. The fraction of the population that actually registers in a given period. For a new or lightly marketed TLD, expect it to be small. Adoption is not inherent to the TLD. It is a function of distribution, integration and sustained demand. A name that can receive payments or that resolves in a wallet gives a registrant a reason to hold it, which a token with no use does not.
Adoption also has a structural limit that a model should state. The names in your model are onchain names, which resolve outside the ICANN DNS root, and an ordinary browser opens none of them unless support has been added. Coverage in wallets and browsers is partial and it changes. A member of your population who cannot use the name in the tools they already have is unlikely to pay for it, and no amount of marketing changes that.
Price per name. The registration fee for a name under this TLD, on which the holder’s share is calculated. The holder sets it, so use the fee you have actually set, or the one you can defend setting, and where you price names differently, model each price band on its own line.
The three numbers multiply together to produce gross registration revenue. The holder’s share is then applied. Each step is a multiplication, so an error in any one input passes through the whole chain at full strength. An adoption rate that is twice too high doubles the result, whatever care went into the other two.
A worked example, step by step
This is a worked example, not a forecast and not a typical case. Its only purpose is to show the mechanics. Consider an invented trade body that holds .yoursector, a TLD that is the common word for its sector, so that registrations by third parties are plausible. Here are the assumptions, all of them invented for the example:
- Population: 4,000 organizations in the sector that could find a
name.yoursectorname useful - Adoption rate: 1 in 20 registers in year one
- Price per name: USD 50 per registration, a round number chosen for the arithmetic and not a registry price
- Holder’s share: half of each registration fee, the advertised ceiling, used here to show the maximum case
- Count the registrationsMultiply population by adoption rate: 4,000 times 1 in 20 equals 200 registrations in year one.
- Calculate gross registration revenueMultiply registrations by price per name: 200 times USD 50 equals USD 10,000 in registration fees.
- Apply the holder's shareTake half of the gross figure: USD 10,000 divided by two equals USD 5,000 for the holder.
- Name what the figure isUSD 5,000 is the maximum case at the stated adoption rate. A lower share reduces it in proportion. Neither the annual cost of taking part in the royalty program nor the costs of running the namespace are included, and both must be deducted.
- Project forward with cautionThe figure counts registrations made in year one. A later year earns on the registrations made in that year, so USD 5,000 repeats only if new registrations keep arriving at the same pace. Do not layer growth on top without evidence for it.
Anyone presenting this figure to a buyer must show the assumptions alongside it. A buyer who sees only “USD 5,000 projected annual revenue” without the inputs cannot evaluate it at all, and will assume the inputs were chosen to flatter.
The last step deserves a second look, because it is where projections quietly inflate. A population of 4,000 is a stock, not a flow. If 200 organizations register in year one, the pool that has not yet registered is 3,800. Whether year two brings another 200 depends on whether the reasons to register have grown stronger, not on the calendar. A model that repeats the year-one figure for five years is assuming five years of steady new demand from the same pool. Say so if that is what you are assuming.
Sensitivity: what happens when one input moves
To see how the result responds, hold two inputs constant and move the third, using the same base case. The holder’s share stays at half in every row.
All figures computed from the worked example above, one input changed per row. The annual cost of the royalty program and the costs of running the namespace are not included. No external data used.
The first seven rows show that the model is symmetrical. Doubling any single input doubles the output, and halving it halves the output. That is simply what a product does, and on this evidence alone no input matters more than another.
The last row is there for a different reason. It asks which input could plausibly be wrong by a factor of ten. The answer to that question, not the shape of the formula, decides where a buyer looks first.
Why population is the input that matters most
Price and adoption rate are bounded in practice. A registration price can be doubled, but a price ten times higher for the same kind of name is hard to defend, and it would not leave demand untouched. An adoption rate can improve with good distribution, but it cannot approach the whole population for a sector word that competes with the naming habits people already have. The range of honest values for both inputs is fairly tight.
Population has no comparable limit, in either direction. A word that is relevant to a community of 4,000 produces a different order of revenue from one relevant to a community of 40,000, as the last bar of the chart shows. That difference cannot be reached by better marketing or a different price. It follows from what the word means and who finds it useful.
It is also the input that is easiest to overstate without noticing. The usual error is to start from the size of a whole sector and call it the population. Three filters bring the number back to something a buyer will accept:
- Relevance: those for whom the word actually describes what they do, not everyone in the wider industry.
- Reach: those you, or a buyer, have a realistic way to contact, through a membership list, a partner or a channel that already exists.
- Usability: those who can use an onchain name in the tools they already work with, given that resolution is partial.
Each filter removes part of the count, and the three compound. A population that has passed through all of them is smaller and far more useful, because every later number in the model now rests on people who could, in fact, register.
This is why the first question a buyer asks about a revenue projection is not what price you assumed but how you defined the population. A narrow, defensible population with a modest adoption rate is more credible than a large one justified by a general reference to market size. The buyer’s analyst will test the population first, because it is the number with the widest plausible range.
When you prepare a projection for a conversation about valuation, define the population with specificity: identify the segment, explain why that segment would want a name under this TLD, and state where the count comes from. A count taken from a published register or directory of the sector is easier to defend than one derived from a general estimate.
How a buyer reads a revenue projection
A buyer receives a projection with two questions in mind: is the arithmetic right, and are the assumptions honest? The second question does most of the work. A buyer who trusts the assumptions will accept the arithmetic. A buyer who doubts them will discount the entire figure, often heavily.
The evidence a buyer typically asks for falls into five kinds.
| Evidence | What the buyer looks for | Effect on the discount |
|---|---|---|
| Historical registrations | Actual count of names under the TLD, over time | Reduces it sharply: observed data replaces estimates |
| Population source | The register, directory or survey behind the count | Reduces it moderately: the number was not invented |
| Adoption comparables | A similar namespace’s registration rate, with its source | Reduces it slightly: comparables are rarely precise |
| Activation status | Confirmation that the royalty program is active on the TLD | Required: without it, the projection has no basis |
| Price confirmation | The registration fee the holder has set for names under the TLD | Required: a price never applied invalidates the arithmetic |
Registrations already made are public in a way that projections are not. The registry record is public and anyone can check it on a block explorer, so a buyer can verify a claimed count independently. That is why history carries so much more weight than any other row of the table.
Where the discount comes from
When no registrations exist, the common case for a TLD that has not been actively marketed, a buyer applies a significant discount. It reflects the gap between observed revenue and modeled revenue. A buyer who would pay a given multiple of demonstrated annual revenue will pay a materially lower multiple of projected revenue, because projected revenue may not arrive.
There is no standard figure for that discount, and you should distrust anyone who quotes one. It is better understood as the sum of the doubts the buyer has not been able to resolve. One doubt is whether the population is real. Another is whether the adoption rate can be reached, and at what cost. A third is whether the terms of the royalty program will still be the same when the registrations come. Each piece of evidence in the table removes one doubt, and the discount shrinks accordingly.
The buyer also deducts something the seller’s model usually omits: the cost of producing the revenue. If reaching the adoption rate requires a campaign, a partnership and a person to run them, the buyer is the one who will pay for all three. From the buyer’s side, the projection is not income waiting to be collected. It is the gross return on work that has yet to be done.
How heavily the discount weighs also depends on how much of the asking price the projection is asked to justify. A TLD where projected revenue explains a small part of the price is barely affected. A TLD where the projection is the main argument for the price is exposed: if the projection fails under scrutiny, the price fails with it.
When revenue belongs in the valuation and when it does not
Revenue from names registered under a TLD is a legitimate input to a valuation, on four conditions.
It belongs in the valuation when the royalty program is active, when the registration fee has been set by the holder and is stated, when the population is defined with specificity, and when the adoption rate is grounded in something: a comparable, a prior campaign, a waiting list, a partnership that creates distribution. If all four conditions are met, the projected revenue can reasonably support a component of the asking price.
It should be weighted near zero when the royalty program is inactive, when no names have been registered and no campaign has been run, when the population is a broad market size with no segment definition, or when the only evidence for adoption is the holder’s hope. In those cases, building the revenue figure into the asking price is a negotiating liability. A prepared buyer will use it to argue the price down, not up.
There is a useful intermediate position: present the revenue potential as an upside scenario for the buyer, not as part of the floor price. A buyer who intends to put the TLD to work after the transfer will form an independent view of what that work could yield. Showing your model honestly, with every assumption visible, helps the buyer calibrate that view without tying you to a number the buyer will contest.
In practice this means keeping two figures apart. The first is what the TLD is worth as a namespace under one holder’s control, whether or not anyone ever registers a name. The second is the revenue that a holder who operates it could reasonably pursue. The two serve different purposes in a negotiation, and a price that blends them is harder to defend than one that shows each on its own line.
Stress-testing the assumptions before you present them
Before a projection reaches a counterparty, test each assumption yourself.
On population: Could a skeptical analyst cut this number in half and still be reasonable? If so, present the halved figure as the base case and the original as the upside. In the worked example, that means leading with USD 2,500 and showing USD 5,000 as what a wider reach could add. A projection that survives the halving of its population is far more durable in negotiation than one that needs the full number to hold.
On adoption rate: What would have to be true for this rate to be achieved? If the answer requires a marketing campaign, a distribution partnership or an integration that does not yet exist, the rate belongs in a scenario labeled “with activation”, not in a base case.
On price: Is the fee in your model the one you have set for names under the TLD, or one you only intend to set? The price is the holder’s decision, and it can differ from one name to another, so state which names carry which fee, keep a record of when you set it, and remember that the buyer, once holder, is free to change it.
On the holder’s share: Is the royalty program active on this TLD? The share is subject to activation conditions. A projection built on the advertised ceiling is only valid if you have confirmed that the ceiling is the share that applies. Do not model an inactive program as if it were live.
On the names you issue yourself: Does the projection count names that pay no fee? The royalty is a share of a registration fee. A holder who plans to issue names to its own staff, members or partners at no charge should not expect those names to produce a share, because there is no fee to share. Check the registry’s terms on the point, and keep the two pools of names separate in the model.
A model that has passed these five tests is usually smaller than the one you started with. That is the intended result. The smaller figure is the one that will still be standing at the end of a buyer’s review, and a figure that survives review is worth more in a negotiation than a larger one that does not.
Using the calculator and preparing for a valuation conversation
Start by running your own three inputs through the calculator linked at the top of this article. Then run them again with the population halved, and once more with the adoption rate you could defend to a stranger. Keep all three results. Together they are a range, and a range is a more honest thing to bring to a buyer than a single figure.
The calculator is a starting point, not a finished argument. What it produces is an estimate resting on your assumptions. The work of a valuation conversation is to make those assumptions credible to a counterparty, with the evidence in the table above.
Next, write the assumptions down in one page: the segment and the source of its count, the basis for the adoption rate, the registration fee and when you set it, the status of the royalty program, and the costs a buyer would bear to reach the figure. If you cannot fill a line, that line is where the discount will come from.
If you hold a TLD and want to know what it is worth before you approach anyone, you can request a private valuation from Hush Partners. Every exchange is covered by the standard mutual NDA. The TLD Readiness Score, another free tool on the site, scores how ready a TLD is to be sold, which is a wider question than revenue.
Hush Partners is a private desk for onchain TLDs. It acts for holders who mandate it to find a buyer, and for organizations that mandate it to find and approach a holder. In either case, a projection that arrives with its assumptions and its evidence is easier to place in front of the other side than one that arrives as a single number.
Questions people ask
Does a higher price per name always mean more revenue for the holder?
Only if demand does not react to price. In practice, a very high price per name reduces the number of registrations, and price times registrations may be lower than at a moderate price. The model above treats registrations as independent of price, which is a simplification. For a realistic projection, ask whether your population would still register at the price you are modeling.
If the TLD has never had a registration, is revenue relevant to the price at all?
It can be, as a scenario on the buyer’s side and not as a floor on the seller’s side. A TLD with no registrations has no demonstrated revenue, but a buyer who intends to operate it as a namespace may value the revenue they expect to create. That potential belongs in their model, not automatically in the asking price.
How does a TLD that matches a brand differ from a market TLD for revenue purposes?
When the holder is the only party using names under the TLD, as with .yourbrand and names such as pay.yourbrand, there are no registrations by third parties and so no royalty revenue to model. The value lies in the control of the namespace and in the uses the holder puts it to. Revenue from registrations is a characteristic of market TLDs, and the two types call for different valuation approaches.
What happens to the royalty after a transfer?
Do not assume. The TLD is a token, and at closing it moves to the buyer’s wallet through onchain escrow. Whether the royalty program stays active for the new holder, and on what conditions, is a matter for the registry’s terms at that time. The same goes for the annual cost of the program: where the seller’s TLD was registered under earlier terms that include the program for life, it is for the registry to say whether the buyer inherits them. A buyer acquiring a TLD for its revenue potential should confirm the point with the registry before closing, and a seller should expect to be asked.
