# Verifying a counterparty by its onchain name
> A treasury team that pays to a name needs to know the name belongs to the counterparty. What can be checked, and what still needs a phone call.
Source: https://hush.partners/verifying-a-counterparty-by-its-name
Category: Onchain today
Published by Hush Partners.
---
When a counterparty gives you `pay.yourbrand` instead of a long string of letters and digits, the operational picture improves. A name is readable, easy to compare against a contract, and harder to mistype than a wallet address. It also raises a question that a raw address never raised: who controls the name, and can you be sure it belongs to the organization you are paying?
That question is answerable, but not by a single lookup. A treasury team that is used to verifying bank details before a first payment already has the right instinct, and the discipline transfers directly. What changes is the source of the record and the nature of what can and cannot be confirmed onchain. This article walks through each step of a verification routine for payments addressed to onchain names, and it is plain about where the public record ends and a phone call begins.
By the end you will be able to design a written routine that meets the standard of care your team already applies to new banking relationships, adapted to the way names are issued under an onchain [TLD](/glossary), the top-level name such as `.yourbrand` under which names like `pay.yourbrand` are created.
## The discipline treasury already applies to bank details
Corporate treasury has spent a long time hardening the process of adding a new beneficiary. The failure modes are well understood: account details that belong to a different entity, details changed without notice, and the fraudulent "updated bank details" message that redirects a payment to an account the supplier does not control.
The response to those risks is a layered routine. Before a first payment leaves, most teams confirm three things independently: that the account details match a known legal entity, that the details were received through a trusted channel and not just an email, and that a small test payment reaches the right party. Changes to existing details are treated with the same skepticism as new ones.
What makes that routine work is the combination, not any single check: a record that can be consulted, a confirmation through a second channel (a call to a known number, not the number in the email), and a test at the level of the transaction. A fourth element is quieter and matters just as much: the person who verifies is not the person who releases the payment. Onchain names call for the same combination. The sources are different and the logic is identical.
The table maps one routine onto the other. The sections that follow take the rows in turn.
| Check | Bank details | Onchain name |
| --- | --- | --- |
| Record consulted | Bank and account identifiers, validated for format and routing | Public registry record, read on a block explorer |
| What it confirms | The account exists and the routing is valid | The name exists and points to the stated address |
| What it does not confirm | The legal owner of the account | The organization behind the wallet |
| Second channel | Call to a known contact to confirm the account details | Call to a known contact to confirm the TLD wallet, the name and the destination address |
| Test transaction | Small payment, receipt confirmed | Small payment, receipt confirmed |
| Change procedure | A change is treated as a new beneficiary | A change of address record is treated as a new beneficiary |
| Ongoing control | Watch for change requests | Re-read the address record before paying |
## What a name adds and what it does not prove
An onchain name such as `pay.yourbrand` points to a wallet address recorded in the registry. A payment sent to that name lands at whichever address the name points to at that moment. That is the practical improvement over sharing a raw address: the payer handles a short readable label, and the risk of a transcription error falls sharply.
What the name does not do is prove identity. The registry records which wallet holds the name and which address it points to. It does not record the legal name of a company, a company registration number or a tax identifier. A name proves control of a wallet record. It does not prove who the organization behind that wallet is, and a name that looks like a brand is not evidence that the brand holds it.
A bank account comes with an identity check performed by the bank when the account was opened, whatever its limits. A name comes with nothing of the kind: registering one does not involve the identity checks a bank runs on a new customer. The public record is reliable for what it shows, which wallet controls the name, and silent on everything else. That silence is not a defect to work around. It is the boundary of the record, and your routine has to be built on the right side of it.
A name also has to resolve in the software you pay from, which means the software must translate the name into the address behind it. Onchain names live outside the DNS that ordinary browsers and most business software rely on, so support depends on the wallet or the payment tool, and that support is partial and changes over time. The page on [paying to a name](/onchain-tld-payments) describes what happens at the point of payment, and the page on [names that resolve in wallets](/onchain-tld-wallets) covers where resolution works.
## Who controls a name: the holder of the TLD
On Freename, the registry this article uses as its reference, a TLD exists as a token recorded onchain and kept in a wallet. Names under a TLD can be issued by its holder and by nobody else. A name such as `pay.yourbrand` can therefore only exist because whoever held `.yourbrand` at the time created it.
This means the first thing to establish is who holds the TLD, not who holds the name. The holder of the TLD is the starting point of the chain for every name issued under it. If the organization you are paying says it holds `.yourbrand`, the registry record will show which wallet holds that token, and the organization can tell you whether that wallet is its own.
### When the counterparty holds the TLD
This is the simplest case. The TLD matches the counterparty's own name, the counterparty states which wallet holds it, and the name you are asked to pay was issued under it. The chain has two links, the TLD and the name, and both lead back to wallets the counterparty says it controls. Your job is to confirm those statements through a channel you trust.
### When the counterparty does not hold the TLD
A name can also sit under a TLD that someone else holds, for example a sector word such as `.yoursector` under which many organizations have a name. Here the chain is longer. The holder of `.yoursector` issued `name.yoursector`, and your counterparty says the name is theirs. The record tells you the name exists and where it points. It tells you nothing about why the holder of the TLD issued that name to that party, or on what terms.
Two consequences follow. First, the name's resemblance to the counterparty's trading name carries even less weight than usual, because anyone who obtained a name under that TLD could present it as a payment address. Second, a third party now stands in the chain. What that third party can and cannot do to a name after issuing it depends on the registry's rules and on the terms between the two of them. Do not assume either way. Ask the counterparty, and note the answer in the file.
A verification routine that checks the name but not the TLD above it is incomplete in both cases. Organizations that hold their own TLD and want to receive payments under it face the mirror image of this question, which is part of [putting a TLD to work after a transfer](/post-transfer-activation).
## Checking the public record
The registry record is public. Anyone can read it on a block explorer, a website that displays what is recorded on a blockchain. The checks below need no vendor and no special access. They need someone on your team who has been shown how to read the record, and a habit of keeping what was read.
There are three things to check, in order.
**The TLD.** Ask the counterparty to state in writing which wallet holds the TLD. Look up the TLD in the public record and compare. If the wallet in the record is not the wallet they gave you, stop there and ask why before doing anything else.
**The name.** Confirm that the name you were given exists under that TLD, character for character. A name under a similar-looking TLD, or with one letter changed, is a different name. Compare it against the contract or the invoice, not against the message that brought it.
**The address record.** Confirm that the name points to the address the counterparty has given you for payment. This is the address your payment will actually reach. Note what the record showed and when you read it.
Each check answers a narrow question, and it helps to say out loud what the three together establish. They establish that a particular wallet holds the TLD, that the name exists under it, and that the name points to a particular address. They do not establish that any of those wallets belongs to the organization on your invoice. A wallet address is not a company registration. The distance between "this wallet holds this name" and "this wallet is controlled by my counterparty" is the distance a second channel has to cover.
It is tempting to read a consistent record as reassurance. Consistency is necessary, and it is cheap: a party with no connection to your supplier can hold a TLD, issue a name under it and point the name at its own address, and the record will be perfectly consistent. The record rules out mistakes and mismatches. It does not rule out a well-prepared impostor. That is why the next step exists.
For what works with onchain names and what does not yet, with sources, the page on [what is live](/whats-live) is the reference.
## Confirmation through a second channel
The second-channel confirmation is the most important step in the routine and the one most often skipped under time pressure. It is also the step that cannot be automated.
The principle is the one you already apply: you confirm payment details through a channel that is independent of the channel through which the details arrived. If the details came by email, you confirm by telephone on a number you already hold, not the number at the foot of the email. If the details came in a contract document, you confirm with a contact you established before the document reached you.
For a name, the call should confirm three points. First, that the counterparty recognizes the wallet you read from the record as the one holding the TLD, or, where the TLD is held by someone else, that they can say who issued the name to them. Second, that the specific name you will be paying to is theirs. Third, that the destination address set on that name is one they control and intend to receive payment at.
### Who should be on the other end
The contact matters as much as the channel. The person who confirms should be someone with responsibility for the counterparty's payments or treasury, not whoever answers the main line. In many organizations the team that manages wallets is not the team that issues invoices, so expect the first call to be passed along. That is acceptable, provided you reached the organization through a number you held independently and the person who finally confirms is identified by name and role.
Read the details to them, or have them read the details to you. Do not send the details and ask "is this right?" in a channel you have not verified. An address is long, so agree on a practical method, such as reading the first and last characters and then comparing the full string in writing afterward.
Write up the confirmation immediately after the call, with the date, the name of the person you spoke to, their role and the three points they confirmed. That note becomes part of your payment file.
Some payments reach a name through a payment router. One example is [shaka](https://shaka.deal), where a payment link can pay out to a name in place of a raw address and the parties agree and sign the split onchain before any funds move. It routes the funds without holding them. None of this replaces the call: the router sends funds where the name points, and whether the name belongs to your counterparty is still your question to answer.
## The first payment and what a test proves
The verification steps establish what the record says and what the counterparty says. The first payment tests whether the two meet in practice.
The test serves two purposes. It shows that the name resolves correctly in your own payment environment and that the funds reach the address you verified. And it gives the counterparty the occasion to tell you, through the channel you trust, that the funds appeared where they expected them.
Be clear about the limits of the second purpose. A transaction is visible to anyone who looks at the public record, so a message that merely quotes the transaction reference shows only that the sender can read a block explorer. The value of the confirmation comes from who gives it and how: your known contact, on the known channel, confirming that their own team sees the amount in their own wallet. Ask for that confirmation in writing afterward and keep it with the call note.
If your payment tool does not resolve the name at all, you have a different situation. You can pay to the address the name points to, as read from the public record, and use the name as the cross-check that the address is the right one. Record that this is what you did. What you should not do is copy an address out of an email because the name failed to resolve.
Large amounts are the usual argument for skipping the test, on the grounds that the checks are done and the deadline is close. Large amounts are the reason to run it. The delay is the time one transaction and one confirmation take.
## The verification routine as a procedure
The routine below puts the checks in the order in which they should be run. Adapt the wording to your own payment policy, and keep the order.
Verification routine for a first payment to an onchain name
Receive the details in writingAsk the counterparty to state in writing the name they wish to be paid to (for example, pay.yourbrand), the wallet that holds the TLD above it, and the destination address the name points to. All three must be stated explicitly.
Check the TLD in the public recordLook up the TLD on a block explorer and compare the wallet that holds it with the wallet the counterparty named. Keep a capture of the record with the time of the lookup.
Check the name and its addressConfirm that the name exists under that TLD, character for character, and that its address record matches what the counterparty stated. Keep a capture of this record too.
Confirm through a second channelCall a contact at the counterparty on a number you hold independently of this transaction. Confirm the TLD wallet, the name and the destination address. Note the date, the contact's name and role, and what was confirmed.
Send a test paymentTransfer a nominal amount to the name. Have your known contact confirm that it arrived in a wallet they control, then obtain that confirmation in writing.
Complete the payment fileFile the written request, both captures, the call note and the test confirmation together, with the name of the person who ran the checks.
Release under dual controlA second person reviews the file and releases the full payment. The person who verified does not release.
Set the control for repeat paymentsRecord the verified address and define when it is read again before a later payment. Any change to the address record starts the routine again.
The order is deliberate. The written request comes first so that the record is checked against a statement, not the other way round. The record comes before the call so that the call has something precise to confirm. The test comes last because it costs money and should not be spent on a name that failed an earlier step.
## Repeat payments and changes behind a name
A name that has been verified once is not verified forever. The address behind a name can be changed by whoever controls its records. If your payment recurs, as a monthly fee, a royalty or a retainer does, you need a procedure for detecting changes and responding to them.
This is where a name behaves differently from a bank account, and the difference cuts both ways. With bank details, a change reaches you as a request: someone tells you the details are new, and your procedure is triggered by the message. With a name, the label you pay to stays the same while the destination behind it moves. Nobody has to tell you. That is convenient for the counterparty and it removes the "please update our details" message that so many frauds rely on. It also means that a change produces no trigger at all unless you look.
The minimum control is therefore a check before payment: read the name's address record in the public record and compare it with the address you verified. If it is unchanged, pay. If it has changed, treat the name as a new beneficiary and run the routine again, including the second-channel confirmation.
Some organizations set a value threshold, with small amounts paid without the check and larger ones requiring it. That can be a reasonable way to calibrate effort to risk, provided the threshold is set conservatively and reviewed. Running repeat payments to a name with no mechanism at all for detecting a change of address record is not a calibrated risk. It is an absent control.
Moving funds to a new wallet is a legitimate security practice, and a counterparty that changes its destination address is not necessarily doing anything wrong. A well-run counterparty will tell you in advance, through your known contact, that the address behind the name is about to change. Encourage that habit in the contract or the onboarding exchange. The reverse case deserves suspicion: a message asking you to pay a different name, or a raw address "while the name is being updated", is the onchain form of the changed bank details request and gets the same treatment.
Changes can also happen one level up. If the TLD above the name moves to a different wallet, the starting point of your chain has changed even though the name and its address look the same. Reading the TLD record at a sensible interval, and again before any unusually large payment, closes that gap.
## Recording what was verified
A payment file for an onchain name holds four kinds of record: what you checked, when you checked it, how you confirmed it and who confirmed it.
"What you checked" is the public record as you read it: the wallet holding the TLD, the name, and the address the name pointed to. A capture is sufficient if it shows the time of the lookup. Because the history of the record stays public, a later reader can go back to the chain and see what a name pointed to at a given moment. Your capture shows something the chain does not: that you looked, and when.
"When you checked it" matters because records change. A verification done three months before a payment tells you what was true then. Only a reading taken just before the payment tells you what is true as the funds leave.
"How you confirmed it" documents the second-channel confirmation. The note should be written at the time, not reconstructed afterward, and it should say how you came to hold the number you called.
"Who confirmed it" is the full name and role of the person at the counterparty who gave the confirmation, and the name of the person on your side who received it. If a dispute arises, you need to show that a responsible individual confirmed the details, not that a message went to a general inbox.
Keep the file with the beneficiary record, not in a personal mailbox. A payment that goes astray because the record behind a name was changed without your knowledge is a loss event, and the question that follows is whether the paying organization took reasonable steps. A complete file is how that question gets answered. How long to keep it, and what standard of care applies to your organization, vary by country and by sector, and your own counsel decides.
## Writing the routine into your payment policy
The next step is a document, not a tool. Take your existing procedure for adding a beneficiary and add a section for payments addressed to names, built from the eight steps above. Three decisions need an owner before the first such payment arrives.
Decide who on the team reads the public record, and have them practice on a name before it matters. Decide what counts as an independent channel for a counterparty you have only ever dealt with by email, since for a new supplier this is often the hardest part. And decide the rule for repeat payments: every payment, or every payment above a stated amount, with the amount written down.
Then test the procedure once from end to end with a counterparty that is willing, and correct what turns out to be unclear. A routine that has been run once is worth more than one that has only been approved.
If your own organization intends to be paid under its own TLD, your counterparties will run this routine on you, and it is worth being ready with the answers. Hush Partners is a private desk for onchain TLDs: organizations acquire a TLD through it, and the site's free [Launch Roadmap](/activation-roadmap) tool builds a plan for putting a newly acquired TLD to work. The desk is reached through the [contact form](/contact).
## Questions people ask
### Does a name give the same protection as a payee name check at a bank?
No. In some bank payment schemes, a service compares the name the payer typed with the name on the receiving account and returns a match or a mismatch. Nothing in the public record of a name does that. The record tells you which wallet controls a name. It does not match that wallet to a registered legal entity, and the second-channel confirmation is what covers the difference.
### Can someone other than the counterparty change where a name points?
It depends on the registry's rules and on who controls the name's records, so do not assume. What you can rely on is narrower: on Freename, issuing names under a TLD is reserved to the holder of that TLD. Ask the counterparty who is able to change the address record, note the answer, and let the check before each payment catch whatever the answer misses.
### Should the routine differ between a brand TLD and a sector TLD?
The steps are the same and the weight of each step shifts. Under a TLD that matches the counterparty's own name, the check on the TLD wallet does most of the work. Under a sector word shared by many parties, the TLD is held by someone else and the call carries more of the burden. For the difference between this kind of TLD and one delegated by ICANN to a brand, see the [comparison of a dotBrand and an onchain TLD](/dotbrand-vs-onchain-tld).
### What if the counterparty cannot say which wallet holds its TLD?
Treat it as a reason to pause, not as proof of bad faith. The person you reached may simply not be the person who knows. Ask to be put in touch with whoever manages the wallet, through the same known channel. If nobody at the organization can answer, either it does not control the TLD or its control over the asset is too loose to rely on, and the payment waits until that is resolved.
### Is a name ever enough on its own?
No. A name is a better label than an address and a useful cross-check against one. It is evidence about a wallet record, and your payment is owed to an organization. The record, the second channel and the test payment are what connect the two.