For developers
Emoji names — technical overview
How the protocol is put together, what a name costs, what it resolves to today, and the honest state of the integration roadmap.
Why this can exist at all
TON's .ton registry accepts English letters, digits and hyphens. Emoji are excluded, and Telegram usernames use the same restricted set. So an emoji name service cannot be a .ton name.
TON DNS has a permissionless escape hatch. A domain owner can set the record sha256("dns_next_resolver") to any contract address, delegating resolution of every subdomain beneath it to custom logic. Own a parent domain, deploy a TEP-81 resolver under it, and 🚀🌙.<parent>.ton becomes resolvable by any compliant TON client, with nobody's permission.
That is the whole trick. It is not a workaround — it is the standard working as designed.
Architecture
| Contract | Role |
|---|---|
| Registrar | The economic and ownership core. Registration, renewals, auctions, referrals, partner splits, admin. Holds auction escrow. |
| Resolver | TEP-81 dnsresolve. Maps an emoji label to records, byte-exact and root-agnostic. Multiple resolvers can be registered. |
| NFT collection + item | TEP-62. One tradable NFT per name — the ownership object itself, not a receipt for it. |
An off-chain Ed25519 signer attests (nameHash, emojiCount, contentHash, validity), because emoji segmentation — zero-width joiners, variation selectors, regional indicator pairs — cannot practically run inside TVM. The registrar verifies that signature before it prices anything.
nameHash on-chain; skin-tone modifiers and blocked look-alikes are rejected by a byte scan in TVM; and since V7 the registrar segments the emoji clusters itself and refuses any attested tier that disagrees with the bytes. A fully compromised signer cannot mint a blocked emoji, cannot fake a pricing tier, and cannot smuggle a single-emoji name past the auction lock.The namespace
- 2 to 7 emoji are publicly registrable.
MAX_EMOJI_COUNTis an immutable code constant — there is no setter and no lock op. - Single emoji are never publicly registrable. Auction drops and promotional mints are the only doors. See Auctions.
- Skin-tone modifiers are rejected. Only the default form of an emoji is registrable, so 👍 has exactly one spelling.
- Variation selectors are normalised into the name, so a name pins its own appearance rather than leaving it to the renderer.
- ZWJ sequences and flags are one emoji. 👨👩👧 is a single unit and so is 🇯🇵 — the contract counts clusters, not codepoints.
- Invisible characters are disallowed entirely.
- A name is capped at 111 UTF-8 bytes, which is what survives a TEP-81 resolution walk inside the 127-byte domain limit.
Pricing
Two schedules. First-year prices are admin-adjustable only within hardcoded bounds; renewal prices are constants with no setter anywhere in the contract. The lower bound of every first-year band is the tier's own renewal price — a first-year price can never be set below what a renewal costs.
| Emoji | Tier | First year | Adjustable within | Renewal / yr |
|---|---|---|---|---|
| 1 | Mythic | auction only — 150 floor | — | 50 GRAM |
| 2 | Legendary | 20 GRAM | 10 – 80 | 10 GRAM |
| 3 | Epic | 15 GRAM | 7.5 – 60 | 7.5 GRAM |
| 4 | Rare | 5 GRAM | 3 – 20 | 3 GRAM |
| 5 | Uncommon | 3 GRAM | 1.5 – 12 | 1.5 GRAM |
| 6–7 | Common | 1.5 GRAM | 0.75 – 6 | 0.75 GRAM |
A registration of N years costs the first-year price plus (N − 1) renewals. Term is capped at 5 years per transaction and 10 years total from the present.
priceRegister(emojiCount, numYears) and priceRenew(emojiCount, numYears) on the registrar. First-year prices move within their bounds; your integration should not need a redeploy when they do. priceRegister returns 0 for a single-emoji name, because a single has no list price at all.The message you send must also cover network fees and the registrar's own outgoing work — the NFT mint and the resolver syncs. Read Integration before you build a checkout.
What a name resolves to, today
Records live in the resolver as an open map of categories, so new integrations need no contract change. The wallet category is the one that matters at launch: a name resolves to a TON address, and a compliant client sends funds to it.
Two properties worth calling out:
- Wipe-on-transfer. Selling the NFT wipes the resolver records. A sold name never resolves to the seller — stricter than ENS, and the direct fix for the "I bought the name and the old owner still receives the money" failure.
- Root-agnostic resolution. The resolver answers on the emoji label itself, so the same records work regardless of which parent domain the query walked in through. That is what makes the roadmap below possible without re-registering anything.
Integration roadmap — where we actually are
Stage 1 · live mechanism, pre-mainnet deployment
<name>.emojiverse.ton. The resolver sits under a parent .ton domain via dns_next_resolver. Any TON client that implements TEP-81 resolves it with no changes on their side. This has been verified end-to-end — an emoji name resolved in a real wallet and delivered funds.
Stage 2 · native display
Wallets and explorers showing 🚀🌙 as the name rather than the raw address, and accepting it in a send field. This is integration work with individual clients — we can ship SDK support and documentation, but each client decides its own timeline.
Stage 3 · .emoji as a first-class suffix
The end state is 🚀🌙.emoji resolving natively, without a parent domain in the path. That requires adoption by parties we do not control — it is an ecosystem outcome, not a deploy we can schedule. We will not put a date on it.
What we can do, and have done, is make the resolver root-agnostic so that when it happens, existing names carry over byte-for-byte with no migration and no re-registration.
Security properties in one place
- Commit–reveal registration. The commitment binds to the committer's address, so a copied reveal fails. Front-running a registration does not work.
- Bounded admin. Pricing, referral rates, commit timing, auction duration and the permanent-upgrade price are all admin-tunable only inside immutable bounds. A fully compromised admin key cannot raise renewal costs, cannot make the namespace free or unaffordable, cannot disable front-run protection, and cannot seize a live name.
- Two-step, timelocked handover for the admin key, and since V7 the signer key too — signer rotation stages behind the same timelock and requires the incoming key to prove possession.
- Domain-separated attestations. A signature is valid for exactly one registrar contract and one published normalization ruleset. It cannot be replayed onto a second deployment, and changing the ruleset revokes every outstanding signature.
- Escrow is never spendable.
freeBalance()excludes live auction bids, and a withdrawal that would dip into escrow is refused.
The full evidence is in Security and operability.