Onchain TLDs and hotel groups: what to check

A hotel group’s name is not just a trademark. It is also a booking signal, a loyalty anchor, a rate benchmark, and the word a travel agent types into every channel it uses. That same word can exist as an onchain top-level domain: a TLD recorded as a token on a public blockchain, outside the ICANN domain name system. When it does, the name can show up at more points of the guest journey than a single website address ever covers: at the top of the funnel, at the point of payment, inside loyalty accounts, and inside the automated tools that book travel on a guest’s behalf.

This guide explains what makes the hospitality sector distinct, maps exposure by function, and gives a checklist you can delegate. After reading it, the head of distribution or the brand protection lead should be able to brief the team the same afternoon, identify the two or three functions that carry the most exposure, and decide whether to open a file.

The guide does not assume you already hold the TLD that matches your group’s name. It assumes you may not, and that you want to understand what that means before deciding what to do.

Why a hotel group is not a generic brand here

The technology in brief

An onchain TLD is the extension itself, such as .yourbrand, recorded as a token held in a wallet. On the Freename registry, whoever holds that token is the only party able to issue names under it, such as book.yourbrand or pay.yourbrand, and the TLD carries no annual renewal fee. That record is public: a block explorer, which is a website displaying what a blockchain has recorded, lets anyone in the group check it.

These names resolve outside the ICANN DNS root, so an ordinary browser does not open them without support. A guest can use a Freename name today in three places: Bitcoin.com Wallet, MetaMask by way of Freename’s resolver, and a desktop browser fitted with the Freename Web3 extension. That coverage is partial and it changes. For a guest who types an address into a browser, the conventional DNS is simply better, and nothing in this guide suggests moving your booking site.

The page on what is live lists each working capability with its source. For a hotel group, the relevant ones are those where a piece of software, such as a wallet or an agent, reads the name, and no browser is involved.

Five relationships that all run on the name

Many sectors have one main brand-to-customer relationship to protect. A hotel group has at least five running at the same time, and every one of them uses the group’s name as a trust signal.

The first is the direct booking relationship, where the name appears in a web address, a rate comparison and a confirmation message within minutes of each other. The second is the intermediary layer: online travel agencies, distribution systems, tour operators, corporate travel desks and automated booking assistants all use the group’s name as a search term and a mark of credibility. The third is the managed and franchised estate, where many independent operators trade under the group’s flag. The fourth is the loyalty program, where the name is the most visible element of a points balance a guest may have built over years. The fifth is payment, where a guest or a corporate account sends money in advance to something that carries the group’s name.

Each of these relationships is a point where an identity that looks official could be inserted. A manufacturer mostly protects its brand at the point of sale. A hotel group has to protect it at every handoff between the guest, the intermediary, the property and the program. That is why the TLD, and not the individual names under it, is the right level at which to think about control. Whoever holds .yourbrand decides whether book.yourbrand, pay.yourbrand and loyalty.yourbrand exist at all, and to whom they are issued.

The five relationships also interact. A loyalty member books through an agent, pays a deposit to a franchised property and expects points from the group. One name carries the trust across all of those steps, and a weakness at one step is felt at the others.

Bookings, deposits and the long habit of intermediaries

Hotel distribution has always involved third parties using the brand’s name. Agents, wholesalers, tour operators and booking sites have sold rooms under the flag for as long as the flag has existed. Rate leakage, presentation that does not match brand standards, and promotions the group never approved are familiar problems, and your distribution contracts already deal with them. What an onchain namespace adds is a kind of identity that does not depend on the group’s DNS, servers or approval. A name under a TLD the group does not hold exists whether or not the group agreed to it.

Consider what a name like deposit.yourbrand could mean to a guest who sees it in a wallet, or in a message that claims to come from an agent. The name looks authoritative. A payment sent to it goes to whichever wallet the name points to, and nothing on the guest’s screen says whether that wallet has anything to do with the group’s accounts.

Deposits are the sensitive point, for reasons that belong to hotels. A room is paid for long before it is used. Pre-payment for a non-refundable rate, a deposit for a wedding or a conference block, and a guarantee for a group booking are all sent weeks or months ahead, often after a message that asks the guest to complete the payment. The guest cannot inspect anything at that moment. The only thing to check is the name on the request. In a business where the product is delivered later and somewhere else, the name does the work that a shop counter does in retail.

The long history of intermediaries cuts both ways. Guests are used to booking through channels the group does not operate, so a touchpoint that is not the official website does not surprise them. That is a weakness. On the other side, your legal and distribution teams already have rules for how a partner may use the group’s name in a web address, in advertising and in a confirmation. Those rules were written for the web. The question to put to them is whether they also reach a name under an onchain TLD, and the honest answer in most contracts will be that nobody thought to ask.

There is a constructive side. A payment link can pay out to a name in place of a raw wallet address, which is one of the payments to a name capabilities that already work. For a group that controls its TLD, this is a readable, checkable destination for a deposit. When someone else controls the TLD, the same capability works for them.

Franchised and managed properties under one flag

A franchised or managed hotel trades under the group’s flag but is owned, and often partly operated, by an independent party. That structure creates an exposure that a fully owned chain does not have.

The owner or management company may, in good faith, want onchain identities for the property: a wallet, a payment name, an identity for an agent. They will reach for the most recognizable name available, which is the group’s brand. If the group does not hold the TLD, the property cannot be given a name under .yourbrand by the group, because issuing names under a TLD is reserved to its holder. The property team may not know that. And the party that does hold the TLD could issue names that suggest a property relationship the group never authorized.

This matters for rate integrity as much as for brand protection. If a name such as propertyname.yourbrand leads to a wallet the group does not know, guests who pay through it believe they are dealing with a property of the group. The brand supplies the trust, and an unknown wallet receives the funds. Your franchise and management agreements may well say nothing about this, since they were drafted around web addresses, signage and reservation systems.

What the brand standards do not yet say

Brand standards in hospitality are detailed. They cover the sign on the building, the wording of the confirmation, the web address a property may use and the channels it may sell through. An onchain name is a new item on that list, and it raises questions the standards manual can answer in advance:

• May a property register or use any onchain name that contains the group’s brand?
• Who issues a name to a property, and under which TLD?
• Which wallet may a property name point to, and who approves a change?
• What happens to the name when the property leaves the flag?

The last question is the one that is specific to this sector. Properties change flags. When a hotel leaves the system, the sign comes down, the web address is redirected and the reservation codes are closed. A name issued to that property under the group’s TLD needs the same exit treatment, written into the agreement. How a name already issued can be recovered or retired depends on the registry’s terms, so have that point checked before you rely on it in a contract.

Extending brand governance to the onchain namespace is a project for legal and distribution together. It is far easier to run when the group itself holds the TLD, because then the group is the one that issues.

Loyalty programs and the name as a points identity

A loyalty program’s value depends on the member’s belief that points, status and redemption rights are held by the group and will be honored by the group. The brand name carries that belief. Members do not read the terms every time they check a balance. They read the name.

An onchain name can be shown in a wallet in place of a long address, and it can serve as the identity of a piece of software. A name like loyalty.yourbrand or points.yourbrand therefore carries implied authority for a member who sees it in a wallet or in a message from a travel assistant. If the group does not control that name, it could be used to imitate a program communication without the group’s involvement. Your member-care team should be able to recognize that pattern and know where to report it.

Points are also a store of value that members treat casually. A member who would hesitate before sending money will often follow an instruction to “verify” or “merge” a points account, because points do not feel like money. Hotel programs add partners to this: airlines, card issuers, car rental and retail partners all send messages that mention the group’s program. Each partner is one more sender whose messages the member is used to trusting, and one more place where a name that looks like the program’s could go unquestioned.

The loyalty program is also the part of the business with the deepest data relationship with the guest. Status, preferences, payment methods and stay history are all reached through the trust the name creates. Control of the name at the TLD level is one part of protecting that perimeter. It does not replace the account security your program already runs.

There is a positive case too. A group that holds .yourbrand can issue loyalty.yourbrand as the program’s own identity, under a TLD whose registry record is public and open to inspection on a block explorer. A conventional subdomain gives a similar assurance on the web. The onchain name gives it in the places where a web address is not what the member sees.

Travel agents and concierges acting for the guest

Human travel agents and corporate travel managers have always used hotel brand names as search and booking terms. A good agent knows the group, knows its sales contacts and notices when something is off. The same job is being handed to software: booking assistants that compare rates and make reservations for a guest, and concierge tools that arrange transfers, tables and late check-outs. Software does not have the agent’s instinct. It relies on identifiers, and a name is an identifier.

One proposal for how such software identifies itself is ERC-8004, known as “Trustless Agents”. It is a draft Ethereum standard and may change. It describes three registries: one for identity, where each agent is an ERC-721 token that points to its agent card, one for reputation, built from the feedback of those the agent worked with, and one for validation, where its work is checked independently. How naming registries connect to it is still evolving, so treat any plan built on it as provisional.

The practical implication for a hotel group is narrow but concrete. A booking assistant or a digital concierge that presents itself as agent.yourbrand or concierge.yourbrand carries an implied endorsement from the group. The group that holds the TLD decides who gets such a name. A group that does not hold it has no say. The page on identities for AI agents describes where this capability stands.

Hotels meet this from both directions. The guest’s assistant needs to know that it is talking to the real hotel. The hotel’s own concierge service, whether a person at a desk or software in an app, needs to be recognizable as the hotel’s when it contacts a restaurant, a driver or the guest. A property’s concierge has always traded on the hotel’s name to get a table. An automated one will do the same, and the name it uses should be one the group issued.

For corporate accounts with managed travel programs, the point to check is approval. A travel manager approves a hotel, a rate and a traveler. If an assistant is ever allowed to choose where a payment goes, the approval workflow should also cover the destination, and the destination should be one the group has confirmed.

Exposure by function inside the group

The table maps the main functions of a hotel group to their exposure. It is not exhaustive. It covers the points where a question is most likely to arrive first, and it tells you whom to brief.

Two rows deserve a comment. Legal carries the structural exposure: the UDRP, the dispute policy that applies to domain names registered through ICANN-accredited registrars, has no hold over a name that sits outside the DNS. Trademark law still applies to how a name is used, but it varies by country and it works through courts, not through a registrar. Franchise and operations carries the exposure most likely to be created from inside, by a property acting with good intentions.

Ten checks, each with an owner

The checks are ordered so that the first three need no outside contact and no budget. Each names the function that owns it.

1. Identify the TLD that matches the primary trading nameEstablish whether the TLD exists on the registry, and note the public record as shown on a block explorer. The Trademark Name Check gives a first read. Repeat for each flag the group trades under. Owner: Legal and brand protection.
2. Look at names issued under the TLDIf the TLD exists, note which names have been issued under it. Names such as book, pay, deposit, loyalty, points and concierge come first. Owner: Legal and distribution.
3. Run the Namespace Exposure ScoreThe tool scores how exposed the brand is onchain. Use the result to brief senior stakeholders and to order the checks that follow. Owner: Brand protection.
4. Read the franchise and management templatesCheck whether the templates and the brand standards say anything about onchain names, wallets or payment destinations, including what happens when a property leaves the flag. Owner: Legal.
5. Ask the propertiesAsk owned, managed and franchised properties whether any of them uses, or plans to use, an onchain name or a wallet for guest payments. Owner: Franchise and operations.
6. Review loyalty communicationsCheck whether any member-facing message, including those sent by partners, refers to an onchain name or address, and whether the group controls each one. Owner: Loyalty and CRM.
7. Map wallet and payment integrationsList every wallet or onchain payment integration that is live or in pilot. For each, confirm that the destination belongs to the group and that someone is named as responsible for it. Owner: IT and finance.
8. Ask the largest corporate accountsAsk whether their travel tools let an assistant choose a payment destination or rely on a name to identify a hotel. You need to know whether it is in scope, not how it works. Owner: Corporate sales.
9. Decide how the namespace is watchedWhatever the first checks show, decide who looks again, how often, and what finding reopens the file. Owner: Brand protection.
10. Brief the executive committeeThe decision to acquire, to monitor or to do nothing commits brand, legal, distribution and finance. Take it at a level that can commit all four, and record it. Owner: General counsel.

The first check starts on the page about trademark TLDs, which holds the Trademark Name Check form. The third uses the Namespace Exposure Score. Both are free, and neither requires you to say more than the name you are checking.

The options, and who should own the file

Once the checks are done, the group has three basic options: acquire the TLD, monitor and reassess, or take no action. Each has a different owner and different conditions.

Acquire the TLD. This is the fitting response when the TLD matches the primary trading name and either names are being issued under it, or the group plans wallet payments, onchain features in the loyalty program, or agents of its own. The file belongs with the general counsel as decision-maker, with distribution and digital as the functions that will use the TLD after the transfer. Because the UDRP does not apply, obtaining a TLD is a negotiation and a purchase, not a takedown. Brand namespace recovery is the service built for that case. An organization can mandate Hush Partners to find the holder and make the approach; the mandating client pays a fixed amount, never a share of the price, and closing runs through onchain escrow on an aftermarket.

Monitor and reassess. If the TLD exists but nothing visible is happening under it, and the group has no plans for the capabilities it would enable, a structured watch is proportionate. Define the trigger in advance: for example, the review reopens when a name like book.yourbrand or pay.yourbrand appears. Namespace watch is the service for monitoring a brand’s names onchain. The owner of the monitoring file should be brand protection, with a defined route to legal.

Take no action. This is a legitimate decision if the TLD does not match a name the group actively trades under, and if none of the five relationships described earlier touches a wallet or an agent. It should be a decision and not an oversight, and it should be revisited on a fixed schedule, for instance once a year.

Why distribution should not own the file alone

In most sectors the file sits naturally with legal. In a hotel group there is a real case for distribution, because distribution owns the channel contracts, the rate rules and the relationship with intermediaries, and it will be the first to hear that something odd is circulating. But distribution does not own the franchise agreements, the loyalty terms or the trademark portfolio.

A workable arrangement is one owner and one deputy. Legal owns the file, because the outcome is either a contract change or an acquisition. The head of distribution is the deputy, because the evidence and the urgency will come from the channels. Loyalty, IT and franchise operations are consulted and are not owners. Split ownership with no lead is a common reason a review stalls, so name one person before the checklist is circulated.

Multi-brand groups have one more decision: whether to treat each flag as its own file. Usually the answer is one file for the group, with one line per flag, since the same people would handle each of them and the franchise templates are shared.

What holding the TLD lets the group do, beyond defense

The defensive case has taken most of this guide. The operational case deserves its own statement, because it changes how the acquisition is presented internally and which budget it draws from.

A payment name guests can read. A group that holds its TLD can issue pay.yourbrand as the single destination for wallet-based deposits, pre-payments and ancillary purchases. The group can publish that name in its own channels, so a guest or a corporate account has one thing to compare against. With shaka, an onchain payment router, the split between the parties is agreed and signed onchain before funds move, and the router passes funds along without holding them. In a sector where a single stay can involve the group, the property owner and an agent owed a commission, a split settled before the money moves is a practical feature.

A program identity. loyalty.yourbrand or member.yourbrand can serve as the program’s identity wherever a wallet or an assistant shows a name. If the program ever adds onchain features, such as points or rewards recorded as tokens, the identity is already in place and already the group’s.

Identities for the group’s own agents. If standards such as the ERC-8004 draft mature, names under the group’s TLD could identify its booking and service agents. concierge.yourbrand would be the group’s, by issue. The group can build that distinction into its agent projects from the start. This remains a possibility that depends on a draft, and it should be budgeted as one.

Names for the managed estate. The group can issue propertyname.yourbrand to franchised and managed properties on terms set in the agreement, alongside the sign and the reservation codes. It gives the brand standards something concrete to refer to. Post-transfer activation is the service that deals with putting a TLD to work once it has been transferred, and the sequencing of property names belongs there.

A share of registration fees. If the group chooses to open part of the namespace to partners or agents who want a name under its TLD, Freename runs a royalty program in which the TLD holder receives a share of each registration fee, advertised at up to half and subject to the registry’s terms and activation conditions. The TLD has no renewal fee, but taking part in the program has an annual cost set by the registry; some TLDs were registered under earlier terms that include the program for life, and whether those terms pass to a buyer is a point to confirm with the registry before closing. Next to the brand arguments this is minor. Mention it in the business case and do not build the case on it.

None of this replaces the group’s DNS presence. The booking site, the app and email stay where they are. The TLD adds a layer for wallets and agents, and that is all it should be asked to do.

Where to begin

Start by establishing, precisely, what exists onchain under the group’s trading names. Run the first three checks before any other decision. One person can do them without contacting anyone outside the group, and the result fits on a page: the TLD exists or does not, names are issued under it or are not, and the exposure score is what it is.

If the TLD exists and names are issued under it, open the file formally, name the owner and the deputy, and decide whether to act through an intermediary. If the TLD exists and nothing is happening under it, set the watch and write down the trigger. If no such TLD exists, record the fact and set a review date.

Where the group wants the holder found and approached on its behalf, that is the work Hush Partners does under mandate. Every exchange is covered by a standard mutual NDA, one named partner follows the file from the first note to closing, and the desk is reached through the contact form on the site. The page for brands and legal teams is the place to start.

Questions people ask

Does a trademark registration give the group a claim over the onchain TLD?

A registered trademark matters in any discussion about the TLD, and it may support a legal claim depending on how the name is used and in which country. It does not transfer the TLD by itself, and the UDRP is not available. In practice the path is usually a negotiated acquisition. Your own counsel decides whether and how a trademark argument is made.

Can the group issue names to properties without giving up the TLD?

Yes. Issuing a name under a TLD does not transfer the TLD. The group remains the holder and decides which names exist. The terms on which a property uses its name, and what happens when it leaves the flag, belong in the franchise or management agreement and should be checked against the registry’s terms before the first name is issued.

What about names already issued under the TLD before the group acquires it?

Treat this as a due diligence point. Before closing, review which names have been issued under the TLD and who holds each one. Names the seller itself holds can pass to the group together with the TLD if the two parties agree it, while names sold to third parties remain with those third parties. Do not assume that acquiring the TLD cancels them, and have your counsel reflect the position in the terms of the purchase.

Should a hotel group also consider a sector TLD?

A sector word such as .yoursector, with names like name.yoursector, is a different question from the TLD that matches your own name. It is a commercial opportunity, not a brand protection matter, and it belongs in a separate file with a separate owner. Settle the matching TLD first.