Measuring the use of a TLD from its public record

Someone tells you that a TLD has more than a thousand names under it. You are an operator deciding whether your namespace is alive, or a buyer deciding whether the figure in front of you means anything. The number is true, and you can verify it yourself. It still does not answer the question you care about, which is whether anyone uses the thing.

The good news is that an onchain TLD carries its own ledger. Every name issued under it is a public event with a time and a destination, and nobody has to hand you a dashboard for you to see it. The limit is that a ledger records what was written to it and nothing else. It holds issuances, transfers and records. It holds no visits, no people and no reasons.

This article is about measurement, not about how to read a single entry. It gives you five measures you can take from the record, the traps in each, a worked example with assumed figures, and a plain statement of the questions the record will never answer.

What the record of a TLD lets you count

An onchain TLD is a token held in a wallet, and each name issued under it is a further entry in the same public ledger. On Freename, the wallet that holds the TLD is the only one able to issue names under it. None of this passes through the DNS that ICANN coordinates, so a name works only in software built to support it. That is all the background this subject needs.

For measurement, the useful property is that issuing a name leaves a trace. A block explorer, which is a public website that displays the contents of a blockchain, shows that trace to anyone. From it you can take four kinds of count.

Names issued. How many names exist under the TLD. This is a stock: a total at a moment you choose.

When they were issued. Each issuance carries the time of the block it was written in. A stock becomes a flow once you sort it by date.

Where they sit. Each name is held by a wallet. Counting the distinct wallets tells you how widely the names are spread.

What was done with them. A name can carry records, such as the wallet address it points to or the location of a website. Where those records are written onchain, you can count how many names have at least one.

A fifth count sits on top of the four: movement after issuance. A name that passed from one wallet to another has a second event in its history, and that event is public too.

What the record cannot tell you about use

Before the framework, the limits. They are not footnotes. They decide how much weight any of the five measures can bear.

The record does not count visits. A website published under a name can be opened a thousand times or never, and the ledger looks the same in both cases. Opening a page does not write to a blockchain. If you need traffic, you need the analytics of the site itself, and those belong to whoever runs it.

The record does not count people. A wallet is a key pair, not a person. One person can hold twenty wallets, and one wallet can belong to a company with forty staff. Every statement you make about “holders” is a statement about wallets, and you should write it that way in any memo.

The record does not show intent. A name issued to a wallet may be a customer who wanted it, a test by the operator, a gift nobody asked for, or a name bought to be resold. The ledger shows the same event for all four.

The record does not show payments made to a name. When someone pays pay.yourbrand, the wallet software as a rule turns the name into an address and sends funds to the address. The transaction on the ledger mentions the address, not the name. You cannot count “payments to names” from the record of the TLD.

The record does not show lookups. Each time a wallet resolves a name, it reads the ledger. Reading is free and leaves no trace. There is no public counter of how often a name was resolved.

Finally, the record may not show every record. Whether a given type of record is written onchain or kept elsewhere depends on the registry and on the type of record. Before you count records, find out which ones your method can see, and say so beside the number.

A five-measure framework for a TLD

Five measures cover what the record supports. Each answers one question, and each has a known way of misleading you. Take all five together. Any one of them alone can be made to look good.

Two rules make the framework honest.

First, split every measure in two: the names in the wallet that holds the TLD, and the names everywhere else. The holder’s wallet is visible on the record of the TLD itself, so the split costs nothing. Names the holder issued to itself are inventory. Names in other wallets are distribution. Adding them together produces a total that describes neither.

Second, fix the date. A count is a photograph. Write down the day you took it, and take every measure on the same day. Two measures taken a month apart cannot be divided by one another.

The sections that follow take the first four in turn. Movement after issuance has its own entry in the questions at the end.

Names issued: a weak total and a telling curve

The total number of names is the figure everyone quotes and the one that says least. It is the easiest to raise. Since the holder of the TLD is the one who issues names, the holder can raise the total at will by issuing names to its own wallet.

There is nothing improper in that. An operator preparing to open .yoursector will often issue the names it wants to keep for its own functions, or the names it intends to hold back from registration, before anyone else arrives. That is ordinary housekeeping. It simply is not use.

So the first thing to do with a total is to apply the split. Only the names outside the holder’s wallet are a candidate for “use”. Even then it is an upper limit. Some of those other wallets may belong to the operator, its staff or its partners, and the record will not tell you which. You can ask. An operator who measures its own TLD knows the answer and should record it. A buyer should ask the seller to identify the wallets the seller controls, and should treat every unidentified wallet with many names as a question, not as a customer.

Turning the total into a curve

A total tells you where the TLD stands. The dates tell you how it got there, and the path matters more than the position.

Group the issuances by period. A month is usually the right width: narrow enough to show a change, wide enough that a quiet week does not look like a collapse. Then look at the shape.

A single spike. Most names issued in a few days, then almost nothing. This is the shape of a batch: the holder issuing to itself, or one campaign. It tells you that someone was once busy. It says nothing about what is happening now.

A spike and a tail. A burst at opening, then a lower, steady rate. This is the common shape of a namespace that opened to the public and settled. The tail is the number to watch. The burst is history.

A slope. No dramatic opening, a rate that holds or rises. This is the rarest shape and the most reassuring, because nothing in it depends on one event.

Steps. Flat periods broken by sudden jumps. Each jump usually has a cause outside the ledger: a partner brought its members in, or a product began issuing names to its users. Find the cause of each step. A namespace that grows only when one partner acts depends on that partner.

Run the curve twice, once for all names and once for names outside the holder’s wallet. The two curves often tell different stories, and the second is the one about distribution.

Distinct wallets: spread is not headcount

Count the wallets that hold at least one name under the TLD, leaving out the holder’s own. This is the measure people most want to read as “users”. It is not that, for the reason already given: wallets are not people. It is still one of the most useful measures, as long as you read it as spread.

Three figures come out of the wallet count.

Names per wallet. Divide names outside the holder’s wallet by the number of wallets that hold them. An average near one means names went out singly, which is what individual registrants look like. A high average means a few wallets hold many names each.

The share of single-name wallets. An average hides the distribution. Count how many wallets hold exactly one name. A namespace where most wallets hold one name and a handful hold dozens is two populations, and you should describe them separately.

Concentration at the top. Sort the wallets by the number of names they hold and look at the largest few. If a small number of wallets hold most of the names outside the holder’s own, the spread is thin whatever the wallet count says.

Wallets with many names are not a bad sign in themselves. A company that issues a name to each of its branches from one treasury wallet looks exactly like a speculator on the ledger. The difference lies in what happened next, which is what the fourth measure is for.

The wallet count can also be inflated. Creating a wallet costs nothing, so a party that wanted to appear as a hundred registrants could do so. You cannot rule this out from the record alone. What you can do is look for the signs that usually accompany it: many wallets created close together, each receiving one name within a short window, none of them ever setting a record or doing anything else. That pattern does not prove anything. It tells you the wallet count deserves less weight than it would otherwise carry.

Records set: the closest the ledger comes to use

A name with no record is a label in a drawer. A name with a record has been pointed at something: a wallet address so that it can receive funds, or the location of a site. Setting a record takes a deliberate act by whoever holds the name. That makes “names with at least one record” the best single signal the ledger offers that a name was meant to work.

Read it as configuration, not as activity. The measure says that someone took the trouble to set the name up. It does not say that anyone ever sent funds to it or opened the site.

Three refinements make the measure sharper.

Which record. An address record and a website record are different commitments. Pointing a name at an address you already have takes a moment. Publishing a site takes work. Count the two separately where the record lets you.

Changed since. A record set on the day of issuance and never touched may be a default or a forgotten setup. A record that was updated later shows continued attention. Where the history of changes is visible, the number of names whose record changed at least once after it was first set is a small but meaningful count.

Whose names. The split matters here more than anywhere. Names an operator keeps for safekeeping rarely carry records, and mixing them into the rate hides how the distributed names behave.

For names that carry a website record, you can go one step past the ledger and open the site in software that supports it. Resolution is partial and changes over time: a wallet, a resolver or a browser extension that handles these names does not mean every browser does. The page on what works with onchain TLDs and where is the place to check the state of support, and the page on names that resolve in wallets covers the wallet side. Opening a sample of sites tells you whether the records lead anywhere. It is a manual check, not a count, and you should report it as a sample.

A worked example: 1,200 names, 410 wallets, 300 records

This is an example with assumed figures. It describes no real TLD. The TLD is called .yoursector, and every number below is an assumption stated here so that you can follow the arithmetic.

The assumptions:

• 1,200 names exist under the TLD on the day of the count.
• They are held by 410 distinct wallets, one of which is the wallet that holds the TLD.
• 300 of the 1,200 names have at least one record set.
• The holder’s wallet holds 500 of the names, and 20 of those have a record.
• Of the other 409 wallets, 290 hold exactly one name.
• Names outside the holder’s wallet were issued over twelve months: 400 in the first three and 300 in the nine that followed.

Start with the headline figures as they would be quoted. There are 1,200 names across 410 wallets, an average of 2.93 names per wallet. One name in four, 25.0 percent, has a record. Read like that, the TLD looks moderately spread and lightly configured.

Now apply the first rule and split off the holder. The holder’s wallet has 500 names, which is 41.7 percent of the total. That leaves 700 names in 409 wallets. The average falls to 1.71 names per wallet. The namespace is smaller than the headline said, and more evenly spread.

Look at the distribution inside those 409 wallets. With 290 of them holding one name each, 70.9 percent of wallets are single-name wallets. The remaining 119 wallets hold the other 410 names, an average of 3.45 each. So there are two populations: a majority of wallets that took one name, and a minority that took a few. Neither looks like a single party holding the lot.

Then the records. Of the 300 names with a record, 20 are the holder’s, which leaves 280 among the 700 names in other wallets. The rate of configuration outside the holder is 40.0 percent, not 25.0. Inside the holder’s wallet it is 4.0 percent, which is what inventory looks like. The blended figure understated how the distributed names behave by a wide margin.

Names issued, all wallets1,200

Names outside the holder's wallet700

Distinct wallets, holder included410

Names with a record set300

Assumed figures for an invented TLD. The bars show counts from the record only; visits, lookups and payments are not measured.

Last, the curve. The 700 distributed names arrived at about 133 a month for the first three months and about 33 a month for the next nine. The opening rate was four times the later one. That is a spike and a tail. Whether 33 a month is healthy depends on what the operator set out to build. What the curve rules out is the reading that the namespace is growing as fast as its total might suggest.

How to run the count yourself

The method matters as much as the result. A count that cannot be repeated cannot be compared with the next one, and comparison over time is where measurement earns its keep.

1. Fix the date and the sourceChoose the day of the count and the block explorer or data export you will use. Write both down. Use the same source every time.
2. Identify the holder's walletRead it from the record of the TLD. If the holder controls other wallets, ask for them and note that the answer is a statement, not an observation.
3. Extract every issuanceFor each name: the name, the time it was issued and the wallet that holds it on the day of the count.
4. Split and countSeparate the holder's names from the rest. Count names, distinct wallets, single-name wallets and the largest wallets on each side.
5. Count recordsNote which types of record your source can see. Count names with at least one, by type, on each side of the split.
6. Build the curveGroup issuances outside the holder's wallet by month and note the cause of any jump you can explain.
7. Write the limits beside the numbersState what was not measured and which figures rest on someone's statement. Keep the file so the next count can be compared with it.

What an operator and a buyer each take from the numbers

The same five measures serve two readers with different questions. An operator measures to steer. A buyer measures to test a claim.

For an operator, the measure that most often points to a fixable problem is the gap between names issued and names configured. A registrant who took a name and never set a record may have found the setup unclear. That is a matter of instructions and onboarding, and it is within your control. The page for operators of a market TLD covers the wider work of running a namespace.

For a buyer, the measures frame what you are being offered. Names already in third-party wallets stay with those third parties when a TLD changes hands, so the distributed names are a fact about the namespace you would inherit, not an asset that transfers to you. Names the seller holds itself can pass with the TLD if the two of you agree. The split you made in the count is therefore also the split in the deal.

Use counts with restraint in pricing. A measured base of configured names in many wallets supports the view that the namespace has a function. It does not convert into a price by formula. If you want to see how registrations under a TLD might translate into income under assumptions you choose, the subname revenue calculator lets you test them, and the page on how a TLD valuation is built sets out what else goes into the figure.

Putting your first count on paper

Pick one TLD and one day, and produce a single page. At the top, the five measures, each split between the holder’s wallet and everyone else. Below them, the monthly curve of distributed names. At the bottom, three lines: which record types your source could see, which figures rest on a statement and not on the record, and what you did not measure. That last line should always include visits, lookups and the number of people.

If you operate the TLD, put the next count in your calendar before you close the file. If you are a holder thinking about a sale, the same page belongs beside your TLD readiness score, and it is better prepared by you than reconstructed by a buyer. If you are a buyer, make the count yourself before you read the seller’s version, then compare the two and ask about each difference.

A count like this is also what a sale or an acquisition file starts from. Hush Partners works on onchain TLDs under mandate, for a holder who wants a buyer or for an organization that wants a holder found and approached. The page for holders explains how a file starts, and the desk is reached through the contact form.

Questions people ask

How often should a count be repeated?

There is no fixed rule. Match the interval to the pace of the namespace: every month while names are going out steadily, less often once it is quiet. What matters more than the interval is that each count uses the same source, the same split and the same list of record types, so that two counts can be set side by side.

How often do names under a TLD change hands, and does it matter?

It varies from one namespace to another, and the record shows each transfer. A steady trickle of transfers between unrelated wallets suggests that names have a value to someone other than their first registrant. Transfers that run back and forth between a small set of wallets suggest the opposite of what they appear to show.

Is there a threshold that separates a used TLD from an unused one?

There is no accepted threshold, and you should be wary of anyone who offers one. A namespace built for the staff of one organization may be fully used with a few dozen names. Judge the measures against what the TLD was meant to do, and against its own earlier counts.