Running a market TLD for travel: who it serves and how

Travel is a sector built on trust between strangers. A guest books a room from someone they have never met. A trekking group hands a deposit to a local guide whose business card is a phone number in a messaging app. A destination management company coordinates a dozen sub-operators under a single booking, with no single document binding them all. The friction is less in the logistics than in identity: who exactly is this person, and how does the traveler know they are who they say they are?

A market TLD is a sector word held as a namespace, under which names are issued to participants in that sector. It speaks to this friction, on one condition. A name such as name.yoursector carries nothing by itself. If the operator behind .yoursector has written issuance rules, runs a known directory and ties each name to an onchain record that others can check, then the name works as a credential: something the holder controls, that a traveler can verify, and that stays with the holder from one platform to the next.

This article is for operators, platforms and associations in travel who are deciding whether to acquire a sector TLD and issue names under it. It covers who the natural registrants are, what a name would do for each of them, what the operator takes on, and what a realistic first year looks like. Where demand is thin, it says so.

Who would hold a name under a travel TLD

The obvious registrants are the professionals who work at the point of contact with a traveler: travel agencies, independent guides, hosts and accommodation operators, and destination bodies such as tourism boards or the local operators who market a place.

The sharpest demand sits with independent professionals. A guide working across several booking platforms has no persistent identity of their own. Their profile on any one platform is an asset that belongs to the platform. A name under .yoursector that they control from their own wallet is a different thing: it is theirs whichever platform carries their offer. That is the argument that lands.

Large agencies and destinations are harder to convert early. A tourism board already has a well-known conventional domain and an official site. It is not looking for a replacement. It might hold a name as the reference point for a specific program (a festival, a corridor initiative, a certification scheme), but it is unlikely to be a first-year registrant, and it will never register in volume.

What a name does for each kind of registrant

A name does a different job for a guide, a host, an agency and a destination, and the offer you make to each has to be different too.

For an independent guide, the most immediate value is a payment address. A traveler who wants to pay a deposit before a trek can send funds to the guide’s name under .yoursector rather than to a raw wallet address or to bank details they cannot verify. The name resolves in supported wallets, which makes it readable to the payer. A guide rarely works alone: the trek involves a porter team, a driver or a local co-operator. With an onchain payment router such as shaka, a payment link can pay out to a name, and the shares of each party are agreed and signed onchain before any funds move; the router passes the funds on and never holds them. That removes a common source of argument after a trip. The name is also a stable identifier the guide can print on materials, share in messaging apps and point to from any platform profile.

For a small accommodation host, the case is similar but the payment flow is simpler: a deposit or a balance from a guest. Many hosts are paid into a domestic bank account that is slow or costly to reach from abroad, and a name that works as a payment endpoint gives the guest another route. It also serves as an anchor. If the property appears on several platforms under different spellings or translations, the name is the one reference that every one of those pages can point to.

For a travel agency or destination management company (DMC), a name is most useful as an organizing tool. Where your issuance rules allow it, an agency can hold several names, for example reservations.yoursector for its booking desk and another for its group arrivals desk, so that each activity has its own onchain identity and its own payment endpoint. This suits agencies that manage many supplier and client relationships and want each flow to be traceable. It is far less compelling for a two-person agency that already has a working website and payment setup.

For a destination or tourism board, the interest is reputational and tied to programs. Suppose a regional body runs a quality program for dive centers. Each certified center holds a name under .yoursector, and the public directory of the namespace shows which program admitted it. The TLD then carries a trust signal that centers can display and visitors can check. This is a long game: the certification logic and the directory have to exist before the signal means anything.

A name does not replace a website for most registrants. Onchain names resolve outside the ICANN DNS root, so opening one takes a wallet, a browser extension or a resolver that supports it, and that support is partial and changes over time. For a guide who wants a page that any traveler can open in a phone browser, a conventional domain is still the right tool. The onchain name and the DNS domain can coexist and serve different purposes.

Independent professionals who lack a trusted identity

This group gets its own section because it is where a travel namespace has its strongest argument, and where the barrier to entry is highest.

Travel is exceptionally fragmented at ground level. Guides, boat captains, trekking leaders, local fixers and specialist operators often work informally or semi-formally. Their reputation lives in review pages they do not control, in group chats and in word of mouth. If a negative review is attached to the wrong profile, or a platform changes how it ranks offers, their visible reputation can shift without any recourse.

An onchain name does not fix this directly. It gives the professional something they own: a persistent identifier that no platform can withdraw, that points to a wallet they control, and that can carry linked information (certifications, endorsements, a portfolio) if the operator builds that layer. The key word is “if”. The value of the name is proportional to what the operator builds around it.

The barrier is familiarity. Most independent guides have never held a wallet. Taking a name under .yoursector means learning at least one new tool, often on a phone, often in a second language, often with a weak connection. An operator who wants this group to register in volume has to provide either very simple onboarding, ideally through an interface the guide already uses rather than the registry itself, or a clear and immediate benefit that justifies the effort. A payment endpoint that works in the first week is that benefit. A vague future credential is not.

There is a second barrier, on the traveler’s side. A guide’s name is only useful if the person paying can use it, and many travelers have no wallet either. In practice the first travelers to pay to a name will be those who already hold digital assets, which is a minority of any guide’s clients. An honest pitch to guides says so: the name adds a payment route and an identity, and takes nothing away from the routes they already use.

Before you build around payments, read how payments to a name work and check what is live for onchain TLDs, which lists each capability with its source.

Bookings and deposits between strangers

Paying a stranger across a border is the one place where a name does material work for travel, beyond reputation.

Consider a scenario with invented parties. A traveler in one country books a private hiking guide in another for a trip three months away. The traveler wants to pay a deposit to hold the date. The guide wants the deposit to mean something: if the traveler cancels late, the guide has turned away other work and expects to keep part of it. The two have never met. The traveler cannot easily verify the guide’s bank details, and sending money to a long string of characters found on a profile page feels uncomfortable.

If the guide holds a name under .yoursector, the traveler sends the deposit to a name they can read and compare with the directory of the namespace. If the trip involves a local co-operator, a payment router lets the guide fix each party’s share before the money moves, so nobody has to redistribute it by hand afterward.

What the name does not settle is the cancellation policy. Who keeps what, and until which date, remains an agreement between guide and traveler, written wherever they wrote it. A name also cannot reverse a payment sent in error or to a dishonest party: an onchain transfer is final in a way a card payment is not. Travelers used to the protection of a card or a booking platform will notice the difference, and your onboarding material for guides should state it plainly, with advice to confirm terms in writing before a deposit is requested.

The components for this exist. What is usually missing is the operator who assembles them into something a non-technical guide can use from a phone at a trailhead. The page for operators of a market TLD sets out what running a namespace involves.

Destinations and local operators: a slower adoption curve

Destination bodies (tourism boards, regional DMCs, place-based certification programs) are worth pursuing, but they will not drive early registration. Their decision cycles are long, their procurement is formal, and they are cautious about anything that looks experimental.

The case that works with them is narrow. A specific certification or accreditation program benefits from names that anyone can verify and that do not depend on the destination body’s own server staying online. A dive center admitted to the program can show its name to any booking agent, and the agent can look up the public registry record on a block explorer without writing to the destination body for confirmation.

Even that case takes time to make. A regional tourism board that wants to run such a program needs legal review of what the name represents, a process for issuing and withdrawing names (a guide who loses certification should not keep presenting the name as a credential), and agreement from the accommodation and activity operators it wants to certify. None of that is fast.

Local operators attached to a place raise a question of their own: who may hold the name of the place itself? A valley, a reef or an old town belongs to no single business, and the first applicant is rarely the right holder. A common answer is to reserve place names from general registration and release them only to a body that can show it represents the destination.

Plan for destination bodies to register in the second or third year, not at launch. If one is willing to pilot a program, treat it as a test case and invest in making it work. A successful pilot with one tourism corridor is worth more than five vague letters of intent.

Seasonality and renewal of interest

Travel demand is not flat. Beach destinations peak in summer, ski areas in winter, festival corridors in their festival weeks. That rhythm decides when guides and hosts pay attention to their online presence, when they are most likely to take a name, and when they are most likely to let it drift.

On Freename, the TLD itself costs nothing to keep from one year to the next: the registry charges no annual renewal on it. The terms that apply to names under it are a separate matter, and you should read the registry’s current terms before you design your offer. Where a name carries a term, expect seasonal operators to let it go when the term ends in their quiet months. Where it does not, that friction disappears, and so does a natural moment to get back in touch.

In both cases the real renewal in travel is a renewal of interest. A guide who set up a payment endpoint in spring and received no payment to it by autumn will stop mentioning the name. A host who received three deposits through it will put it on every confirmation message. Usage in the first season, far more than any registration count, predicts whether the namespace is alive a year later, so the measure to watch is names that received a payment or were opened, not names issued.

Seasonality also shapes your support load. When guides are on the mountain in peak season, they are not thinking about how their name is configured. In the off-season they have time to set it up, fix what is broken and refer colleagues. Plan onboarding campaigns and support around the off-season of the main geography you serve, not around a calendar date. If you serve two hemispheres or both a winter and a summer trade, you get two onboarding windows and no quiet period.

A name whose holder has stopped operating is not a disaster. A name that still appears in your directory and sends payments to a wallet nobody watches is a problem. You need a policy for dormant names: how long before a name is flagged, what notice the holder receives, and whether the directory entry is withdrawn. These decisions belong in the issuance rules before launch.

The operator’s role: rules, issuance, support, disputes

Running a namespace is not passive. The registry records the TLD, and on Freename only its holder can issue names under it. Every decision about who gets a name, on what conditions, and what happens when things go wrong falls to you.

Issuance rules

Issuance rules define what a registrant must provide to hold a name. The minimum is evidence that they are who they claim to be: an identity document, a business registration, or an account on a platform that already verifies identity. You can add requirements specific to travel: a guide license where the country issues one, an accommodation permit, a certification from a recognized body. Licensing differs widely from one country to the next, so a rule that is easy to meet in one destination may be impossible in another. The tighter the rules, the more the namespace can be trusted, and the slower the first registrations. You decide where on that line to sit, and collecting identity documents brings data protection duties that your counsel should review.

Disputes

Dispute handling covers two distinct problems. The first is a registrant who holds a name they have no legitimate claim to, such as the name of a national park held by a business with no relationship to that park. The second is a disagreement between two registrants who both claim the same name, which is common where several family businesses in one village share a surname or a place name. Neither is resolved by the registry. The UDRP, the dispute policy that binds registrants of domain names in the ICANN system through their registration agreements, does not extend to names under an onchain TLD. Your own rules are the mechanism, so they have to be written and published before the first dispute, and some cases will need legal counsel.

Support

Support is light at first and grows with registrations. Budget for a named person who can answer a guide who cannot set up a wallet, a host who needs help with a payment link, and a platform partner who wants to display names in its own product. Travel adds two constraints: registrants write in many languages, and they write at odd hours from places with poor connectivity. If you run the TLD as a side project, support is the part most likely to fail.

The launch roadmap tool builds a plan from your constraints, and the post-transfer activation service covers putting a TLD to work once it is in your wallet.

Revenue from names: a worked example

On Freename, the holder of a TLD can join a royalty program that pays a share of the registration fee each time a name is registered under that TLD. Up to half is what the registry advertises for that share, and the figure a travel operator obtains follows the registry’s current terms and activation conditions. Some TLDs were registered under earlier terms that include the program for life, and whether a buyer keeps those terms is to be confirmed with the registry before closing. It applies to registrations. Do not build a model that counts on renewals of names.

Here is a worked example. Every figure in it is an assumption chosen for illustration, not a forecast.

Assumptions

• The TLD is acquired and operational in month three of the first year.
• The registration fee for a standard name under .yoursector is USD 40.
• The operator receives half of each registration fee, the advertised maximum, which is USD 20 per standard name.
• 200 standard names are registered by the end of the year: 30 in a pilot group and 170 after registration opens.
• Ten sought-after names are registered at a fee of USD 200 each, and the same half share applies, which is USD 100 per name. Different fees for different names are yours to decide, because the holder of a TLD sets the price of the names issued under it.
• No income other than the royalty on registrations is counted.
• Operator costs (acquiring the TLD, setup, onboarding materials, support) are left out, because they vary widely. Also left out, and to be deducted from the total, is the annual cost the registry sets for taking part in the royalty program.

Computed revenue

Standard names: 200 names x USD 20 = USD 4,000

Sought-after names: 10 names x USD 100 = USD 1,000

Total royalty in the first year: USD 5,000

Standard names (200 names)USD 4,000

Sought-after names (10 names)USD 1,000

Royalty on registrations only; excludes the cost of acquiring the TLD, the annual cost of the royalty program and all operating costs.

USD 5,000 is modest, and it is the result of favorable assumptions. At 200 registrations a travel namespace does not pay for itself through royalties. The arithmetic only changes if names are issued in the thousands, which takes distribution through a platform or an association with a large membership, and travel professionals are slow to adopt new tools. The more defensible business case treats the royalty as a secondary return on a namespace whose main value lies elsewhere: a booking platform that stands apart, an association that gives members a credential, or a certification program with its own economics. Be honest about this when you make the case for acquisition.

The subname revenue calculator lets you change these assumptions and see the result.

What to check before acquiring the TLD

The string you want may or may not be free. The first check is the registry: is the TLD already recorded to a wallet? That record is public, and a block explorer shows it to anyone who looks.

Beyond that, check these things before committing.

Trademark exposure. A sector word is often generic enough to raise no trademark concern, but travel vocabulary is full of place names, and in some countries place names and regional designations are protected. Names issued under the TLD raise the same question one level down. Your own counsel advises on the specific string. The page on trademark TLDs explains the subject and holds a free Trademark Name Check.

Collision with the ICANN DNS. If the same string exists, or comes to exist, as a TLD in the ICANN root, names under your onchain TLD may not resolve as expected in software that does not use the onchain resolver. This does not block acquisition, but it affects how useful the names are, and it is worth knowing before you print a name on a brochure.

Valuation. If the TLD is held by a third party, you need a realistic view of what it is worth before anyone approaches the holder. A sector word in travel has no price list, and a guess anchored on the wrong comparison costs you either the deal or your budget. Hush Partners describes how a TLD valuation is built.

Your own readiness. Acquiring the TLD is the start. Are the issuance rules written, the support process defined, the first group of registrants identified? If not, the TLD will sit unused. A buy-side acquisition mandate, in which the desk finds and approaches the holder for you, makes most sense when you can activate within weeks of closing.

Resolution expectations. An ordinary browser will not open an onchain name without support. A guide’s or a host’s Freename name does work in Bitcoin.com Wallet, in MetaMask by way of Freename’s resolver, and on desktop in a browser with the Freename Web3 extension installed. That list is partial and will change, and nobody can promise it will become universal. If your registrants mainly use the name to be paid, this is a manageable limit. If they expect an address a guest can tap on a phone, tell them at registration that the name sits beside their conventional domain and does not replace it.

Seasonal timing. Check when your first registrants are free to listen. A TLD acquired at the start of their peak season will wait months for attention.

A realistic first year

The first year of a travel namespace is mostly groundwork. Registration volume comes later, if it comes, and the plan below assumes the same numbers as the worked example.

1. Checks before acquisition (weeks 1 to 4)Confirm whether the string is free or held. Have counsel review trademark exposure. Draft the issuance rules and the policy for place names. Read the registry's royalty terms and activation conditions.
2. Acquisition and setup (weeks 5 to 10)Close the acquisition and receive the TLD in a wallet your organization controls, preferably one that needs more than one person to approve a transaction. Meet the activation conditions of the royalty program. Test how names resolve in the supported wallets and browsers.
3. Pilot group (months 3 and 4)Invite a closed group of 30 guides and hosts you know directly or through a platform relationship, in their off-season. Issue their names, help them configure a payment endpoint, and write down everything that breaks.
4. Onboarding material (month 4)Write short guides for the three most common tasks: taking a name, setting up a payment endpoint, and telling a guest how to pay to it. Publish them in the languages your registrants work in.
5. Open registration (months 5 and 6)Open to the wider sector, starting with independent guides and hosts who serve international travelers. Announce through travel trade channels. The audience is travel professionals, not name investors.
6. Sought-after names (months 5 to 8)Offer the ten professional and category names you set aside. Keep place names in reserve for the destination bodies you plan to approach later.
7. First dispute (month 6 onward)Expect at least one. Apply the written process, record the outcome, and revise the rules if the case exposed a gap.
8. Review (month 12)Count registrations, names that received a payment, support requests, disputes and royalty income. Compare with your model. Build the next plan from what happened.

The 200 registrations of the worked example are within reach in a first year only if you already have a channel to travel professionals: a booking tool, an association membership, a certification program. They are not within reach through cold outreach to people who have never heard of onchain names. If you have no such channel, the honest first-year target is the pilot group and a working payment flow, and the decision to continue is taken at the review.

The next step

Before any negotiation, write one page: the registrant group you will serve first, the benefit they get in their first week, and the channel through which you reach them. If you cannot fill in the third line, wait.

If the page holds up and the TLD you want is held by someone else, Hush Partners can be mandated to find and approach the holder. The desk works for a fixed fee, never a percentage, paid by the client who gives the mandate. A mutual NDA covers every exchange, and one named partner stays with the file until closing, which runs through onchain escrow on an aftermarket.

Questions people ask

Can the operator withdraw a name once it is issued?

You can write rules that provide for withdrawal, and you can always remove a name from your directory and from any program it was part of. Whether the name itself can be taken back onchain depends on the registry’s terms and on how issuance is set up. If you need that power, for a certification program for instance, confirm what the registry supports before launch and disclose the conditions at registration. Announcing after the fact that a name can be withdrawn is a legal and reputational problem.

Does holding the TLD give the operator rights over names that look like trademarks?

No. You control issuance under the TLD, and that gives you no right over anyone’s trademark. If a registrant takes a name that conflicts with a mark, the owner of the mark will look first to the registrant and may also look to the operator. How responsibility is shared varies by country, and your own counsel decides. Your issuance rules and dispute process are your practical tools.

What happens to issued names if the operator sells the TLD?

The registry record shows the new holder of the TLD. Names you sold to guides, hosts or agencies remain theirs, and names you hold yourself under the TLD can go to the buyer with it if you both agree. What you owe the people who hold names under it (support, dispute handling, the terms you published) is a matter between you and them, and a buyer will ask how those commitments pass on. Review them before you put the TLD up for sale.

Is the royalty income taxable?

Usually it is treated as income, and how it is classified depends on the type of entity, where it is established and local law. This is information, not tax advice; your own adviser decides.