# What an earlier creation date is worth
> How a holder or valuer should weigh the creation date of an onchain TLD: what the Freename patent says about first registration, and what it does not.
Source: https://hush.partners/what-an-earlier-creation-date-is-worth
Category: Market & ICANN
Published by Hush Partners.
---
Holders of onchain top-level domains often open a conversation about price with a date. The TLD was created early, before the string drew any attention, before anyone applied for it anywhere else, and the holder feels that this seniority must be worth something. Valuers hear the argument often enough that they need a settled way to answer it.
The argument has a real source. A granted U.S. patent describes a way of deciding which of two colliding names resolves, and the earliest date of creation is one of the things that method weighs. That is a fact, and it deserves a place in a valuation file. It is also a narrow fact, and most of the mistakes made with it come from stretching it into something it is not: a priority right, a defense, or a claim against an applicant in the DNS.
This article is for the holder who wants to know what the date adds to an asking price, and for the valuer who has to put the date somewhere in a reasoned opinion. It stays on value. It explains the patent only as far as a valuation needs.
US 12,401,618 B1the U.S. patent held by Freename AG
February 23, 2024the day the application was filed
August 26, 2025the day the patent was granted
Patent text as published on Google Patents; the grant was reported by Domain Name Wire.
## What the patent says about first registration, in brief
An onchain TLD is a top-level name that lives on a blockchain, as a token in its holder's wallet, and not in the ICANN DNS root. Because it sits outside that system, the same string can exist in more than one place: once onchain, once in the DNS, or in two onchain naming systems. That is a name collision.
The patent, held by Freename AG, addresses what software should do when it meets one. Its method is rules-based. Competing names are scored against a set of criteria, each carrying a weight, and the outcome of the scoring decides which name resolves. First registration, meaning the earliest date of creation, is one of those weighted criteria. The text also names a specific situation it has in view: a new ICANN TLD arriving on a string that an established web3 namespace already uses.
That is everything a valuer needs from the document. Read the claims themselves on Google Patents before you rely on any summary, this one included, and treat everything below as reasoning about value, not about patent law.
## Why a holder reads seniority as value
The instinct is not foolish. In most systems people know, being first counts. Trademark law in many countries gives weight to earlier use or earlier filing, with rules that differ from one country to the next. Domain registration in the DNS is first come, first served at the level of a single registry. Land registers, patent offices and company registers all turn on dates. A holder who has spent years around any of these systems arrives at an onchain TLD expecting the date to work the same way.
There is a second reason. The creation date of an onchain TLD is unusually easy to establish. The registry's record is open, and a block explorer, a website that displays the contents of a blockchain, shows it to anyone who looks. The moment the token came into existence is fixed in a transaction that nobody can backdate. Few assets come with a birth certificate that clean, and it is natural to assume that a fact so well evidenced must carry weight.
The error is in the step from "well evidenced" to "legally or commercially decisive". A date can be beyond dispute and still decide very little. What matters for value is what the date changes in the future of the asset: who can use the string, where it resolves, and what a buyer can do with it that they could not do with a TLD created later. The rest of this article works through those questions one at a time.
## One criterion among several: what a weight means in a valuation
The patent's method does not say that the earlier name wins. It says the earlier date is scored, alongside other criteria, and that the total decides. A valuer has to take that structure seriously, because it sets the ceiling on what the date can be worth.
### A weight is not a veto
In a weighted method, no single criterion settles the result unless its weight is large enough to outvote everything else. This article does not claim that first registration has that kind of weight, and you should not assume it without reading the claims. A holder who argues "I was first, so my name resolves" is describing a different method, one with a single rule. The patent describes several rules balanced against each other.
For value, this means the date improves a position without securing it. An older TLD enters a scored comparison with an advantage on one line. Whether that advantage survives depends on the other lines, which the holder may not control and may score poorly on.
### You cannot price the criteria you have not read
The patent text sets out its criteria. A valuer who wants to rely on the method should read them and ask, for the TLD in front of them, how it would fare on each. A valuation that cites first registration and stays silent on the rest is quoting half a formula.
In practice this pushes the valuer back toward the ordinary drivers of value. If the other criteria in a scoring method reward things that also matter commercially, then a TLD that is old but otherwise inert gains little, and a TLD that is old and well developed gains on several lines at once. Either way, the date alone is rarely the story.
### Earlier than what
Seniority is relative. A creation date only matters against a specific competing name. Against a name created later in another onchain system, the date is an advantage on that criterion. Against a name created earlier, it is a disadvantage. Against nothing, because no collision exists, it has no role to play in a collision method at all.
So the first question a valuer asks is not "how old is this TLD" but "older than which other name, and where". A holder who cannot point to a present or plausible collision is offering an answer to a question nobody has asked yet.
## A method, not a ruling: three limits on the date
The second group of limits concerns the nature of the document. A patent grants its owner rights over an invention for a period and within a territory. It describes a method. It does not adjudicate anything.
### It decides nothing between two parties
A ruling settles a dispute between named parties and can be enforced. A patent does neither. If you and another holder disagree over a string, the patent gives neither of you a remedy. It tells you how one company's described method would rank the two names if that method were applied. A valuer should never write "priority" in a report on the strength of the patent, because priority is a legal conclusion and the patent contains none.
### It applies only where the method runs
A resolution method has effect in the software that implements it. A patent tells you that a method has been described and protected. It does not, by itself, tell you which resolvers, wallets or browsers apply it, or how the weights are set in any given product. A resolver is the piece of software that turns a name into an address or a record, and each one follows its own rules. Outside software that applies the scoring, the creation date has no effect on resolution at all.
For value, this is a question of reach. An advantage that operates in part of the resolving software is worth less than one that operates everywhere, and coverage of onchain names is itself partial and changing.
### It has a holder, a territory and a term
A patent belongs to its owner, covers the countries where it was granted, and expires. Other naming systems are free to resolve collisions in other ways, and other methods may weigh dates differently or not at all. A valuation that leans on the date is therefore leaning on one company's approach, in the places and for the time that approach applies. That is a dependency, and a careful report says so in plain words.
## What the date cannot do against an ICANN registration
This is the limit that matters most, and the one holders most often get wrong.
ICANN coordinates the DNS root, the authoritative list of top-level domains that ordinary browsers, email and most internet software rely on. It decides what enters that list through its own application rounds, under its own rules, contracts and dispute procedures. A patent held by a private company does not change them.
Three consequences follow for a holder.
First, an earlier onchain creation date cannot block an application for the same string in the DNS. The applicant applies to ICANN, ICANN evaluates under its own criteria, and the existence of an older onchain TLD is not, on the strength of this patent, a ground for refusal.
Second, the date cannot stop a delegated TLD from resolving. Once a string is in the DNS root, every ordinary browser reaches it without any extension or special support. The onchain TLD of the same string continues to exist, and continues to resolve where onchain names are supported, but the two now coexist. The patent's method speaks to what collision-aware software does in that situation. It does not remove the DNS version from the internet.
Third, the date is not a claim for payment. An applicant in an ICANN round owes nothing to the holder of an older onchain TLD because of the date. A holder who writes to an applicant asserting seniority as a right is asserting something the patent does not give. It is also a poor way to open a commercial conversation, and it can expose the holder to legal risk that varies by country. Your own counsel decides what you may say and to whom.
The honest summary for a valuer is that the DNS is the stronger system on reach, and the creation date does nothing to close that gap. The page comparing an [ICANN dotBrand and an onchain TLD](/dotbrand-vs-onchain-tld) sets the two side by side on the criteria that matter.
| Question | What the date does | What it does not do |
| --- | --- | --- |
| A collision scored by the patent's method | Counts on one weighted criterion | Decide the outcome alone |
| A dispute with another holder | Supplies a clean, public fact | Give a remedy or a right |
| An ICANN application for the string | Nothing under ICANN's rules | Block, delay or condition it |
| A buyer's diligence | Dates the start of the record | Replace the other checks |
## Where an earlier creation date does add value
None of this makes the date worthless. It makes it specific. There are four places where an earlier date helps, and a valuer can name each of them without overstating.
### A favorable position in a described method
Within software that applies a scoring of the kind the patent describes, an earlier date is better than a later one. That is a real advantage on one criterion. A buyer who expects collisions on the string, and who expects collision-aware resolution to matter in the wallets and browsers their audience uses, may reasonably prefer the older of two otherwise similar TLDs. The valuer records this as a preference, not as a protection.
### A longer and cleaner history
An older token has more history on the public record: how long one wallet has held it, whether it moved, what names were issued under it and when. A long, quiet history under one holder is easier for a buyer to accept than a short one with several transfers. This has little to do with the patent and a great deal to do with diligence. Age here is evidence of stability.
### A simple story about good faith
The date can show that a TLD was created before a particular event: before a company adopted a name, before a product launched, before a string was applied for in the DNS. Where that is true, it supports the holder's account of why the TLD was registered. It does not settle a trademark question, which turns on rights, use and the law of each country, but it removes one common suspicion from the conversation. Where the date falls after such an event, the same logic works against the holder, and a valuer should say so.
### The terms the TLD was registered under
Registry terms can change over time, and a TLD keeps a link to the terms it was registered under. On Freename, the royalty program normally carries an annual cost set by the registry, but some older registrations have it for life. Ask the registry, before closing, whether those older terms would pass to a buyer. This is the one case where an earlier date can carry a concrete economic difference, and it comes from the registry's terms, not from the patent. A valuer treats it as a separate line with its own confirmation step.
## How a valuer places the date in an opinion
A valuation of an onchain TLD usually rests on a small number of drivers: the string itself and who would want it, what can be done with the TLD where it resolves, the names issued under it and what they earn, and the condition of the record. Our page on [how a TLD valuation is built](/valuation) covers the desk's approach. The creation date is not one of the drivers. It is a modifier that acts on some of them.
The practical rule is to place the date according to the situation the TLD is in, and to write down which situation that is. The table below gives the four that come up.
| Situation of the TLD | Role of the date | Treatment in the opinion |
| --- | --- | --- |
| No known collision on the string | Background fact | Noted in the record section, no adjustment |
| Same string in another onchain system | One scored criterion | Qualitative factor, with the other criteria reviewed |
| Same string applied for in the DNS | Coexistence, not priority | Risk described, date given no blocking effect |
| Earlier registry terms attached | Possible economic difference | Separate line, subject to registry confirmation |
Three working habits keep the opinion honest.
Describe, do not quantify. Nothing in the patent converts months of seniority into money, and inventing a formula gives a false precision that a buyer's adviser will take apart. A sentence that says the date is a favorable qualitative factor in a named situation is stronger than a number nobody can defend.
Separate the date from the things it travels with. An older TLD may well sit on a shorter, more generic string, since obvious words tend to be taken first. That value belongs to the string. If the valuer credits the string for its quality and then credits the date again for the same reason, the same advantage has been counted twice.
State the dependencies. If any part of the opinion relies on collision-aware resolution, name the software where that matters and say that coverage is partial and changes. The page on [what is live on onchain TLDs](/whats-live) keeps a sourced account of where onchain names resolve, which is a better basis than an assumption.
## Putting the creation date on file so it survives diligence
A date that is worth mentioning is worth documenting properly. A buyer's adviser will check it, and a holder who has already assembled the record saves both sides time. The procedure is short and involves nothing beyond public information and the holder's own papers.
Documenting the creation date of a TLD
Locate the creation recordFind the transaction in which the token for the TLD was created and note its reference. A block explorer shows it, and the buyer's adviser will look at the same page.
Record the date as the chain shows itWrite down the date and time shown for that transaction, with the time zone the explorer uses, so that two readers arrive at the same day.
Trace the holding historyNote every transfer of the token since creation. A TLD that has never moved is the simplest case; one that has moved needs each step explained.
Keep the terms that appliedFile the registry terms you accepted when you registered, and any confirmation from the registry about the program terms attached to the TLD.
Set the date against outside eventsWhere it helps your account, note what the date precedes or follows, such as a product launch or an application for the string, with a source for each.
Write one neutral paragraphSummarize the facts without the word priority and without a conclusion about rights. Leave the conclusion to the reader and their counsel.
The last step matters more than it looks. A file that states facts invites agreement. A file that argues a legal position invites a counter-argument, and the counter-argument on this subject is strong. The [TLD Readiness Score](/tld-readiness-score) is a quick way to see what else a buyer will expect to find in the file beyond the date.
## Four ways holders overplay the date
The same errors recur, and each one costs credibility at the moment the holder needs it.
**Calling it a right.** Words such as priority, seniority right or prior claim suggest a legal position. The patent supplies none. A buyer's lawyer who reads those words will check them, find nothing behind them, and discount the rest of the file.
**Citing the patent as if it were a decision.** A sentence such as "a U.S. patent confirms that the first registration prevails" is wrong on three counts: the patent weighs, it does not confirm; first registration is one criterion; and a patent is not a decision. The accurate sentence is longer and less exciting, and it is the only one that survives a reading of the source.
**Using the date as leverage on a DNS applicant.** The date cannot affect an application, so it is not leverage. Presenting it as such reads as pressure, and pressure on a trademark owner or an applicant tends to end conversations and may carry legal consequences depending on the country. If an applicant has a reason to want the onchain version of its string, that reason is commercial and stands without the date.
**Pricing as if time were running out.** Nothing about a creation date gets more valuable with a deadline attached. A buyer who is told that the date makes the TLD a last chance will correctly conclude that the argument has run out of substance.
A plain rule covers all four: say what the record shows, say what the patent describes, and stop there.
## Before you put the date in front of a buyer
If you hold a TLD and intend to raise its creation date in a conversation about price, do three things first.
Read the patent text on Google Patents and write down, in your own words, what it would mean for your string. If you cannot name a competing name that your TLD is earlier than, set the argument aside until you can.
Check whether the string has been applied for in the DNS. The reference is ICANN's list of applied-for strings, and Reveal Day is the name for the day of its publication. If your string is on that list, your position is coexistence with a system of wider reach, and your valuation should be written on that basis. If it does not, the collision the patent has in view does not arise from that side.
Assemble the file described above, with the registry terms and the holding history next to the date, and have your own counsel read the summary paragraph before anyone else does.
If you want a view of where your date sits in the whole picture, you can ask Hush Partners for a [private valuation](/private-valuation) through the form on the site. There is a page written for [TLD holders](/holders), and whatever you send falls under the desk's standard mutual [NDA](/nda).
## Questions people ask
### Does an older TLD always sell for more than a newer one?
No. Where age and price seem to move together, the string is the likelier cause, because obvious words tend to be taken first. Two TLDs of similar quality with different creation dates may trade on terms that have nothing to do with the date, and a recent TLD on a strong string can be worth far more than an old one on a weak string.
### Does the creation date change when the TLD is sold?
The creation of the token is a fixed event on the public record, and a transfer to a buyer's wallet is a separate, later event. The buyer acquires the same token with the same creation record. What may not carry over automatically are registry terms attached to the original registration, which is why they are confirmed with the registry before closing.
### Can two onchain TLDs on the same string both claim to be first?
Each naming system records its own creation dates, so two tokens for the same string in two systems each have a true date. Which one is earlier is a matter of comparing the two public records. Which one resolves in a given wallet or browser depends on the rules that software follows, not on the comparison alone.
### Should a buyer pay for a patent search or legal opinion on the date?
That depends on how much of the price rests on the date. Where it is a background fact, the public record is enough. Where a buyer's plan relies on collision-aware resolution favoring the TLD, an opinion from the buyer's own counsel on the patent and on the law of the relevant countries is a reasonable cost of diligence.