Safety
Risks — spoofing and phishing
An emoji name service has an attack surface a text one does not. Here is exactly what we block, what we warn about, the measured numbers, and what we still cannot fix.
Read this page before you buy a name and before you send funds to one.
The threat, stated precisely
In a text name service the enemy is the homoglyph: paypal.eth versus pаypal.eth with a Cyrillic а. In an emoji name service the problem is worse in one specific way and better in another.
Worse: emoji are drawings, and drawings of the same thing look alike on purpose. 😮 and 😯 are different codepoints, different names, different owners — and at 16 pixels in a wallet's send field they are the same picture. A user cannot tell them apart by looking harder.
Better: the namespace is small and enumerable. There are 1,878 registrable characters, not a million Unicode codepoints. That means the look-alike families can be measured rather than guessed at, and the residual risk can be published as a number instead of a reassurance.
Five tiers, and who enforces each
Where a rule lives matters more than the rule. Names are content-hashed, so anything that changes which names are valid becomes unfixable after the first mainnet mint. The rules are split accordingly.
| Tier | Rule | Enforced by | Changeable later? |
|---|---|---|---|
| 1 · Block | 37 confusable variants in 10 classes, plus every skin-tone modifier | The contract, in TVM | Never 🔒 |
| 2 · Canonicalise | One encoding per rendered name; only RGI emoji and RGI sequences | Signer, pinned by an on-chain policy hash | Never 🔒 |
| 3 · Detect | Skeleton collision against the live registry | Indexer / mini-app | Yes |
| 4 · Warn | Per-name risk band, at registration and at send time | Wallet / mini-app | Yes |
| 5 · Clean | Nothing looks like it | — | — |
Tiers 1 and 2 are welded shut. Tiers 3 to 5 are deliberately not, because what looks alike is a moving target — new emoji ship every year and vendors redraw the ones that exist. Welding a similarity table to an immutable namespace would guarantee it goes stale.
What is blocked outright
Only the cases where two emoji are genuinely indistinguishable — where no amount of care lets a user tell them apart. Each look-alike class names one survivor up front, and every other member is permanently unregistrable by anyone: public, admin, or a compromised signer.
Ten classes, 37 blocked characters. Examples:
| Class | Survives | Blocked |
|---|---|---|
| Hearts | ❤️ | ♥ |
| Frowning faces | 😕 | 🙁 ☹ |
| Surprised faces | 😮 | 😯 😲 😦 😧 |
| Check marks | ✔️ | 🗸 |
| Clock faces | 🕐 | 🕑 … 🕧 |
| Blue / grey hearts | 💙 🖤 | 🩵 🩶 |
| Moon phases | 🌑 🌒 🌓 🌔 🌕 | 🌖 🌗 🌘 |
The moon set is the clearest example of the rule being applied honestly: the family is three mirror pairs, and an earlier version of this policy kept both crescents — the most confusable pair in the set — while blocking four phases that are plainly distinct. It was repartitioned. The current split keeps one moon per lit-area level and blocks only the mirrored half, which removes a real collision and blocks one fewer emoji than before.
Skin-tone modifiers are rejected everywhere, so every person emoji has exactly one registrable spelling and 👍 cannot be shadowed by five near-identical variants. All invisible characters are disallowed — zero-width spaces, directional overrides, and every other markless codepoint that could hide inside a name without being seen.
The number that went to zero
The metric that actually matters is homograph multiplicity: given a registered name, how many other registrable names render identically to it?
If that number is greater than zero, the namespace itself is unsafe — no amount of interface warning fixes a name that has a perfect twin.
| Name length | Identical-rendering alternatives |
|---|---|
| 2 emoji | 1 (the name itself) |
| 3 emoji | 1 |
| 4 emoji | 1 |
| 5 emoji | 1 |
| 6 emoji | 1 |
| 7 emoji | 1 |
One means the name is alone. Every registrable name in this namespace has exactly one spelling, and no other registrable name draws the same picture.
The confusability map
Below "identical" sits "similar", and similar is not something to block — it is something to measure and disclose. The map is derived from Unicode's own character names rather than hand-written, so it does not go stale the moment a new emoji block ships.
So roughly a quarter of the namespace has a visual neighbour, and three quarters is clean. That is the honest shape of the risk. It is not zero and we are not going to present it as zero.
What you will see as a user
The check that protects money is the one at send time, not registration — the person who loses funds is the sender, and they never saw the registration flow.
| Situation | What a wallet shows |
|---|---|
| The name is visually near-identical to another registered name | Blocked — "Visually almost identical to 🔴🔵, which is also registered" |
| Elevated risk and registered less than 30 days ago | Warning — "Registered recently and 99 similar names are possible. Confirm the address" |
| Elevated risk, established name | Notice — "99 other registrable names could be mistaken for this one" |
| Clean, or on a verified list | Nothing |
Age is the strongest free signal there is. An impostor name is registered shortly before the campaign that uses it — a name in a crowded visual neighbourhood that appeared last week is the classic setup.
What we still cannot fix
Stated plainly, because a security page that only lists wins is marketing.
- Cross-vendor rendering. Apple's 🧐 and Google's 🧐 are different drawings, and no on-chain rule can model that. A render audit across the major vendor font sets is scheduled before the first premium drop.
- Stale fonts. Around 400 registrable emoji from recent Unicode blocks render as an identical empty box on devices with out-of-date fonts — the same problem as unassigned codepoints, reintroduced by assigned but unsupported ones. A minimum-Unicode-version policy for the namespace is the mitigation.
- Artwork versus name. The marketplace metadata for a name is attested by the signer but never compared on-chain to the name itself.
- Semantic impersonation. A name that is thematically brand-adjacent rather than visually similar is a dispute-policy problem, not a code problem.
Protecting yourself
- Check the address, not the picture. Resolve the name and confirm the destination address through a second channel before sending anything meaningful.
- Prefer clean characters for anything public-facing. The interface tells you which ones those are.
- Treat a new name in a dense family as unverified until you have confirmed it out-of-band.
- Buy the look-alikes you care about. If your brand name has three near neighbours, registering them is cheap insurance — and at these tiers, cheaper than almost any other defence.