# Onchain TLDs and energy companies: what to check

> A sector guide for energy companies: why a TLD matching the name matters here, where the exposure sits, and a short list of checks.

Source: https://hush.partners/onchain-tlds-and-energy-companies
Category: Brand protection
Published by Hush Partners.

---
An energy supplier's name sits in almost every household in the territories it serves. It appears on bills, direct-debit mandates, smart-meter displays, payment portals and commodity contracts. That breadth of everyday presence is also the source of a specific exposure: when someone other than the organization holds an onchain TLD that matches its brand, the room for confusion is concentrated exactly where the brand touches money.

For an energy group, the object in question is a top-level domain that exists as a token recorded on a public blockchain: an onchain TLD. It plays the same structural role as `.com`, but it is held in a wallet instead of being delegated through the ICANN DNS root. On Freename, only the holder can issue names under it, such as `pay.yourbrand` or `account.yourbrand`, and there is no annual renewal fee. Because onchain names resolve outside the DNS, an ordinary browser does not open them without support, and the dispute procedures built for domain names do not reach them.

This guide works through what is distinctive about the energy sector's exposure, maps it by function inside a typical group, and ends with a checklist that can be delegated the same day. By the end, your team will know where to look, who should own each item, and what holding the TLD would let the organization do.

## Why energy is different from a generic brand

Most consumer brands are names that customers meet occasionally: in a store, in an advertisement, during a purchase. An energy brand is part of the household's routine. The bill arrives at regular intervals. The direct-debit instruction carries the name. The payment portal is opened under time pressure when a customer is trying to avoid a disconnection. That routine familiarity creates a baseline of trust, and a name that looks plausible under a familiar TLD borrows it.

The second distinction is the mix of audiences. A single energy group typically operates a regulated supply brand that households recognize, a network or distribution brand that installers and professional counterparties deal with, and a wholesale or commodity trading entity whose counterparties move large sums and verify payment instructions carefully. Each of those audiences is exposed in a different way, and the consequence of being misled is different for each.

The third distinction is that energy supply is a necessity. A shopper who hesitates over an unfamiliar link on a retail website can close the tab and come back later. A customer who is behind on an energy account, managing debt, or responding to a disconnection notice does not feel that freedom. The care a utility is generally expected to show its customers, and above all the most vulnerable ones, extends as a practical matter to the channels through which they pay. A name that resembles a payment or account-management address falls inside that expectation, whoever issued it.

The fourth distinction is that the customer did not choose the relationship in the way a shopper chooses a store. In many places a household inherits its supplier with the home, or has a single network operator whatever supplier it picks. People act on messages from a utility because they must, and they rarely check them. The question for you is whether the organization understands what an onchain TLD matching its name adds to that picture, and whether the question sits with the right internal owner.

## Bills, payment reminders and the household payment flow

The most concentrated exposure in the sector is the payment instruction. A household bill carries a brand name, an account number and a set of ways to pay. Payment reminders, top-up links for prepayment meters and emergency credit messages repeat those details. A customer who pays digitally follows a short mental chain: they see the brand name, they go to what they believe is the right address, and they pay.

Under a TLD that matches the brand, the holder can issue a name such as `pay.yourbrand` and point it at a wallet address. In a wallet that supports the registry, a payer then sees the name, and the long string of characters behind it stays out of view. If the name is the utility's own name, the visual cue that would normally prompt a second look is missing. The capability to issue names and to make them resolve in wallets works already, within the partial support described on the page that tracks [what is live](/whats-live).

The exposure has honest limits, and you should state them internally. Most households pay their energy bill by bank transfer, card or direct debit, and will never open a wallet. Resolution of onchain names is partial and changes. The households affected are therefore a small share of the customer base. They are also hard to identify in advance, and a utility does not get to choose which of its customers is misled.

### Why reminders matter more than bills

A bill is expected. It arrives on a known cycle, in a known format, and many customers do nothing with it because the direct debit runs on its own. A reminder is different. It arrives outside the cycle, it tells the customer that something is wrong, and it asks for action within days. It may come as a letter, a text message or an email, and its format varies with the collections stage.

Suppliers also add payment channels over time: an app, a top-up service, a payment partner in local shops. Customers have learned that a new way to pay can be genuine. A reminder that points to an unfamiliar name carrying the supplier's brand therefore does not look wrong in itself. Two controls follow, and both are within the organization's own hands whatever happens to the TLD. The first is a single published list of the payment channels the supplier uses, repeated on every bill and reminder. The second is a plain statement, where it is true, that the supplier does not ask for payment to an onchain name.

Payment operations, customer services and the digital team all have a stake here. The function that owns the brand's payment channels should be present when the question is reviewed.

## Supply brands, network brands and trading entities under one group

An integrated energy group rarely operates under a single name. The regulated supply arm, the network or distribution arm, and the wholesale trading entity often carry distinct names, sometimes with a common parent element and sometimes not. In many countries the network business is expected to keep its brand separate from the supply business, and the rules on that separation vary by country. Each name that appears on a document a third party acts on is a separate onchain question, because each can exist as a TLD independently of the others.

### The supply brand

This is the name households recognize, and it carries the payment exposure described above. It is usually the best protected by trademark registrations and the most closely watched in the DNS. It is also the name most often reviewed, so it is rarely the one that gets forgotten.

### The network brand

The network brand appears on connection agreements, metering documents, planned-outage notices and the identity cards of engineers who visit homes. Customers know it less well than the supply brand, and that is the point: they have less to compare it with. A message announcing an engineer visit, a meter exchange or a charge for a new connection is hard for a household to judge. Installers, developers and local authorities also act on correspondence in this name. Network brands often receive less brand protection attention because they do little consumer marketing, and they are the names most likely to be missing from a review.

### The trading entity

The trading entity's name is known to few people, but every one of them is a counterparty with a payment relationship. It appears on master trading agreements, trade confirmations and settlement instructions. A separate section below covers it.

### Legacy names

Groups that have been through acquisitions, rebrands or business separations carry additional surface. A retired name may still circulate on old correspondence, on meters and on equipment in the street, and customers who signed up years ago may still think of the supplier by that name. A TLD matching a retired name deserves the same check as one matching a current name.

The right scope for a review is every name the group uses externally, plus every legacy name that remains in real circulation. The [Namespace Exposure Score](/namespace-exposure-score), a free tool that scores how exposed a brand is onchain, gives a first reading for each name before the review begins.

## Vulnerable customers and the care expected of a utility

Utilities serve the whole population, including customers in financial difficulty, customers on prepayment meters, and customers who depend on a continuous supply for medical reasons. Those customers deal with the brand at moments of stress: when managing a debt, when restoring supply, when applying for support.

The care expected toward them shows in the way suppliers design their communications, their collections processes and their digital channels. The detail of what is expected differs from one country to another, and your own counsel decides what applies to you. The common thread is that a utility is expected to think about how a customer under pressure will read a message, and not only about whether the message was accurate.

Seen from that angle, an onchain TLD is not a hazard in itself. The concern is narrower. A name that looks like a payment or account-management address carries particular weight for a customer who is already under pressure and who has been taught by years of genuine communications to trust that name. The brand's signal is strongest exactly where the customer is least able to absorb a misdirected payment.

There is a second group to consider: the people who act for a vulnerable customer. Relatives, carers, debt advisers and charity workers pay bills and negotiate arrangements on someone else's behalf. They do not know the supplier's usual channels as the account holder does, and they rely on the name more heavily for that reason. Guidance written for them, saying how the supplier takes payment and how it does not, is a low-cost measure that belongs in the review's output.

This shapes how the review is positioned internally. It is a consumer protection question with a brand dimension, and it belongs with the people who already own customer vulnerability, with legal in the lead. A short written record that the question was examined, with the scope and the decision, is worth keeping whatever the decision is. The page for [general counsel and brand protection teams](/brands-and-legal-teams) addresses the same reader.

<aside class="callout">
<span class="callout-label">For legal teams</span>
<h4>Keep the review confidential</h4>
<p>Limit the review to the people who need it, and keep its scope, its findings and any view on value out of general circulation. Put a mutual NDA in place before a name or a position is shared outside the group. Hush Partners works the same way: a standard mutual NDA covers every exchange with it.</p>
</aside>

## Commodity trading counterparties who verify payment details

The trading arm of an energy group works in a different register from the retail business, but it shares one structural feature with it: other people act on its name. Counterparties verify payment details against the entity they know, through a process they have agreed in advance.

In commodity markets that process is usually documented. A settlement instruction or a change of payment details arrives, a back-office or compliance function checks it against the standing record and a known contact, often by calling back on a number already on file, and only then does payment move. The control is designed to catch an instruction that departs from the expected identity of the counterparty.

Two honest limits apply. Commodity trades are, as a rule, settled through bank payments, and an instruction to pay to an onchain name would itself be a departure that a sound process stops. The exposure is therefore narrower than in the retail business. It sits in the supporting material around an instruction: a message, a document or an address that uses a name such as `settlement.yourbrand` to make a request look as if it comes from the group.

The questions to put to the trading entity's operations team are practical. Do the verification procedures say what to do when a message refers to a name outside the DNS? Does the callback rule apply to every change of payment details, whatever channel the request came through? Do counterparties know which channels the group uses to send instructions, and which it never uses?

The exposure does not stop at the group. A counterparty that acts in good faith on an instruction carrying the group's name has a problem of its own, and the commercial relationship absorbs part of it. Groups that have started to accept or make payments in digital assets, for example in trading of environmental certificates where that is done onchain, should look at this more closely. The page on [payments to a name](/onchain-tld-payments) describes that capability as it stands.

## Exposure by function inside the group

The table maps the main exposure to the function that owns the activity concerned. The example names show the pattern to recognize in a registry record.

| Function | Main exposure | Names to look for |
| --- | --- | --- |
| Customer operations | Misdirected household payments, harm to vulnerable customers | `pay.yourbrand`, `account.yourbrand` |
| Trading and treasury | Payment instructions that borrow the entity's name | `settlement.yourbrand` |
| Brand and marketing | Names issued by a third party under the TLD | Any name under `.yourbrand` |
| Legal and compliance | The UDRP does not apply, recourse varies by country | The TLD itself |
| Digital and IT security | Pages that imitate a customer portal | `login.yourbrand`, `portal.yourbrand` |
| Network and distribution | Third parties acting on network correspondence | The TLD matching the network brand |
| Group communications | Retired names still in public circulation | TLDs matching legacy brands |

The legal row deserves a word. The UDRP is a dispute policy for domain names in the ICANN system. It binds registrars and registrants there through their contracts. An onchain TLD sits outside that system. A trademark owner's routes are the registry's own policies, the courts, where the outcome depends on the country and the facts, or a negotiated acquisition. The first two are less predictable than a UDRP complaint. The third depends on the holder being willing to sell at a price both sides accept.

The table also shows why no single function sees the whole exposure. Customer operations knows the payment journeys but not the trademark position. The trading back office knows its verification rules but has no reason to look at a registry. Digital security can read a registry record but does not know which legacy names still circulate. The checklist that follows gives each check to the function that holds the relevant knowledge.

## A checklist of ten checks, each with its owner

Each check below can be delegated as written. None requires contact with anyone outside the group except the last.

<figure class="fig">
<figcaption><b>Onchain name review for an energy group</b></figcaption>
<ol class="fig-steps">
<li><b>Identify every active brand name</b>Draw up the names the group uses externally: supply brand, network brand, trading entity and any sub-brands, including names used in other territories. Owner: brand and legal.</li>
<li><b>Identify legacy names in circulation</b>Add any retired name that still appears on correspondence, meters, equipment or market documentation. Owner: brand and group communications.</li>
<li><b>Check the registry record for each name</b>Search each name as a TLD on Freename and on any other onchain registry the group is aware of. No special access is needed to verify a result: the registry record is open to anyone through a block explorer. Owner: legal or an external adviser.</li>
<li><b>Score the exposure</b>Run each material name through the Namespace Exposure Score and keep the results with the review file. Owner: brand protection.</li>
<li><b>Look at names issued under a matching TLD</b>Where a matching TLD exists, note whether names have been issued under it and whether any resemble a payment, login or account address. Owner: digital and IT security.</li>
<li><b>Review payment verification in trading</b>Confirm that back-office procedures cover a change of payment details whatever channel it arrives through, including a message that refers to a name outside the DNS. Owner: trading and treasury compliance.</li>
<li><b>Check trademark coverage</b>Confirm that registrations cover the names identified, in the classes and territories relevant to supply, network operation and trading. Note the gaps. Owner: IP counsel.</li>
<li><b>Review the journeys of vulnerable customers</b>Go through the payment and account links sent to customers in debt or on prepayment, and confirm that each message states the channels the supplier uses. Owner: customer operations and compliance.</li>
<li><b>Decide the response for each name</b>For every name assessed as material, choose between acquisition, monitoring, both or neither, record the reason, and assign a named owner. Owner: general counsel.</li>
<li><b>Put an NDA in place before any outside contact</b>If the review reaches the stage of instructing an adviser or approaching a holder, a mutual NDA comes first. Owner: legal.</li>
</ol>
</figure>

## The options and who should own the file

Once the review is complete, the organization has four responses available for each material name. Which one fits is for your own counsel to decide.

**Acquisition.** The group mandates a desk to find and approach the holder, agree a price, and close through onchain escrow on an aftermarket. This is the response that puts the TLD, and with it the power to issue names under it, in the group's own wallet. It suits a primary supply brand or a trading entity name. It covers one registry at a time, and it depends on the holder agreeing to sell. The file is owned by general counsel, with brand protection and treasury as stakeholders.

**Monitoring.** Where acquisition is not warranted, because the name is a lesser brand or a legacy name and nothing of concern has been issued under it, the group keeps the TLD under watch and reviews the position when something changes. [Namespace Watch](/namespace-watch) is the service for monitoring the names of a brand onchain. Monitoring informs you. It does not stop a holder from issuing names. The file is owned by brand protection.

**Trademark position.** The group makes sure its registrations are current, that the classes and territories are right, and that the position is documented in case a registry complaint or court action becomes necessary. This does not change the onchain record, but it is the basis of every other route. The file is owned by IP counsel.

**A recorded decision not to act.** For a name with little circulation and no payment role, the right answer may be to do nothing beyond the controls the group already runs. Write the reasoning down and set a date to look again.

These responses combine. A group will typically watch every material name, pursue acquisition for one or two, and strengthen its own communications in any case, since the published list of payment channels and the callback rule in trading protect customers and counterparties whoever holds the TLD.

<aside class="callout">
<span class="callout-label">For general counsel</span>
<h4>Name one owner before the review starts</h4>
<p>The file touches trademarks, consumer protection, payment security and counterparty risk at once. Split between IT security, IP counsel and the brand team, it has no natural lead. One named owner in the general counsel's office keeps it moving.</p>
</aside>

## What an energy group could do with the TLD once it is secured

The case for acquisition is usually made in defensive terms. That is accurate but incomplete. A TLD that matches the organization's name, held by the organization, can also be put to work. Each use below has limits, and for most customer-facing purposes the DNS remains the better tool: every browser opens it, and every customer knows how to use it.

**Named payment addresses.** A name such as `pay.yourbrand` can serve as a payment destination that people can read and that the group controls. An onchain payment router such as [shaka](https://shaka.deal) is the tool for it: the destination of a payment link can be a name instead of a raw address, and the parties agree and sign their split onchain before funds move. It routes funds and does not hold them. For an energy group the plausible first uses are business-to-business: payments to installers and contractors, or settlements between group entities and partners. Household billing is not a realistic early use.

**Controlled name issuance.** Because only the holder can issue names under the TLD, the group can create `engineer.yourbrand`, `meter.yourbrand` or `partner.yourbrand` as identifiers for its own services, field staff or accredited contractors. A third party cannot issue a name under the same TLD on that registry. That exclusivity is useful wherever someone needs to confirm that a contractor or a service belongs to the group, which in this sector includes the engineer at the door.

**A share of registration fees.** If the group issues names under `.yourbrand` to accredited installers or scheme participants against a registration fee, Freename's royalty program gives the holder of the TLD a share of each registration fee, advertised at up to half, subject to the registry's current terms and activation conditions. The group would have to count the other side as well: a Freename TLD has no annual renewal fee, but the registry sets an annual cost for taking part in the royalty program. An energy group buying an existing TLD should also know that some were registered under earlier terms that include the program for life, and should confirm with the registry, before closing, whether those terms pass to a buyer. For most energy groups this is a secondary consideration.

**Identity for AI agents.** ERC-8004, "Trustless Agents", is a draft Ethereum standard and may change. It defines three registries, for identity, reputation and validation, and in the identity registry each agent is a token pointing to its agent card. How naming registries plug into it is still evolving. A group that runs automated agents for customer service or for trading support may want to follow the page on [identities for AI agents under a TLD](/onchain-tld-ai-agents), without building on a standard that is not final.

**Publishing.** Names under the TLD can carry websites published to IPFS, a peer-to-peer network for storing and serving files. Technical documentation or partner material could be published that way. Browser support for onchain names is partial and changes, so this complements the group's ordinary website and does not replace it.

Putting a TLD to work is a project of its own, with its own owner, usually outside legal. The [post-transfer activation](/post-transfer-activation) service covers that stage, after the transfer is complete.

## A first step that stays inside the legal team

Start with scope, before any outside contact. The first two checks of the list, the active names and the legacy names, need nothing but internal knowledge, and they decide the quality of everything after them. The third check, the registry record, is public information that anyone can read. Those three give you the facts. The remaining checks can then go to their owners with a deadline of your choosing.

If the review identifies a TLD that the group wants to hold, [brand namespace recovery](/brand-namespace-recovery) is the service for acquiring the onchain TLD that matches a brand. Hush Partners is a private desk for onchain TLDs, and it acts for organizations that mandate it to find and approach a holder. One named partner follows a file from first note to closing, and closing runs through onchain escrow on an aftermarket. The fee is a fixed amount, never a percentage, and is charged only to the client who mandates the desk.

If your organization has received a note from Hush Partners about a name that matches its brand, the page for [organizations that received a note](/received-a-note) is the place to begin. A party that answers a note pays no fee. To reach the desk, the group's legal team uses the contact form on the site.

## Questions people ask

### Does a trademark registration give direct recourse over an onchain TLD?

Not through the UDRP, which applies to domain names in the ICANN system. A registration supports a complaint under a registry's own policies, a court action, or a negotiation with a holder. How a court treats an onchain name depends on the country and on the facts. Your own counsel advises on the routes open to you.

### Can a TLD be watched without being acquired?

Yes. Monitoring tells you when the position under a matching TLD changes. It does not prevent a holder from issuing names. It is a reasonable first response where acquisition is not warranted, and it leaves every other option open.

### How does an onchain TLD change hands?

On Freename, a TLD is recorded onchain as a token held in a wallet, and a transfer moves that token to the acquirer's wallet. In a transaction through the desk, closing runs through onchain escrow on an aftermarket. The registry record is public, and anyone can check the new holder on a block explorer after closing. Before closing, decide which wallet will hold the TLD and who controls it. A multisignature wallet, which needs several approvals before it acts, is a common choice for an asset held by a company.

### What if the group's name exists as a TLD on more than one onchain registry?

Each registry is a separate namespace with its own record, so the same string can exist as a TLD on several of them. The review should cover each registry where the name appears. Give priority to the registries whose names resolve in the wallets and browsers your customers and counterparties are likely to use.
