# Paying to a name instead of an address
> How a payment addressed to a readable name works, what it changes for the payer and the payee, and the checks that still matter.
Source: https://hush.partners/paying-to-a-name
Category: Onchain today
Published by Hush Partners.
---
Every onchain payment begins with the same friction: one party hands the other a string of forty hexadecimal characters, and both of them have to trust that no character was altered between sending and receiving. The address format was never designed to be read by a human. It was designed to be verified by a machine, and the machine does not care that the human in the middle is copying, pasting, reading aloud, or transcribing from a screenshot.
A payment name is a different layer. It sits above the raw address the way a domain name sits above an IP address: the name is stable and human-readable, and the underlying destination can be updated without changing what the payer types. That separation has real consequences for both sides of the transaction.
This article walks through how the resolution works, where it is supported, what each side gains and what each side still needs to check, and how an organization should govern the name it publishes for payment.
## The problem a raw address creates
A standard Ethereum-style address is a string of forty hexadecimal characters prefixed with `0x`. Many wallets shorten the display to the first few and the last few characters, with an ellipsis between them. A payer who trusts that display is trusting a partial string, not a verified destination.
The weakness is the use of raw addresses as payment identifiers. When a person must copy, paste, and verify a long string of characters for every transaction, human error becomes structurally likely.
Two well-documented fraud patterns build on that weakness. They differ in mechanism and are identical in outcome. The first, known as address poisoning, relies on the shortened display: a look-alike address whose first and last characters match a familiar one appears in the payer's transaction history, and the payer later copies it from that history in place of the genuine one. The second involves a compromised device: malicious software replaces an address held in the clipboard with a different one between the copy and the paste. Knowing both patterns is what allows a treasury team to recognize them and to design its checks around them.
Both share a structural precondition: the payer is working with a raw address and has nothing readable to compare it against. A payment name does not eliminate every risk, but it removes the raw address from the payer's primary workflow, which is where most of these errors begin.
## How a name resolves to an address
A name service lets a human-readable name stand in for the destination address of a payment. A wallet that supports the service resolves the name to the underlying address, much as a browser resolves a domain name to an IP address.
The mechanism requires three components: a registry that maps names to records, a resolver that answers lookup queries against that registry, and a wallet that knows how to call the resolver before constructing a transaction.
Freename records each TLD onchain as a token that sits in a wallet, and the right to issue names under a TLD belongs to its holder alone. When a supporting wallet receives input such as `pay.yourbrand`, it asks the resolver for the records attached to that name, takes the address held there, and uses it as the destination of the transaction. The payer types the name. The resolution happens in the background. The raw address only appears at the confirmation screen.
Name systems are generally designed so that a name can carry more than one record, which is what allows a single published name to point to different destinations on different networks. Which networks a given registry and a given wallet support is a matter for their own documentation, and it is the first thing to confirm before you rely on one name for more than one network. From the payer's side, the name stays constant either way.
## Where a name resolves and where it does not
Resolution support is real but partial. Onchain names resolve outside the ICANN DNS root, so software that only knows the DNS does not recognize them without added support. Check the state of that support before you publish a payment name, because it changes as wallets update their integrations.
For Freename names, three environments are supported: Bitcoin.com Wallet, MetaMask by way of Freename's resolver, and desktop browsers with the Freename Web3 extension installed. Outside these, assume that a wallet or browser will not resolve the name. Nobody can promise universal resolution, and you should not promise it to your counterparties.
The practical implication for an organization publishing a payment name is that you cannot assume your counterparty's wallet handles resolution. For [payments addressed to a name](/onchain-tld-payments), this means telling incoming payers which wallets are known to work, and making the underlying address available as a fallback for those whose environment does not support resolution. The page on [what is live](/whats-live) sets out the capabilities that work, with their sources.
The fallback deserves a moment of thought. An address published next to the name is useful to a payer who cannot resolve the name, and it also gives every payer a reference to compare the resolved address against. The cost is that you now maintain two published items in step: if the address behind the name changes, the published fallback must change at the same moment, through the same approval.
## What changes for the payer
The most immediate change is what the payer types. Instead of transcribing or pasting a forty-character address, the payer enters a name that can be read aloud, copied from a website, or remembered. The name is also checkable: a payer can look up the record on a block explorer before the first payment, see which address it resolves to, and keep a note of that check.
The name also changes where the copy and paste risk sits. A payer who types a short name has no long string in the clipboard to be replaced, and no reason to copy a destination from the transaction history. What remains is the confirmation screen, where the wallet shows the resolved address before the payer approves the transaction. That is the moment to compare it with a reference the payer already trusts.
A name introduces a risk of its own, and the payer should know it. A name that differs by one character is a different name, and a similar word under a different TLD is a different name too. Reading the whole name, TLD included, is the equivalent of reading the whole address. It is far easier to do, which is the point, but it still has to be done.
What does not change is the finality of the transaction. An onchain transfer sent to the wrong address cannot be recalled by the sender, and no intermediary stands ready to reverse it. A name makes the correct address easier to reach; it does not create a mechanism for recovery if something still goes wrong. The payer should still review the resolved address on the confirmation screen before signing, particularly on a first payment to a new name.
The payer also acquires a dependency on name resolution. If the resolver cannot be reached, the name does not resolve, and the payer cannot complete the payment by name until it can. That dependency does not exist when paying to a raw address, and it is one more reason to keep a verified copy of the address on file.
| Property | Paying to a raw address | Paying to a name |
|---|---|---|
| What the payer types | Forty-character hex string | Readable name |
| Destination can change without new instructions | No | Yes |
| What the payer must read in full | The whole address | The whole name, then the resolved address |
| Depends on resolution support | No | Yes |
| Who controls the destination | The key holder | Name holder and TLD holder |
| What can be checked onchain | Address only | Name record, holding wallet, resolved address |
## What changes for the payee
For the payee, the separation between the published name and the underlying address is the main structural advantage. The name `pay.yourbrand` can remain unchanged in invoices, contracts, published payment pages, and counterparty address books. The wallet address behind it can be changed by updating the name's record, with no need to reissue any document.
This matters in several practical scenarios. If a wallet is compromised or decommissioned, the record is updated and payments made by name from then on go to the new address. If an organization changes its custody arrangement, moving for instance from a software wallet to a hardware wallet or a multisignature setup, the name absorbs the transition. A payer who stored the old address and pays to it directly is not covered by the update, which is why a change of address is still announced to regular counterparties.
A multisignature wallet is one where more than one private key must approve a transaction before it executes. Many treasury teams use this structure for accounts that hold significant value. The payment name can resolve to a multisignature address with no change to the payer's experience. The payer sends to the name; the multisignature policy governs what happens to the funds after receipt. The page on [names that resolve in wallets](/onchain-tld-wallets) covers that side of the subject.
The flexibility has a bookkeeping consequence. Because the destination behind the name can change, your records should show which address was live during which period, who approved each change, and when. Without that log, reconciling an incoming payment against the right wallet becomes guesswork, and an auditor who asks why funds arrived at a particular address has no document to read.
The payee also gains something subtler: a public reference for its payment destination. A counterparty who wants to verify a payment name can open a block explorer and read its registry record, which is public. That record shows the wallet that holds the name and the address the name resolves to. It does not show a legal entity, and that gap is what brings the question of name control into focus.
## Who controls the name, and why the TLD holder matters
When a payment name is published, two levels of control sit above the underlying wallet address: the name itself, and the TLD that the name sits under.
The name (`pay.yourbrand`) is controlled by whoever holds that name's record in the registry. The TLD (`.yourbrand`) is controlled by the wallet that holds its token, and issuing names under it is reserved to that holder. An organization that uses a name without holding the TLD therefore depends, for every further name it may need under that TLD, on a party it does not control.
This has a direct bearing on payment reliability. If the TLD is held by a party with no contractual relationship to the organization, that party can issue other names under the same TLD, including names that sit close to the one you publish, and it can transfer the TLD to someone else on terms you never see. For an organization publishing a payment name as part of its standard invoicing or treasury operations, holding the relevant TLD is not a cosmetic concern. It is a question of control over a business-critical identifier.
The TLD holder matters for a second reason. Because only the holder can issue names, an organization holding `.yourbrand` can create further names for internal units or specific purposes under the same TLD. `invoicing.yourbrand` and `deposits.yourbrand` can each resolve to a different address, sit under the same TLD, and be updated independently.
Control inside the organization needs the same attention as control outside it. The wallet that holds the TLD and the wallet that holds the payment name are assets in their own right, and each can move funds indirectly by changing where a name points. A sound arrangement separates the roles: the people who can issue names under the TLD are not the only people who can change a payment record, and neither group acts alone. Deciding who may update records, under what approval, and with what monitoring is part of putting a TLD to work, the stage covered by [post-transfer activation](/post-transfer-activation). Those decisions come before the name is published externally, not after.
## Payment links and agreed splits
A name also fits a kind of payment structure in which the routing of funds is settled before any money moves.
[shaka](https://shaka.deal) is an onchain payment router. A payment link created there can pay out to a name rather than to a raw address, and the parties agree the split between them and sign it onchain before funds move. Its role is to route the funds: it does not hold them.
This matters where a payment is not meant for a single recipient. Consider, as an invented scenario, a mid-sized manufacturer that invoices a customer and owes a share of each invoice to a contracted supplier. Or picture an organization with a licensing arrangement in which part of each payment belongs to a third party. In the conventional pattern, one party collects the full amount and pays the others afterward, and everyone else waits on that second transfer.
A split agreed before funds move changes the order of events. The discussion about who receives which share takes place at the point of agreement, where it belongs, and not after collection. For a finance team, that moves the control point. The review that counts is the review of the split and of the names it pays out to, carried out before anyone signs.
Each payout name in such a split deserves the same scrutiny as any other payment name. A split that pays out to three names rests on three records, each with its own holder and its own TLD above it. The checks described further down apply to each one, and they apply before the split is signed, since that is the last moment at which a correction is simple.
Two limits are worth stating. First, a split signed onchain records what the parties agreed about routing. It does not replace the commercial contract between them, which still decides what each share is owed for and what happens in a dispute. Second, the accounting and tax treatment of a payment that reaches several parties at once varies by country and by the nature of the arrangement. Your own counsel and your accountants decide how it is recorded.
## Controls for an organization publishing a payment name
Publishing a payment name is not a technical exercise alone. It is a change to the organization's payment infrastructure, and it requires governance proportionate to the risk.
The principle behind every control is the same. Changing the address behind a payment name redirects incoming money as surely as an outbound payment sends money out. It should therefore pass through approvals of the same weight. An organization that requires two approvers to send a large payment and lets one person on one device change where all incoming payments land has left the weaker door open.
The second principle is that changes are visible. An update to a name's record happens onchain, where it can be observed, so the organization can watch its own names and learn of a change it did not approve. Monitoring does not prevent an unauthorized change. It shortens the time during which one goes unnoticed, and for a payment destination that time is what matters.
Introducing a payment name for an organization
Confirm who holds the TLDEstablish that the organization holds the TLD under which the payment name will sit. If it does not, acquire the TLD or choose a different name structure before going further.
Set up the name recordIssue the chosen name (for example, pay.yourbrand) under the TLD and point its record to the receiving wallet. Test that it resolves to the right address in the supported wallets your counterparties are likely to use before publishing it.
Define the update policyDocument who is authorized to change the resolved address, how many approvals a change needs, and in which circumstances a change is permitted. Give this policy the same rigor as the policy for authorizing outbound payments.
Watch the recordArrange for the treasury and security teams to be alerted when the record of the name, or of any name under the TLD, changes. The registry record is public, so the watch only has to read it.
Publish in authoritative placesAdd the payment name to the organization's website, its invoice template and the contracts that designate it as the payment destination. A counterparty who finds the same name in several official places has more to rely on than one who saw it once.
Tell existing counterpartiesAnnounce the name through a channel they already trust, such as a formal notice under an existing contract or a call from their usual contact. Never introduce it through a single unverified message.
One point the procedure cannot settle for you is who owns it. In most organizations the name touches treasury, security, legal and whoever manages the brand's digital assets. Give the payment name one accountable owner, usually in treasury, and make the others reviewers. A name that belongs to four teams is, in practice, watched by none.
## How counterparties can verify a name before paying
Verification is the payer's last line of defense. A readable name is easier to communicate than a raw address, but it still needs to be confirmed before the first payment.
This is not specific to onchain payments. It is the control that already applies to a new bank account number received by email, and the reasoning is identical: the name on an invoice is only as trustworthy as the invoice itself. Three further checks complete it.
**Check the record.** The registry record of a name is public, and a block explorer shows the wallet that holds the name and the address it resolves to. Compare the resolved address with the one the payee confirmed through the separate channel. That comparison closes the gap between "this name resolves" and "this name resolves to the address I expect."
**Look at the TLD above the name.** The record of the TLD is public in the same way. It shows a holding wallet, not an organization, so it cannot tell you by itself whose TLD it is. What you can do is ask the payee whether it holds the TLD its payment name sits under, and treat a vague answer as a reason to look further before the first payment.
**Store the resolved address after the first payment.** Once the first payment has been made and acknowledged, record the resolved address next to the name in your payment records. On later payments, compare the freshly resolved address with the stored reference. A difference is not proof of a problem, since payees do change wallets, but it is a reason to stop and ask through the trusted channel before paying.
For counterparties whose legal or compliance teams need to map a payment name to a legal entity, the public record and the organization's published materials are the starting point. Where they are not enough, the route is the one used for any other payment instruction: request written confirmation from the payee's authorized representative. Your own counsel decides what standard of documentation applies in your jurisdiction.
## Start with who holds the TLD
For an organization evaluating a payment name, the first task is not choosing the name. It is establishing who holds the TLD it would sit under, because every control described above operates at the level of the name and none of them reaches above it. Approval rules and monitoring can protect `pay.yourbrand`. They cannot decide what else is issued under `.yourbrand` if someone else holds it.
If you hold the TLD, the next step is the work in the procedure above: record, policy, watch, publication. The [activation roadmap](/activation-roadmap) tool on this site builds a launch roadmap for a newly acquired TLD and is a reasonable place to put the payment name in sequence with everything else the TLD will carry.
If the TLD that matches your brand is not in your hands, [brand namespace recovery](/brand-namespace-recovery) is the service through which Hush Partners acquires it for an organization. Each exchange with the desk falls under a standard mutual NDA, and one named partner stays with the file from the first note through to closing.
## Questions people ask
### Does a counterparty need a special wallet to pay to a name?
It needs a wallet or browser that supports resolution of the name. For Freename names, that means the environments named earlier in this article. A counterparty outside them obtains the underlying address and pays to it in the conventional way, which is why publishing the fallback address next to the name is good practice. The [glossary](/glossary) defines the terms a counterparty may ask about.
### Can one name receive payments on more than one network?
In principle a name can carry more than one record, so one published name can serve more than one network. Whether that works for the networks you use depends on the registry and on the sending wallet, and both should be tested before you tell counterparties to rely on it. Until you have tested it, publish the name for the network you have verified and say so.
### If the resolved address changes, does the payer receive any notice?
Not automatically. The change is public and can be seen by anyone who watches the record, but the payer hears nothing unless the payee says something. This is the reason for the payer to store the first resolved address, and for the payee to announce changes through the same authoritative channels that introduced the name. [Namespace watch](/namespace-watch) is the service for organizations that want the names of their brand monitored onchain.
### Does holding a TLD mean a name under it cannot be imitated?
It means that names under that TLD are issued by its holder and by no one else. It does not stop a similar-looking TLD from existing elsewhere, with names under it that resemble yours. Watching for look-alikes is a separate control, and it matters for any organization that publishes a payment name widely. The [namespace exposure score](/namespace-exposure-score) gives a first reading of how exposed a brand is onchain.
### What is the right internal approval process for changing the resolved address?
There is no universal standard. The approval should reflect the value of the payments the name receives, and the request should be confirmed through a channel independent of the person who makes it. A reasonable starting point is to mirror the approvals you already require for outbound payments of comparable size. Your internal controls function, with your own counsel where needed, defines the policy.