Onchain names in a corporate domain portfolio

A corporate domain register is built on a few quiet assumptions. Every entry has a registrar, an expiry date and a set of name servers. Every entry can be renewed, locked, transferred or allowed to lapse from one account. Whoever designed the spreadsheet or the portfolio tool did not have to think about any of this, because every domain in the DNS works that way.

Then someone in marketing, product or legal tells you the company holds a name on a blockchain, or is about to. It may be a top-level domain that matches the brand, such as .yourbrand, or a single name under a shared suffix. It does not appear in the registrar portal. Nobody can tell you when it expires, and the honest answer may be that it does not. The question lands on your desk anyway, because you are the person who keeps the list of names the company owns.

This article is about that list. It covers where onchain names sit next to DNS domains in the register, which columns have to be added, which of your usual services stop at the edge of the DNS, how to treat an entry with no renewal date, and what to send to legal. It does not argue for or against holding such names. It assumes the company holds one, or soon will, and that you want the record to be right.

Why the domain manager inherits the onchain entries

Onchain names rarely arrive through the domain team. They arrive through a product pilot, a brand protection purchase, an agency, or an employee who registered something on a personal initiative and mentioned it months later. Each of those routes produces an asset that the company controls in practice and that no central record describes.

The domain manager is the natural owner of the record. You already run the processes the new entries need in a modified form: inventory, ownership checks, periodic review, reporting. And you are the person an auditor or a new general counsel will ask for the full picture.

Owning the record is not the same as being custodian of the asset. For a DNS domain the two roles sit together in the registrar account you administer. For an onchain name they separate. The control sits in a wallet, which is usually run by treasury, security or a custody provider. Your job is to make sure the register says so, accurately, and that the person named in it would agree.

A useful starting rule: one register, two entry types. A separate spreadsheet kept by another team drifts out of date. A second record type in the same tool, with its own columns, keeps the names in front of the same people on the same review cycle.

What an onchain name is, in the terms of a register

An onchain name is a name recorded on a blockchain by a naming registry instead of in the DNS. On Freename, the registry this article uses as its reference, a TLD exists as a token sitting in a wallet. Whoever controls that wallet is the holder, and the holder alone can create names beneath the TLD, such as pay.yourbrand.

For register purposes, three consequences matter. There is no registrar account, so nothing in your portal can show the name or act on it. Control is a matter of who can operate the wallet, so the register must name the wallet and its custodian. And the name is resolved outside the DNS that ICANN coordinates, so a browser needs added support to open it and none of your DNS tooling sees it. The glossary defines the terms used below.

A DNS domain entry and an onchain name entry, side by side

The clearest way to see the difference is to put the two entry types in adjacent columns and read down. Some fields carry over unchanged. Some carry over with a different meaning. A few have no counterpart at all, and a few new ones appear.

The second column describes a system with intermediaries at every step, each giving you a control and a recourse. The third describes a shorter chain: a registry, a wallet, a holder. That is why the entry needs more care on custody and less on renewal.

The table also shows why you cannot reuse the DNS record type with a few cells left empty. An empty expiry cell normally means missing data. An entry type of its own tells the reader that the absence is a property of the asset.

The columns your register does not have yet

A register for onchain names keeps the business columns you already use: the brand or business unit the name belongs to, the internal owner, the purpose, the cost center, the date acquired and the status. It adds the following.

A few of these deserve a comment.

Holding wallet. Record the public address in full, copied and pasted, never retyped. It is not a secret; it is the equivalent of naming the registrar account. What is secret is the key material that operates the wallet, and that never goes in the register. Record where the key procedure is documented and who owns that document, not the procedure itself.

Custodian. Name a role or a team first and a person second. A register that says a named individual holds the company’s TLD describes a risk, and writing it down is the first step to fixing it.

Record link. The registry record is open to anyone through a block explorer, a website that displays what is written on a blockchain. Storing the link lets you, legal or an auditor confirm in a minute that the name still sits in the wallet the register names.

Registry terms. Naming registries each write their own terms. Record which terms applied when the name was acquired, and whether the name takes part in any program that carries its own conditions. On Freename, for instance, a TLD holder can join a royalty program that pays a share of registration fees for names under the TLD; taking part has an annual cost that the registry sets, except where a TLD was registered on earlier terms that cover the program for life. Which regime applies is a register fact.

Resolution note. Support is partial and it changes. For Freename names it covers Bitcoin.com Wallet, MetaMask by way of Freename’s resolver, and desktop browsers that have the Freename Web3 extension installed. Your note should say where your own team has tested the name and on what date the test was run, so nobody reads the entry as a promise that the name works everywhere. The page on what works now is a reasonable reference to check a note against.

What the corporate registrar does not do for onchain names

A corporate registrar bundles a long list of services around DNS domains. It helps to unpack the bundle, because each item is something you will have to source elsewhere, do yourself, or consciously go without.

Consolidated inventory. The portal shows every domain in the account, and exports feed your register. An onchain name is not in the account. Unless your provider has built a specific service for it, the register is updated by hand from the public record.

Renewal management. Auto-renewal, consolidated invoicing and expiry alerts are the heart of the service. For a name with no renewal there is nothing to manage. For a name on a registry that does charge a periodic fee, the reminder is yours to set.

Locks. Registrar lock and registry lock stop a domain from being transferred or changed without extra verification. No equivalent exists at the registrar for an onchain name. The protection is in how the wallet is set up: who can approve a transaction, how many people must agree, where the keys are kept. That is a conversation with security, and the register only records its outcome.

Recovery. If a domain account is compromised or a name is transferred in error, there are people to call: the registrar, the registry, and in the end a dispute process. A token moved out of a wallet by someone with the keys has in general no administrator who reverses the transfer. The DNS is better here.

DNS hosting and certificates. Zone management, DNS security extensions and certificate services apply to DNS domains only. An onchain name carries its own records, set by the holder through the registry’s tools.

Monitoring. Many providers watch new domain registrations for names that resemble your marks. Check whether that watch covers onchain naming systems before assuming it does. If it does not, onchain names that resemble the brand need a separate watch, which is what a namespace watch is for.

None of this is criticism of registrars. Their services were designed around the DNS and its contracts, and they do that work well. Some may offer help with onchain names, so ask your account manager in writing which of these services extend to names recorded on a blockchain registry, and record the answer.

Renewal dates and the entries that have none

Much of domain management is calendar management, so the first thing a domain manager asks about a new asset is when it renews.

For a Freename TLD the answer is that it does not. No annual fee is due to keep the TLD, and no expiry date is attached to it. That removes the lapse risk that every DNS domain carries. It does not mean the entry has no dates.

Three kinds of date can still apply, and the register should distinguish them.

The first is a registry date on the name itself. Renewal is a property of each registry and sometimes of each type of name within it. Some naming systems charge a periodic fee to keep a name; others charge once. Names issued under a TLD may be subject to different rules from the TLD above them. Do not infer the rule for one entry from another: read the terms for each, and record either a date or the words “no renewal” with the source.

The second is a program date. A holder who takes part in the Freename royalty program meets an annual cost for that program, unless the TLD sits under the earlier lifetime terms. The TLD itself carries no renewal fee, so this date concerns the program only. What a missed payment means is set out in the registry’s terms, and the date belongs in the calendar.

The third is a review date that you set yourself. This is the one that matters most. In the DNS, the renewal invoice forces someone to look at each domain at least once a year and decide whether to keep it. An asset that never asks for money never forces that look. Left alone, the entry will outlive the project it was acquired for, the person who acquired it and the memory of where the keys are.

So give every onchain entry a review date, on the same cycle as your portfolio review. At each review, confirm four things: the public record still shows the name in the wallet the register names, the custodian is still the right team and can still operate the wallet, the purpose in the register is still true, and the resolution note has been retested.

Custody is the field that replaces the registrar account

In the DNS register, control is described by the registrar, the account and the users who have access to it. In the onchain part of the register, control is described by the wallet and by who can make it act. If one field of the new entry type is wrong, this is the one that hurts.

A wallet, in general terms, is the tool that holds the keys allowing transactions from a blockchain address. Companies usually avoid a wallet run by one person from one device, and prefer an arrangement in which several designated keys must approve, or a custody provider with approval workflows. The choice belongs to security and treasury. Your register describes it in enough detail that a reader understands who can move the asset.

In practice that means recording:

• the type of arrangement, in plain words
• the team accountable for it, and a named contact
• the approval rule in outline, for instance that more than one approver is required
• where the operating procedure is kept, and who owns it
• the date custody was last confirmed

Two situations come up often enough to plan for.

One is the name held in a personal wallet by the employee or agency that registered it. The register shows this honestly, with the status marked as pending transfer to company custody, and legal should know. Moving the token to a company wallet is a single transfer, but it needs the cooperation of the person who holds it, which is easier to obtain while they still work with you.

The other is the name that needs to be used. A TLD that only sits in custody can stay in the most restrictive arrangement the company has. A TLD under which names are issued, or a name whose records are updated, needs someone to operate it. Freename offers no delegated management of a TLD: the holder is the only party that manages it, so there is no way to give a product team a limited operator role while the token stays in a vault. Every management action is an action of the holding wallet. The register should therefore say not only who holds the asset but who is expected to request changes and how those requests reach the custodian.

Names under a company TLD: one entry or many

A DNS portfolio is flat. Each domain is a line. An onchain TLD introduces a second level that the company itself controls: if you hold .yourbrand, you can issue pay.yourbrand, and as many other names as the business asks for.

The question for the register is how deep to record. A workable rule is to keep the TLD as a parent entry and to add a child entry for each name issued under it that meets one of three tests: it is used in front of customers or partners, it is held by a wallet other than the one holding the TLD, or it was issued to a third party.

The third test matters most. A name issued to a partner, a licensee or a customer belongs to that party. It is not a company asset, and it should not be counted as one. It is, however, a company commitment, and the register is a sensible place to record that it exists, who received it and under which agreement. Whether a holder can later withdraw or change a name that has been issued is case by case, so the entry should point to the terms under which the name was given and not assume an answer.

If the company holds a name under a TLD it does not control, such as name.yoursector, the entry is a single line with one extra field: the TLD it depends on. The company is then a registrant under someone else’s namespace, and the terms that govern the name are the terms of that namespace.

What to send legal, and how often

Legal teams generally want to know four things: what the company holds, whether it is safely held, what it has promised to others, and what others hold that resembles its marks. A short standing section in the periodic domain report answers them better than a separate document that nobody expects.

Three points make this report more useful to its readers.

Report exceptions first. A name in a personal wallet, a custodian who has left, a wallet nobody can confirm access to: these are the items legal needs to act on.

Keep what is held separate from what is observed. The first five lines describe the company’s own assets and promises. The last describes names held by others. Mixing them leads to confusion about what the company controls. What to do about a resembling name is a legal decision that depends on the rights involved and on the country, and the UDRP, which binds registrants of DNS domains through their registration agreements, does not reach names recorded outside the DNS. Your role is to report the observation accurately. The page for brands and legal teams is written for the readers of that line.

State the limits of the data. The public record shows which wallet holds a name. It does not show who is behind a wallet. A report that says “held by an unknown party” is accurate; a report that guesses at an identity is not.

If the company applied for a dotBrand in an ICANN round, or considered it, legal may ask how the onchain name relates to it. They are different assets under different rules, and the register shows them as separate entries that share a string. The comparison of a dotBrand and an onchain TLD explains the differences in a form you can forward.

Adding the first onchain entries to your register

The work is small if it is done in order. Most of the effort is finding out what exists and who controls it; the register changes take an afternoon.

1. Create the second entry typeAdd a tab or record type for onchain names with the new fields.
2. Find what the company holdsAsk marketing, product, innovation, legal and the main agencies whether anyone has registered or bought a name on a blockchain registry, in the company's name or their own.
3. Confirm each name on the public recordOpen the registry record on a block explorer, note the holding wallet and store the link in the entry.
4. Match each wallet to a custodianAsk security or treasury to confirm in writing which team operates each wallet. Mark any wallet that nobody claims, or that belongs to an individual, as an exception.
5. Record terms and datesNote the registry terms, any program the name takes part in, any registry or program date, and a review date you set yourself.
6. Record names issued under a TLDAdd child entries for names in use, names held in other wallets and names issued to third parties, with the agreement behind each.
7. Report and scheduleSend legal the first onchain section with exceptions at the top, and put the entries on the same review cycle as the rest of the portfolio.

Once the entries exist, one follow-up is worth an hour. Check whether the company’s main marks exist as onchain TLDs held by someone else, since that belongs in the resemblance line of your report; the free Trademark Name Check on the trademark TLDs page is the place to run it.

If that check shows the TLD matching the brand in another party’s hands, the company may decide it wants it. An organization can then mandate Hush Partners to find and approach the holder, with closing through onchain escrow on an aftermarket. If that question reaches you, the contact form is the way in. Whatever the outcome, the register entry comes first, because a name the company acquires should arrive in a wallet and under a custodian that are already written down.

Questions people ask

Should onchain names go in the trademark register instead of the domain register?

No. A trademark register records rights granted by trademark offices, and an onchain name is not a right of that kind. It is closer to a domain: an identifier the company controls under a registry’s terms. Keep it in the domain register and cross-reference the mark it corresponds to.

What happens to the entry if the company decides to drop the name?

A DNS domain is dropped by letting it lapse. A name with no renewal does not lapse, so dropping it is an active decision: keep it in custody, transfer it, or sell it. Until one of those happens the entry stays open, with its custodian and its review date.

Who may see the onchain section of the register?

The same readers as the rest of it. The wallet address and the registry record are public. The key procedures the entry points to are stored elsewhere, under the custodian’s access rules.