Onchain TLDs and airlines: what to check

Airlines carry a combination of brand dependencies that few other sectors share: a transactional relationship with every passenger at the moment of payment, a loyalty currency with real monetary value, a web of resellers and codeshare partners who legitimately trade under the carrier’s name, and a recurring class of events (cancellations, weather disruptions, strikes) that creates a concentrated window of customer anxiety. Each of those elements is already familiar to anyone who handles conventional domain impersonation. Onchain TLDs add a layer that many airline legal and digital teams have not mapped.

The TLD a carrier has to look for here is an onchain one: a top-level domain that a public blockchain records as a token. It is held in a wallet, transferred from one wallet to another, and not administered through the ICANN system. When a carrier’s name, or a name closely associated with it, exists as such a TLD, only the holder of that token can issue names under it. The holder can point those names at payment addresses and publish content under them, and a casual observer may read the result as official infrastructure of the carrier. The TLD may be held as an investment, run commercially, or left without any deployment at all. Those three states call for different responses.

This guide works through what is specific to the airline sector, where the exposure concentrates by function, and what a competent review looks like in practice. The goal is a file that can be delegated on the day it is started, with clear ownership at each step.

Why airlines differ from a generic consumer brand

Most brand protection analysis of onchain TLDs is built around consumer goods or financial services. Airlines have a different shape of exposure, for five reasons that add up.

Transaction size and timing. A flight purchase is large relative to a typical retail transaction, and it is often made under time pressure: the fare may change, the seat may go. The customer follows a payment instruction to a destination they have never verified before. A name such as pay.yourbrand or book.yourbrand resolves in a supported wallet to whatever address has been set for it. The customer sees a name they associate with the carrier. The instruction looks routine.

Loyalty balances as a second currency. Frequent-flyer points carry redemption value. They sit in accounts that many members open only a few times a year, so an unusual prompt is less likely to stand out. A name that appears to belong to the carrier’s loyalty program creates a plausible invitation to log in or to transfer a balance. Being onchain does not make that prompt more or less plausible to most members. It does change the response path, because there is no registrar to write to.

Distributed sales. Airlines do not sell only through their own channels. Travel agencies, corporate booking tools, online aggregators and wholesale consolidators all sell seats legitimately under the carrier’s name. Customers are therefore used to third-party interfaces that carry the carrier’s branding. A name issued under .yourbrand by a party with no authorization from the carrier fits naturally into that expectation.

Alliance and codeshare identity. A carrier that operates under an alliance name, a regional brand or a codeshare designator has several names in circulation that customers associate with it. Each of those names is a candidate TLD. The file cannot be limited to the legal entity’s primary registered trademark. It extends to every name under which seats are sold or customers are served.

Irregular operations. Impersonation is most effective outside the steady state of normal operations. The sensitive period is the hours after a mass cancellation, when thousands of passengers look for refund instructions, rebooking tools and support contacts at the same time. A name under a TLD the carrier does not hold can be pointed at a new destination during exactly that period, and the carrier has no say over it.

For a generic consumer brand, one or two of these factors may apply. For a carrier of any size, all five apply at once.

Bookings, refunds and loyalty: where customers follow payment instructions

The three moments of highest exposure are also the three moments when customers act fastest.

At booking, a customer is completing a transaction they have already decided on. The fare has been found and the dates work. The final step is payment. If that step presents a name such as pay.yourbrand, the customer has no practical way to tell an instruction authorized by the carrier from one set up by an unrelated party. The name is readable and memorable. The address behind it is not something most customers inspect.

At refund, the dynamic is reversed and the customer is less careful. They believe the carrier owes them money, and they follow instructions they believe came from the carrier in order to receive it. A request for a “processing deposit”, or for account details needed to release the refund, works on a customer whose attention is on receiving and not on checking where they are sending.

Loyalty balances sit in a slightly different category. They are not as liquid as a card payment, but they have clear monetary value. A name that presents itself as the carrier’s loyalty portal and prompts a login, a points transfer or an account verification follows the same logic as conventional credential phishing, with the added weight of appearing to live under the carrier’s own name. Payments to a name work in supported environments, and coverage is partial, so the scenario is narrow but not hypothetical.

Passengers are not the only ones who follow payment instructions. Cargo customers, freight forwarders, group travel organizers and corporate accounts settle invoices on instructions sent by the carrier’s commercial teams, often for larger sums and through staff who process many such requests. A change of payment details that arrives under a name matching the carrier deserves the same scrutiny in a forwarder’s accounts department as it would at a check-in desk. The review should therefore cover business payment flows as well as consumer ones.

One limit should be stated plainly. A name such as pay.yourbrand is resolved outside the ICANN DNS root, which is why a passenger’s ordinary browser does not open it without support. The carrier’s booking engine, its app and its email all run on the DNS, and for reaching the general public the DNS is simply better. The exposure described here concerns customers who use wallets and browsers that support these names. That group is a subset of the customer base, and its size is something the digital team can estimate better than any outside adviser.

The practical implication is that the payment and loyalty operations groups belong inside the review, not downstream of it.

Agents and resellers who sell legitimately under the carrier’s name

Airlines routinely authorize third parties (consolidators, tour operators, corporate travel management companies, regional agents) to sell under the carrier’s designator and, in many cases, to use the carrier’s marks in their own marketing. This creates a legitimate ecosystem of names that customers associate with the carrier and that the carrier does not fully control.

An onchain TLD creates a parallel structure. Whoever holds .yourbrand can issue names to any party it chooses, and those names will read, to a customer, as if they belong to the carrier. If a reseller obtained bookings.yourbrand and used it in a payment flow, the carrier would face customer confusion, and possibly complaints addressed to it, without having authorized or even noticed the arrangement.

The more precise question is contractual. Reseller agreements typically cover conventional domain names, social media accounts and advertising guidelines. Many were drafted before names issued under an onchain TLD were a practical possibility, and they may say nothing about them. The review should ask whether those agreements need a clause on onchain names, and whether any existing agent is using a name under a TLD the carrier does not hold.

A workable clause is short. It states that the agent uses only names the carrier has approved in writing, in any naming system, and that payment instructions sent to the carrier’s customers point only to destinations on an approved list. It does not need to describe the technology. Drafting it is a matter for the carrier’s own counsel, and the rules on agency and trademark licensing vary by country.

This is distinct from the impersonation scenario. An authorized agent using an onchain name intends no harm. But the carrier’s brand governance extends, in principle, to every channel where customers are directed to pay money or hand over credentials in connection with its services. Onchain names belong on that list of channels.

Alliances, codeshares and sub-brands

A carrier that belongs to an alliance operates under at least two names in the market: its own and the alliance’s. Both are candidate TLDs. A carrier that operates regional feeders, low-cost subsidiaries or seasonal charter brands may have several more names in active customer circulation. Each one is exposed separately.

Codeshares add a further category. A flight that a customer books with one carrier is sometimes operated by another, and the booking confirmation names both. Customers do not always distinguish between the operating carrier, the marketing carrier and the alliance. A name that borrows the vocabulary they share, such as miles.yourbrand or status.yourbrand, speaks to the combined customer base of the partnership and not only to one carrier’s passengers.

The alliance name raises a question of its own: who owns the file. The mark usually belongs to a jointly governed entity, not to any single member. If the alliance name exists as an onchain TLD, no member carrier can decide alone to approach the holder, and each may assume another has looked. The sensible step for a member’s general counsel is to check, record the finding and raise it through the alliance’s own legal channel.

Sub-brands used for co-branded cards, cargo operations, holiday packages and in-flight retail also create exposure. These businesses often have their own identities, their own customer-facing names and their own payment flows. The review should list them explicitly and not assume that the primary name covers everything.

A practical starting point is the carrier’s trademark portfolio. Every mark in force that covers air transport or loyalty services is a name to check against the onchain registry. The Namespace Exposure Score gives a structured first view of how exposed a brand is onchain.

Irregular operations: the window of highest exposure

When a carrier cancels a large number of flights, several conditions arise together. Thousands of passengers are anxious and actively searching for information. Customer service channels are saturated and slow to answer. The carrier’s own messages are spread across the app, text messages and email. Media coverage makes the carrier’s name highly visible to everyone, including those with no good intentions.

In those hours, a customer is more willing than usual to follow an instruction without pausing to verify it. A name under .yourbrand can be pointed at a new destination with a single blockchain transaction, and no registrar stands between the party who controls the name and the change. A request for a “rebooking deposit”, or for account verification before a refund, can therefore circulate while the disruption is still unfolding, and the carrier’s customer service team may learn of it only from the passengers who ask whether it is genuine.

Response capability matters as much as the initial exposure. A carrier that holds its own TLD decides which names exist under it, and can say so publicly in one sentence: only names the carrier has issued are official. A carrier that does not hold it controls nothing about what those names resolve to, and its public statement has to be longer and less certain.

The disruption playbook is the place to settle this in advance. It should name who checks for unauthorized names when a major event starts, which channels carry the warning to passengers, and what the wording is. Preparing that wording on a quiet day costs little. The page on what works today lists which capabilities of onchain TLDs are operational in supported environments, with sources, and helps size the scenario realistically.

Exposure by function inside the carrier

The review is not a single-team exercise. An onchain TLD touches different functions in different ways, and each has a distinct role in the response.

No single function sees the whole exposure. A cross-functional working group, convened under legal privilege where the jurisdiction permits, is a sound way to run a review of this kind. The page for brands and legal teams is written for the people who usually lead it.

Eight checks and the function that owns each

1. Registry check across all names in circulationCheck every trademark, sub-brand, alliance name and loyalty program name against the onchain registry. Record whether the TLD exists, whether names have been issued under it, and whether any of them is in use. Owner: legal and brand protection.
2. Payment-flow mappingList every payment instruction the carrier sends to passengers and business customers (booking confirmations, refund notices, loyalty redemption prompts, cargo and group invoices) and note which could be imitated under a matching name. Owner: digital and customer operations.
3. Loyalty authentication reviewTest the authentication required for loyalty account access and points transfers against the scenario of a member directed to a plausible onchain name. Note whether existing controls would stop the use of credentials obtained that way. Owner: loyalty program and IT security.
4. Reseller and codeshare agreement auditReview third-party agreements for coverage of onchain names. Confirm whether agents are limited to names the carrier has approved, and whether any agent uses a name under a TLD the carrier does not hold. Owner: commercial, procurement and legal.
5. Irregular-operations playbook reviewRead the disruption communications plan against the impersonation scenario. Add a step for checking unauthorized names under the carrier's TLD when a major disruption starts, and prepare the passenger wording in advance. Owner: customer operations and corporate communications.
6. Trademark portfolio gap analysisIdentify every name in active customer use that is not covered by a registered trademark in the carrier's main markets. An unregistered name generally leaves fewer remedies if a matching TLD is held by someone else; the carrier's counsel assesses this country by country. Owner: legal and IP.
7. Onchain monitoring setupPut in place ongoing monitoring of names issued under any TLD that matches the carrier's brands, so that a new name is noticed without a manual search. This is separate from DNS monitoring. Owner: brand protection.
8. Decision on each TLDFrom the registry check and the risk assessment, decide for each relevant TLD whether to monitor, to have the holder approached, or to ask counsel to assess a challenge. Record the decision and the reasons. Owner: legal, with sign-off from the general counsel.

The first six checks can run in parallel, and none of them requires contact with anyone outside the organization. The last two depend on their results.

The options and who should own the file

Once the registry check is complete and the exposure is mapped, the carrier has three broad paths. They are not mutually exclusive.

Monitor without immediate action. Where a TLD shows no sign of deployment, and the carrier’s disruption playbook can absorb the risk, monitoring may be the appropriate position. It requires a real monitoring capability: an ongoing watch on names issued under the TLD, not an occasional manual check. The Namespace Watch service covers this. A monitoring position should be reviewed at fixed intervals and after every major disruption.

Have the holder approached. Where the TLD is held by a party who is not impersonating the carrier and may be willing to transfer it, a quiet approach through an intermediary is usually preferable to a public demand. A direct approach by the carrier, or by outside counsel visibly acting for it, tells the holder who is interested and can affect the price. An approach through an intermediary, under a mutual NDA, keeps the carrier’s choices open. Brand namespace recovery is the service for this kind of mandate.

Challenge where grounds exist. Where the use of the TLD or of names under it infringes a registered trademark, the carrier’s counsel should assess which remedies are available. The UDRP, the dispute policy that binds registrants of ICANN domain names through their registration agreements, does not extend to onchain TLDs, so the routes are different and depend on the jurisdiction and on whether the holder can be identified. The registry record is public and anyone can check it on a block explorer, but a wallet address does not by itself name a person. This is analysis for the carrier’s own counsel, and the answer is not uniform across countries.

The file should be owned by the general counsel or a senior member of the IP team, not handed entirely to an outside monitoring provider. The decisions that arise (approach or wait, acquire or challenge, update reseller agreements or not) require authority and judgment. The operational tasks in the checklist can be delegated. The file cannot.

There is a sector reason for placing ownership in legal and not in digital or marketing. In an airline, the functions most affected, such as loyalty, customer operations and commercial, each see only their own payment flows, and each has its own relationship with agents and partners. Legal is the one function that reads all the agreements and can keep the finding confidential while a response is prepared.

What holding the TLD lets a carrier do beyond defense

The analysis above is framed as risk management. That is the right starting frame for a carrier that does not hold its TLD. A carrier that does hold it gains capabilities that are operationally useful.

One readable payment name. A carrier that holds .yourbrand can issue pay.yourbrand and set the address it resolves to. The record is public, so anyone can check it on a block explorer. That is easier to communicate than a long string of characters, especially during a disruption, when the carrier needs to tell passengers in one line where refunds come from and where payments go. A payment router such as shaka lets a payment link pay out to a name instead of a raw address, with the split between parties agreed and signed onchain before funds move, which suits a sale shared between a carrier and an agent.

Names for AI agents. A carrier that deploys AI agents for customer service, rebooking or ancillary sales can give each one a name under its own TLD, tied to the carrier and not to a third-party platform. The page on identities for AI agents describes this. The relevant Ethereum standard, ERC-8004, is a draft and may change, and how naming registries plug into it is still evolving.

Governance of the partner ecosystem. A carrier that holds its TLD can issue names to authorized agents on its own terms. This inverts the reseller problem. The carrier no longer tries to prevent uncontrolled use of its name in a namespace it does not govern: it is the only party that can issue names there. An authorized agent has a name under the carrier’s TLD, and any name the carrier did not issue does not exist. That is a governance structure, not only a brand signal.

Registration revenue. On Freename, the registry’s royalty program gives the holder of a TLD a share of each registration fee for names registered under it, advertised at up to half, subject to the registry’s current terms and activation conditions. Taking part in the program is not free: the registry sets an annual cost for it. Some TLDs were registered under earlier terms that include the program for life, and a carrier acquiring one should confirm with the registry, before closing, whether those terms pass to a buyer. For an airline this is secondary. A carrier’s namespace is more likely to be closed, with names granted to partners, than open to public registration.

Low carrying cost. There is no annual renewal fee on a Freename TLD. Holding the TLD for defensive reasons, and deciding later whether to use it, does not create a recurring registry charge, as long as the carrier stays outside the royalty program. Custody is the real ongoing duty: the token sits in a wallet, and the carrier’s treasury or security team should hold it in a multisignature wallet, one that requires several approvals before anything moves.

Activation after the transfer. Acquiring the TLD opens the operational question. The configuration work (payment names, a policy for issuing names, partner onboarding, wallet security) is substantial. The post-transfer activation service addresses the step from a TLD that is held to one that is in use.

The first step, before any of this is in scope, is to know what exists onchain under the carrier’s names. The Trademark Name Check is free. Give the result to whoever owns the file, and start the eight checks from there. If the result shows a TLD that matters, Hush Partners can be mandated to find and approach its holder, through the contact form on the site.

Questions people ask

Does the holder of an onchain TLD have the same legal standing as a domain registrant in the DNS?

The two systems are distinct. A Freename TLD is a token on a blockchain, not a registration in the DNS coordinated by ICANN, and the UDRP does not reach it. Which rights the holder has, and which remedies a trademark owner can pursue, depend on the law of the relevant jurisdiction and on whether the holder can be identified. The carrier’s own counsel advises on each country where it operates.

If the TLD does not open in ordinary browsers, is the risk lower?

Lower, but not absent. Without an extension or a supported wallet, an ordinary browser does not open these names, so pay.yourbrand cannot reach the general public through a standard browser. A passenger can use a Freename name in three places: Bitcoin.com Wallet, MetaMask by way of Freename’s resolver, and a desktop browser fitted with the Freename Web3 extension. Coverage is partial and changes. The review should record where coverage stands when it is carried out and be repeated at intervals.

Who inside the organization should receive the initial findings?

The general counsel first, under whatever privilege applies in the jurisdiction. The findings show which names exist onchain under the carrier’s brands and whether any is in use. That information is sensitive: it informs negotiation, possible legal action and public communications, and circulating it before a response is agreed can narrow the organization’s choices. Once the response is agreed, the digital, loyalty and customer operations teams are briefed at the level of detail their role requires.