Lookalike characters in onchain names: the homoglyph problem

The string pay.yourbrand that appears in a payment instruction may not be the string pay.yourbrand your organization issued. The two can be built from different Unicode characters, resolve to different wallets and be held by entirely different parties, and still look identical in every font a recipient is likely to use. This is the homoglyph problem, and it is much older than onchain names.

What follows explains how the problem works, how the DNS world came to manage it, why onchain names inherit it in a sharper form, and where the risk concentrates. By the end, a security lead or brand protection analyst should be able to brief colleagues on what the risk is, point to the mitigations worth deploying, and say plainly what no mitigation can guarantee.

What a homoglyph is, and why it matters in a naming system

A homoglyph is a character that looks like another character but has a different code point, which is the number that identifies a character in the Unicode standard. The Latin, Greek and Cyrillic alphabets each contain a letter that renders as the familiar round shape of “o”, and each of those letters has its own code point. Because computers process code points, not visual shapes, two strings built from different code points are different strings even when they are indistinguishable on a screen.

Unicode is very large, because it aims to cover every writing system in use, and many of its characters resemble Latin letters closely or exactly. Within Latin itself, certain characters look similar depending on the font: the lowercase letter l is easily confused with the digit 1 and with the uppercase letter I, and the uppercase letter O resembles the digit 0. Lookalikes across scripts go further, because in common fonts the two shapes are drawn the same way.

A neutral illustration helps when you brief colleagues. Take the placeholder name pay.yourbrand. Picture a second name in which a single letter has been replaced by its twin from another alphabet. Printed side by side in this article, the two would look like the same name written twice, which is why no such string is reproduced here. A registry, a wallet and a resolver would treat them as two unrelated names, each with its own holder and its own records.

In a naming system, this matters because the name is the identifier. If a visually identical string can point to a different wallet or a different website, the name on the screen no longer identifies anything reliably by sight alone. Nothing is broken in the cryptography. The weakness sits in human reading. The underlying record may be perfectly accurate and the funds may still go to a destination the sender did not intend.

How the DNS world came to handle the problem

Domain names were first limited to unaccented Latin letters, digits and the hyphen. When internationalized domain names arrived, so that people could register names in their own scripts, researchers pointed out early that characters from different scripts could be combined to imitate a known name. Public demonstrations followed, and the DNS community treated the matter as a structural question to manage over time.

The response built up in layers. Early specifications for internationalized names were permissive about mixing scripts in one label, a label being one dot-separated part of a name. Later versions tightened the rules, and many registry operators now refuse names that combine unrelated scripts in the same label. Some registry policies go further and bundle a name with its lookalike variants, so that only the registrant of the base name can obtain them.

Browsers developed their own defenses in parallel. An internationalized name is stored in the DNS in an encoded form made of plain Latin characters, known as Punycode. A browser decides, label by label, whether to show the readable Unicode form or the encoded form. The usual approach is to show the readable form when the label uses a single script, or a combination that is normal in a real language, and to fall back to the encoded form when the mix of scripts looks unusual. Some browsers also compare a name with well-known names and show a warning page when the two are close.

A third layer is shared reference data. The Unicode Consortium, the body that maintains the standard, publishes a table of characters that can be mistaken for one another, together with recommendations on how software should restrict and compare identifiers. Registries, browsers and security tools draw on it. ICANN, for its part, reviews applied-for top-level strings for visual similarity with existing ones, which matters for internationalized TLDs in particular.

Registration rules at the registry, display rules in the browser and shared confusables data have reduced the exposure in the DNS without eliminating it. Lookalikes within a single script, and pairs that the reference data does not cover, still get through. The DNS experience is the relevant baseline for understanding why onchain names are exposed, and where the exposure differs.

Why onchain names carry particular exposure

Onchain naming systems operate outside the ICANN DNS root. Where a lookalike can arise follows from how Freename records a TLD: as a token onchain, held in a wallet, with the issuing of names under that TLD reserved to its holder alone. That structure decides where a lookalike can and cannot appear, and it is worth separating three cases.

A lookalike under your own TLD

If your organization holds .yourbrand, nobody else can issue pay.yourbrand or anything that resembles it under that TLD. The character policy inside the TLD is yours: you decide which names exist. This is a real strength compared with a shared TLD, where any member of the public can ask for a neighboring name.

A lookalike of the TLD itself

The exposure moves one level up. A different TLD whose string looks like .yourbrand is a different token, and whoever holds it can issue names under it. A name under that TLD could then look the same as one of yours from the first character to the last. Which characters a registry accepts when a TLD is created, and whether it compares a new string with existing ones, is a matter of that registry’s policy. It is a fair question to put to any registry you rely on, and the answer is not the same everywhere.

A similar name under an unrelated TLD

A name can also borrow your brand as the name under a sector TLD, in the pattern of name.yoursector. This is not a homoglyph question in the strict sense, since a careful reader can see the difference. It is monitored with the same tools and often arrives in the same instruction.

What differs from the DNS

Three differences from the DNS explain why the subject deserves attention.

First, there is no single policy layer. The DNS has one coordinating body, contracts with registries and registrars, and guidelines for internationalized names that those contracts refer to. Onchain naming is made of several independent registries, each with its own rules, and those rules are expressed partly in software. A check applied in one registration interface does not necessarily apply to every route by which a name can come into existence, so the absence of a variant in one interface is not evidence that it cannot exist.

Second, the standard administrative remedy is missing. The UDRP, the dispute policy that binds registrants in ICANN TLDs through their registration agreements, does not extend to names outside the ICANN system. A trademark owner still has rights, but no quick administrative path to enforce them.

Third, display is fragmented. Onchain names are read in wallets, payment applications, browser extensions and websites, each of which renders names with its own logic. Support for resolving onchain names is partial and changes over time, and the same holds for how carefully a given product treats unusual characters. A name that one interface would flag may pass without comment on another product’s confirmation screen.

Where the risk is highest: payments and logins

The exposure is not uniform across all uses of onchain names. It concentrates in two moments: when a payment is sent to a name, and when a name is used to establish who someone is.

Payments to a name

In a payment, the name stands in for a wallet address. A person who copies pay.yourbrand from a document, a chat message or an invoice and pastes it into a wallet relies entirely on the visual integrity of the string. The habit is familiar from raw addresses, where most people compare only the first and last few characters. A readable name feels safer than a long hexadecimal address, and largely is, but that feeling of safety is what a lookalike depends on: the reader stops checking because the name looks right.

For payments to a name, the consequence of a lookalike is that funds go to a wallet the sender did not intend. A confirmed transfer onchain is final. There is no chargeback and no central party that can reverse it, which is the main reason the same old problem carries more weight in this setting.

Names used as identity

The second context is distinct. When a name works as an identity, a counterparty, an application or an automated system resolves it to decide whom it is dealing with. A lookalike then presents itself as the holder of the original. Permissions, approvals and reputation that people attach to the genuine name can be claimed at the display layer, even though the underlying records are unambiguous to a machine. Teams that rely on names that resolve in wallets need to keep in mind that the string a person reads and the string a system resolves are two things, and that only the second one counts.

The identity case is harder to notice than the payment case, because nothing leaves an account at the moment of the mistake. The cost appears later, when access or trust has been granted to the wrong party.

What software can do: display rules and warnings

Software mitigations fall into three categories: normalization, detection and warning.

Normalization means transforming a name into one canonical form before accepting or displaying it. It can fold uppercase into lowercase, remove invisible characters and refuse certain confusable characters outright. Its value depends on how consistently it is applied. Normalization governs the names created through the path where it runs. It says nothing about a name created elsewhere and then sent to your staff in a payment instruction.

Detection means comparing a name with reference data on confusable characters and flagging a match. Browsers do this for domain names. Wallet software and payment interfaces can apply the same logic to onchain names, and the depth of that checking varies from one product to another. A stronger form of detection compares the name with names the user already knows, such as saved contacts or earlier counterparties, and reports a near match.

Warning means showing the ambiguity to the user. A notice about unusual characters says that the name contains characters outside the expected set. It does not say the name is illegitimate, because genuine names in non-Latin scripts trigger the same notice. This is the tension in every display mitigation: a check strict enough to catch every lookalike also flags honest names in Cyrillic, Greek, Arabic or East Asian scripts, and falling back to an encoded form protects readers of Latin script at the expense of the many people who read other scripts natively. No display policy removes that tradeoff. A product can only choose where to sit on it.

For a security lead, the practical consequence is a procurement question. When you select a wallet or a payment tool for corporate use, ask how it displays names with mixed scripts, whether it warns on near matches with saved names, and whether it always shows the resolved address next to the name before confirmation.

What an organization can do: reserve, monitor and educate

Software helps, but only in part. An organization that holds a TLD, or publishes names under one, has three practical levers of its own.

Reserve

Inside your own TLD, reservation is a policy decision: decide which characters you will ever issue names in, and keep to it. Many organizations settle on unaccented lowercase Latin letters and digits, which removes the question inside the TLD. Outside it, reservation means securing the few variants that matter most before a third party does. The set of possible lookalikes is far larger than any organization will reserve, so the aim is narrow: cover the variants of the names you use for payments and logins, and accept that the rest is handled by monitoring. The free Namespace Exposure Score gives a first reading of how exposed a brand is onchain before you decide how much coverage is proportionate.

Organizations with trademark rights have a structural option as well: hold the TLD that matches the trademark, issue every official name under it, and publish that rule. Any instruction that points to a different TLD can then be treated as unverified by default.

Monitor

Monitoring means watching for new names that resemble your issued names or your TLD. Registry records are public and anyone can check them on a block explorer, so the raw material is available. Turning it into a useful signal takes a comparison against confusables data and a person who decides what a match means. An organization can build this in house or use a service that monitors the names of a brand onchain. Early detection shortens the period in which a lookalike goes unnoticed. It does not remove the name.

Decide in advance what happens when a match is found. A workable procedure has an owner, a record of the public registry entry and where the name was seen, a short notice to the counterparties most likely to receive it, and a referral to counsel where a trademark is involved.

Educate

Education is undervalued and often the most durable of the three. Staff who send payments to onchain names, vendors who receive payment instructions from you, and counterparties who identify you by name all need to understand that a string on a screen does not validate itself. One sentence of internal policy, “confirm a name through the official channel before first use”, costs little and addresses the most common failure: acting on a name received through a channel that could have been altered.

Give that policy something to point to. Publish the complete set of your official names in one place you control, such as a page of your main website, and tell counterparties that a name absent from that page is not yours. A short, stable set of names is easier to verify than a long and changing one.

Mitigations by who applies them

Different parties hold different controls. The table maps each mitigation to the party best placed to apply it.

No row is sufficient on its own. The rows reinforce each other because they act at different moments: when a name is created, when it is shown, and when it is used. A residual risk remains after all of them are in place, and a sound control framework says so in writing.

What an individual should check before paying to a name

A person who receives a payment instruction with an onchain name they have not used before faces a verification question that no software settles for them by default. The name looks correct. The instruction is probably genuine. Looking harder at the string does not help, because a lookalike is, by definition, what the eye cannot separate. The checks that work compare things other than the visible name.

1. Type the name, do not paste itEnter the name by hand in the wallet or resolver you trust. Pasting carries over any invisible or lookalike character present in the message you received.
2. Read the resolved addressResolve the name and look at the wallet address it returns. Compare that address, not the name, with a record you already trust, such as an earlier confirmed payment or the address published on the counterparty's own website.
3. Take warnings seriouslyIf your wallet or browser reports unusual characters in a name you expected to be plain, stop and find out why before sending anything.
4. Save the verified nameOnce checked, store the name and its address in your address book and pay from that entry, so that later payments do not depend on a fresh copy of the string.
5. Check again before a large transferThe holder of a name can change the address it points to. Confirm the resolved address immediately before a high-value payment, even for a name you have used before.

Typing the name by hand only works when the genuine name is easy to type, which is one more reason for organizations to issue names in plain Latin letters. Where the genuine name is in another script, the comparison of addresses carries the whole weight of the check.

The limits of every mitigation

Each of these measures stops short somewhere, and a briefing to management should say where.

Normalization at registration removes lookalikes that would pass through that specific path. The name that causes harm is rarely one your organization or your counterparty created. It is one created elsewhere and delivered in an instruction.

Monitoring finds a lookalike after it exists, not before. There is always an interval between creation and detection, and a name can be put to use within that interval.

Reservation scales poorly. The number of plausible lookalikes for even a short name is large, and it grows with the length of the name. An organization can reserve the most likely variants and monitor for the rest. It cannot close the set.

Legal remedies exist in principle. A trademark owner whose mark is imitated by a lookalike name may have a claim, depending on the country and on how the name is used. Onchain names sit outside the UDRP, so the usual administrative path is not available. Whether a court will order the transfer of a name recorded as a token, and whether that order can be enforced against a holder whose identity is not known, depends on the law of the country concerned, and rules vary widely. This article is information, not advice, and your own counsel decides in any specific situation.

Warnings lose force with repetition. A notice that appears often teaches people to dismiss it, and by the time a real lookalike triggers the same notice, the habit of clicking through is already formed. Fewer, more precise warnings do better than many broad ones, but that choice belongs to the software maker, not to you.

Second-channel verification is the strongest control in the set and it too has a limit: it depends on people following it under time pressure, on the last working day before a deadline, for a counterparty they believe they know. It holds when it is written into the payment procedure and required as evidence. As a recommendation only, it tends to be skipped.

None of this argues against the mitigations. Each layer lowers the probability of a costly mistake. The point is to deploy them together and to treat none of them as closing the question.

Practical next steps for organizations with onchain names

Start with an inventory. Write down every onchain name your organization has published or intends to publish, and mark the ones used in payment instructions and in login or identity flows. Those rank highest. For each, record the address it resolves to and who inside the organization can change it.

Then take a baseline. Check whether names that resemble the marked ones already exist, and whether a TLD that resembles yours has been created. This is a one-time exercise that tells you whether ongoing monitoring is proportionate, and for which names.

Two internal changes need no outside help. Update the payment verification policy so that any onchain name received for the first time requires confirmation through a second channel. Then make sure that everyone who issues or publishes names knows the character policy and the rule of reserving before publishing.

Where the baseline shows that the TLD matching your brand is held by someone else, the question becomes one of acquisition, not of security controls. An organization can mandate Hush Partners to find and approach the holder, under a standard mutual NDA, with closing through onchain escrow on an aftermarket.

Questions people ask

Is a lookalike name the same as a typosquatted name?

They are related but distinct. Typosquatting relies on a name that differs from the genuine one by a swapped, added or missing character, a difference a careful reader can see. A homoglyph lookalike differs in its code points and not in its appearance, so careful reading does not reveal it. The mitigations overlap but are not identical: monitoring for typographical variants measures how many edits separate two strings, while homoglyph detection needs confusables data.

Does a lookalike need a different script to work?

No. Lookalikes inside a single script are common, and they depend heavily on the font: some typefaces draw the lowercase l, the uppercase I and the digit 1 almost identically, and others separate them clearly. This is why a name that is unambiguous in one application can be ambiguous in another, and why interfaces that show names in a typeface with well-separated characters lower the risk without any warning at all.

Does a trademark registration remove an onchain lookalike?

Not by itself. A registration establishes a right and gives a basis for action, but nothing in an onchain registry acts on it automatically. Its practical value in this setting is evidence: it documents who owns the mark, in which countries and for which goods and services, which is what any court or negotiation will ask first. How far that carries depends on the country and the facts, and your counsel decides.

What is the Unicode confusables data, and is it complete?

It is a public table, maintained by the Unicode Consortium, that maps characters known to be visually confusable with one another. Browsers, security tools and registration systems use it as a reference. It is not exhaustive: new fonts and rendering environments create resemblances the table does not cover, and it is revised from time to time. Treat it as a baseline that tools extend with their own rules, and see the glossary for the naming terms used in this article.

Should an organization with onchain names also hold the DNS equivalent?

Holding both, where the DNS equivalent is available, removes one class of confusion between the two systems and simplifies communication with counterparties who do not distinguish them. The two differ in governance, enforcement and resolution, and the comparison of a dotBrand and an onchain TLD sets those differences out. Whether holding both is proportionate depends on how the names are used.