Onchain TLDs and delivery companies: what to check

A delivery company’s name does not stay on a label in a warehouse. It sits on the doorstep of every recipient, on every driver’s uniform, and on every notification sent to a consumer who did not choose the carrier and cannot easily verify it. That visibility is what makes the name worth imitating, and it is also what makes the onchain namespace a specific concern for this sector and not a generic one.

An onchain TLD is a top-level domain that exists as a token recorded on a public blockchain and sits outside the ICANN DNS root, and one of them can be the name of a carrier. The TLD .yourbrand can exist, and only whoever holds that token can issue names under it: pay.yourbrand, track.yourbrand, customs.yourbrand. Those names can point to wallets that receive payments and to websites, and work is under way on identities for AI agents. If the holder is not the carrier, the gap between the token and the organization fits the kinds of misuse delivery companies already deal with.

This guide maps that exposure for fraud and brand teams at parcel and freight operators. After reading it you will know where the exposure concentrates in this sector, which function inside the organization owns each part of it, and what to check first.

Why logistics is a different case from most brand categories

Every well-known organization has some version of the onchain TLD question: a name that reads like theirs can exist in a namespace they do not control. Delivery companies face four structural conditions that widen it.

The first condition is contact frequency. A carrier reaches consumers each time a parcel moves, through a channel the consumer did not start. A message that carries a link or a payee name such as track.yourbrand fits into a flow of communications the recipient is already expecting. Nothing about it looks like cold outreach: it arrives when the recipient knows a parcel is in transit.

The second condition is payment expectation. Recipients are regularly asked, by legitimate carriers, to pay import duties, redelivery fees or address correction charges before a parcel is released. That expectation is part of how consumers understand delivery. A payment request under a name that matches the carrier fits the pattern, whether the request is genuine or not.

The third condition is the subcontractor layer. Parcel and freight operators work through local partners, last-mile contractors and regional agents who are entitled to use the brand in their communications. A recipient who sees northregion.yourbrand has no easy way to tell an authorized local partner from a name issued under a TLD the carrier does not hold.

The fourth condition is freight. Brokers, forwarders and customs agents exchange payment instructions in the normal course of business. An instruction that cites a credible name in what looks like the carrier’s namespace is harder to challenge than one from an unrelated domain.

A software publisher, a consumer goods brand or a bank meets one or two of these conditions. A delivery operator meets all four at once.

How far the exposure reaches in practice

The limits matter as much as the conditions. Because resolution of an onchain name happens outside the ICANN DNS root, a recipient’s ordinary browser will not open one unless support has been added. For Freename names that support exists in Bitcoin.com Wallet, in MetaMask via Freename’s resolver, and in desktop browsers that run the Freename Web3 extension. Coverage is partial and it changes.

For a carrier, that means the recipient of a parcel who taps a link on a phone will often see nothing at all. The exposure is narrower than with a lookalike DNS domain, and for mass consumer messaging the DNS remains the main channel on both sides. The onchain exposure concentrates where a wallet is already in use: a payment requested to a name, a counterparty that settles onchain, a recipient who already holds a wallet that resolves these names. The page on what is live keeps the current state of resolution with its sources, and it is the reference to give your security team.

Delivery fees and customs payments requested from recipients

The fee paid before release is the sharpest consumer exposure for this sector. Recipients expect to pay in specific circumstances: import duty, storage, address correction, rerouting. Those expectations are well established, and they have long been imitated with lookalike web domains.

What changes onchain is the payee. A name under a TLD can stand in for a raw wallet address as the destination of a payment. A raw address is a long string of characters that tells the payer nothing. A name such as duties.yourbrand tells the payer something, and what it says is the carrier’s name. The recipient sees a name that reads like the carrier, an amount consistent with a customs charge, and a payment step with none of the usual signs of a careless imitation.

The page on payments to a name describes the capability. A router such as shaka lets a payment link pay out to a name instead of a raw address, and the split between parties is agreed and signed onchain before funds move. It routes funds and does not hold them. The infrastructure is neutral: it serves a carrier that holds its TLD in exactly the same way as any other holder of a name.

Three features of delivery fees make them a good fit for this pattern, and each one can be managed.

• Small amounts. A duty or redelivery charge is usually modest next to the value of the parcel. A recipient pays it without the scrutiny given to a larger payment, and is less likely to report it afterwards. Your contact center may see the pattern only as a rise in “where is my parcel” calls.
• A third party sets the amount. Import charges are assessed by an authority, not by the carrier, so the recipient does not expect to recognize the figure. No price list exists to compare it with.
• The payer is not the customer. The shipper chose the carrier and holds the contract. The recipient has no account, no login and no prior payment history with you, so there is no trusted channel to fall back on.

For fraud teams, the implication is specific. The question a recipient asks, “does this look like it comes from the right organization?”, is answered by the name. The useful question is a different one: is the TLD behind the name held by the carrier? Only the carrier can answer it publicly, by stating which payment channels it uses and by saying plainly, where it is true, that it never requests a fee to a wallet or to an onchain name.

The parcel notification as the most imitated message of the sector

The shipment notification is the message of this sector that is imitated most readily. It carries a tracking number, a delivery window, a reference to an address, and often a call to action: confirm, reschedule, pay. Legitimate operators have taught recipients to respond to exactly these elements, and the message lands at a moment of active expectation.

The onchain namespace adds something that a lookalike DNS domain does not. A DNS domain passes through a registrar, registration data can be watched, and established complaint and dispute procedures exist. A name issued under an onchain TLD is a record on a public blockchain. It does not pass through an ICANN-accredited registrar, and it is issued by whoever holds the TLD.

The record is public, which is an advantage: anyone can read it on a block explorer. But the tooling that watches DNS registrations does not read it. Watching the DNS for your brand is necessary and it is not sufficient. A monitoring service for onchain names covers the part that DNS monitoring leaves out.

For the notification itself, the structural point is that the recipient is already expecting it. A name such as notify.yourbrand or track.yourbrand does not need to match your website address. It needs only to read as yours, and a recipient has no habit of checking who holds a TLD.

Notifications also travel through channels the carrier does not fully control. The shipper’s own store sends order updates that mention you. Marketplaces relay tracking events. Parcel shops and lockers generate pickup codes. A recipient therefore receives messages about one parcel from several senders, in several styles, and has learned to accept that. A carrier cannot make every one of these messages uniform, but it can make its own unmistakable.

The practical answer is to tell recipients, consistently, which names and channels your organization uses in delivery notifications and which it never uses. That statement belongs in the notification itself and on the tracking page, where the recipient is looking, and not only in a help article.

Subcontractors and local partners using the brand

A carrier’s network includes entities that use its name with permission. A regional franchise, a last-mile partner, a returns handler or a pickup point may all send messages under the carrier’s name, and recipients understand that a third party is carrying out the service.

That structure of delegated use creates a specific problem onchain. If the TLD that matches the carrier’s name is held by someone else, that holder decides who receives names under it. A local operator who obtains northeast.yourbrand from the holder is not acting as a subcontractor of the carrier. The carrier has no say over that name, and a recipient cannot tell it from an authorized regional partner.

The exposure runs in both directions. From outside, recipients may be misled by names the carrier never approved. From inside, a well-meaning partner may register or acquire a name under what it believes to be the carrier’s namespace, to look more official in its own territory, without knowing the carrier does not hold the TLD. The second case is not misconduct. It is a gap in instructions.

Partner names also outlive partnerships. Contracts with last-mile operators turn over, territories are redrawn, depots change hands. In the DNS, a carrier that hosts partner pages on its own domain removes them when the contract ends. Under a TLD it does not hold, a name that once pointed to a real partner can keep pointing somewhere after the relationship is over, and nobody at the carrier is told.

The work falls to the partner management function. Agreements with subcontractors and local agents should address the onchain namespace in plain terms: which names a partner may use, whether the carrier operates in any onchain namespace at all, and what a partner should do when a counterparty asks to communicate or settle through an onchain name. Agreements drafted with web domains and email addresses in mind may not cover any of this.

Freight counterparties and payment instructions

The freight side of this exposure is distinct from the consumer side. It is handled by a different function, and the amounts and the checks are of a different kind.

In freight, payment instructions pass routinely between carriers, forwarders, customs brokers, port agents and corporate shippers. A change of bank details or a request to settle through another channel is not suspicious in itself. It happens when banking relationships change, when a local agent handles a settlement, or when payment terms are renegotiated.

A name in what looks like the carrier’s namespace changes that context. A payment instruction that cites settlements.yourbrand or accounts.yourbrand reads as if it came from inside the carrier’s own payment operations. A counterparty’s finance team that has never had to check who holds a TLD will apply the same test a consumer applies: does the name look right?

A single commercial settlement is far larger than a consumer fee, so one misdirected freight payment weighs more than many misdirected duty payments. The volume is lower and the parties are professionals, but the consequence of one error is of a different order.

Freight also has a feature that consumer delivery lacks: goods are often released against payment. Cargo waits at a terminal or a warehouse until charges are settled. The party asked to pay is under time pressure, because release windows are short and storage charges accrue while cargo sits. That pressure is the condition under which a verification step gets skipped.

The chain of parties adds to it. A shipment may involve a shipper, a consignee, one or more forwarders and a customs broker, each of whom relays documents from the others. An instruction that reaches the payer third-hand has lost most of the context that would let anyone judge where it came from.

The check for accounts and treasury is the one fraud teams apply to consumers, pointed the other way. Before acting on any instruction that cites an onchain name carrying your organization’s name, confirm that the name sits under a TLD the organization holds. If the organization holds none, the rule is simpler: no instruction citing such a name is yours. Your counterparties need the same rule in writing, and a contact they already know to confirm any change of payment details.

Exposure by function inside the organization

Different teams carry different parts of this exposure. The table maps the main exposure to each function and names what that function owns.

Two rows deserve a comment. Customer communications is rarely invited to a brand protection meeting, yet it writes the templates that teach recipients what a genuine message looks like. And the driver and depot workforce, which IT and security covers, is a large audience in its own right: drivers receive route changes, pay notices and app updates on personal phones, often from subcontractors, and are as used to mixed senders as recipients are.

No single function sees the whole exposure. The fraud team sees consumer reports, treasury sees a disputed settlement, partner management sees an odd request from an agent. Each observation looks minor alone. That is the argument for one owner of the file, covered further down.

Nine checks to run, and who runs them

The checks below are ordered so that the first three establish the facts and the next five test the organization’s own readiness. Each can be handed to its owner the same day, and none requires contact with anyone outside the organization. The last one turns the findings into a decision.

1. Check whether your TLD exists onchainRun the brand name through the Trademark Name Check and the Namespace Exposure Score, the free tools on this site. The record kept by the registry is public, so whoever runs this check can read it on a block explorer. Do this before any other step. Owner: legal or brand protection.
2. Check which names have been issued under the TLDIf the TLD exists and the organization does not hold it, look at the names already issued under it, with particular attention to words used in delivery: track, notify, pay, duties, customs, returns, and the names of your regions. The picture informs both the risk assessment and any later conversation about acquisition. Owner: legal or brand protection, supported by IT.
3. Check whether any issued name points to a payment address or a websiteResolution of onchain names is partial and changes, so test in the wallets and browsers that support them. A name that points to a payment address or a published site is in use, and a name that points to nothing is not. Owner: IT and security.
4. Review partner agreements for onchain namesRead current subcontractor, franchise and last-mile agreements for the clause on authorized use of domains and names. Note whether it reaches onchain names, and pass any gap to the team that manages renewals. Owner: partner management, with legal.
5. Review the verification rule for payment instructionsCheck whether accounts and treasury have a rule for an instruction that cites an onchain name, and whether freight counterparties have been told what the organization does and does not use. If there is no rule, draft a short interim one pending the ownership decision. Owner: treasury and finance.
6. Check the notification templatesReview every outgoing template (shipment confirmation, delivery attempt, fee request, customs notice, pickup code) for a line that tells the recipient which names and channels the organization uses. Add it where it is missing, at the next template revision. Owner: customer communications.
7. Brief the contact center and the driver channelsGive agents a short script for a recipient who asks about a fee requested to a name, and a place to log such reports. Tell drivers and depot staff which channels carry genuine operational messages. Owner: customer service and operations.
8. Establish the trademark position and the monitoring scopeConfirm which registered trademarks cover the name and in which countries. The UDRP binds registrants of ICANN domain names and does not reach onchain TLDs, so the usual domain dispute route is not available here. Confirm also whether current brand monitoring reads onchain names or only DNS registrations. Owner: IP counsel, with brand protection.
9. Set a date for the ownership decisionBring the findings to legal, brand and senior management, and set a date by which the organization will have chosen between acquiring the TLD, monitoring it, or accepting the position on the record. Owner: general counsel or the head of brand.

The options and who should own the file

Once the checks are complete, the organization has three options. The choice depends on whether the TLD exists, which names have been issued under it, and what the trademark position supports.

Acquisition is the option that removes the exposure on the exact-match TLD. Only the holder of a TLD can issue names under it, so once the organization holds .yourbrand, no new name appears there without its decision. Names issued before the transfer need a separate look: review them as part of the file. Those the seller itself holds can be transferred along with the TLD if both parties agree to it, whereas names already sold to third parties stay with those third parties. The route is a commercial negotiation and not a dispute procedure. In a brand namespace recovery, the organization mandates the desk to find and approach the holder. A standard mutual NDA applies to each exchange in that mandate, and the carrier closes through onchain escrow on an aftermarket.

Monitoring without acquisition suits the case where the TLD exists, no name under it is in use, and the organization judges the exposure to be low. It does not remove the structural exposure. It tells you when the facts change, so that the decision can be reopened on evidence.

Accepting the position after a full assessment is also a decision, and it should be documented as one. If legal and brand have reviewed the facts and concluded that the exposure is acceptable, record that conclusion with the supporting analysis.

Whether any legal route exists besides negotiation depends on the country, the trademark and the facts. This guide is information and not advice: your own counsel decides.

Who owns the file

The file belongs with general counsel or the head of brand, and not with IT or the fraud team alone. The decision has legal, commercial and reputational sides that sit above the operational level, and it draws on functions that do not report to each other: treasury for freight settlements, partner management for the network, customer communications for the templates.

In a carrier, there is a further reason. Operations will ask whether any of this slows a parcel down, and the answer has to come from someone with authority over both the brand and the service. The page for brands and legal teams is written for the people who usually carry this file.

What holding the TLD makes possible, beyond defense

For most organizations in this sector, acquiring the TLD is first a defensive step. Control of the namespace also opens uses that suit a delivery operator, and they are worth understanding before the decision is made.

Names for the partner network

The first use is a structure of names for the network. A carrier that holds .yourbrand decides which names exist under it, and can issue northeast.yourbrand to an authorized regional partner. A partner that wants to appear under the carrier’s namespace has to be given the name by the carrier, and the record of that issuance is public. Recipients and counterparties get one rule to remember in place of a list of partner domains. Before relying on this for partners that come and go, check with the registry how an issued name is held and what happens to it when a partnership ends.

A positive rule for payments

The second use concerns payments. A carrier that holds its TLD can designate names for its own treasury, for example duties.yourbrand for customs settlements and returns.yourbrand for commercial refunds, and tell counterparties that an instruction citing any other name is not the carrier’s. That replaces a negative rule with a positive one. Counterparties are no longer asked to spot a doubtful name. They are given the short set of genuine ones. Whether to accept onchain payments at all is a treasury and compliance decision that comes first. The service for putting a TLD to work after the transfer covers what the setup involves.

Tracking pages and automated agents

A holder can also publish a website on a name, such as a tracking or returns page. The limit stated earlier applies in full: only browsers and wallets with support will open it, so for the general public the DNS site remains the place to send people. An onchain page complements it and does not replace it.

The last use is further out. Where a carrier uses automated agents for customer service or freight coordination, the question of whether an agent genuinely speaks for the carrier follows. ERC-8004, “Trustless Agents”, is a draft Ethereum standard that defines three registries, for identity, reputation and validation. The standard is still a draft that may change, and the way naming registries will plug into its registries is still evolving. The page on identities for AI agents follows that subject.

None of these uses has to be decided at the point of acquisition. Holding the TLD keeps the options open, and what is activated, and when, is a separate decision. The free Launch Roadmap tool on the site turns that decision into a phased plan.

Questions people ask

Does holding the TLD stop others from using different onchain names?

No. Holding .yourbrand gives you control of names under that TLD only. It does not prevent someone from holding a different TLD, such as a spelling variant or a sector word like .yoursector, and issuing a name under it that includes yours. Monitoring should cover the wider namespace around the brand, and the Namespace Exposure Score gives a first view of it.

How is an onchain TLD different from a conventional domain for this purpose?

A conventional domain is registered through an ICANN-accredited registrar, falls under the UDRP, and follows the policy of its registry. An onchain TLD such as .yourbrand sits outside the ICANN root, is recorded as a token in a wallet, and is not reached by the UDRP. In practice the way to control an onchain TLD you do not hold is to acquire it. The page on trademark TLDs covers the distinction in more detail.

What happens if the holder does not want to sell?

A holder is free to decline, and no procedure compels a transfer. The organization is then in the monitoring position described above, with the checks on templates, partner agreements and payment instructions still worth completing. Those checks protect recipients and counterparties whoever holds the TLD.

What does it cost to keep the TLD once acquired?

The acquisition is a one-time commercial payment agreed with the holder. On Freename, there is no annual renewal fee on a TLD, which keeps the ongoing cost simple. The cost that remains is internal: someone has to own the wallet that holds the token, and that custody should be assigned to a function, not to an individual.