Unicode, IDNA, and confusable names
Why two names that look identical can be different strings, what normalisation does, and the warnings a product must show.
Protocol behavior Verified 2026-08-31
Describes the Atomicals protocol itself at the pinned reference revision. It does not promise that any product exposes it.
- Page ID
-
protocol/realms/unicode-and-idna - Normative authority
- Atomicals reference implementation
- Networks
- mainnet
- Documentation version
- 2026.08
- Audience
- everyone, developer, integrator
- Owner
- bitcoin-universe-docs
- Sources
-
- Atomicals ElectrumX
at
v1.5.2.0 - Universe Atomicals NFT, Realm, and Subrealm index
at
1d9109c68d95private repository
- Atomicals ElectrumX
at
- Known limitations
-
- Confusable detection reduces risk. It cannot eliminate it, because what looks alike depends on the font and the reader.
Ce contenu n’est pas encore disponible dans votre langue.
Names can contain characters beyond ASCII. That is useful and it is dangerous, because two different strings can render identically.
Three different strings
Section titled “Three different strings”A reader sees one word. A comparison sees three:
| Appearance | What differs |
|---|---|
| A Latin lowercase a | The ordinary code point |
| A Cyrillic lowercase a | A different code point that renders the same in most fonts |
| A Latin a with a combining mark | Two code points that compose to one glyph |
Normalisation
Section titled “Normalisation”Normalisation maps different byte sequences that mean the same thing to one form, so comparison works. Two rules follow:
- Normalise before comparing. Two names are the same only after both are normalised the same way.
- Keep the exact original bytes. The authoritative name is what was minted. The normalised form is for comparison, not for display or for identity.
Never store only the normalised form, and never display it as if it were the name.
Authoritative against display
Section titled “Authoritative against display”| Form | Use |
|---|---|
| Exact minted bytes | Identity, storage, and what a validator saw |
| Normalised form | Comparison, deduplication, confusable detection |
| Display form | What a reader sees, escaped and marked when risky |
What a product must do
Section titled “What a product must do”- Reject names that fail validation for the target rule set, with a clear reason.
- Normalise before comparing, never before storing.
- Detect mixed scripts within one name and warn.
- Detect confusability against names the user already uses and warn prominently.
- Escape names everywhere they are displayed, including in link text and error messages.
- Neutralise bidirectional control characters so a name cannot reorder surrounding text.
- Show the Atomical ID next to any name the user is about to act on.
Error reporting
Section titled “Error reporting”A rejected name deserves a specific reason: which character, which rule. A generic failure teaches the user nothing and pushes them to guess.
The Universe read model surfaces Unicode and IDNA errors explicitly rather than returning a generic validation failure. See NFT and Realm API.