Using emoji names

Revenue share

Two on-chain revenue programmes — a per-sale referral with a raisable KOL rate, and a standing partner split. Both settle inside the registration transaction, with no claim step.

Two programmes, both settled on-chain, in the same transaction as the sale. There is no accrual ledger, no claim button, no monthly payout run, and nothing to trust us to honour later. The GRAM moves when the name is bought.

Referrals

Anyone can refer a registration. The referrer's address rides along in the reveal, and the registrar pays them their share out of the sale as it settles.

Default public rate5%

Public ceiling20% — hardcoded, admin cannot exceed it 🔒

KOL override ceiling33% — absolute hard cap, per address 🔒

PaidAutomatically, in the registration transaction

Taken fromThe license fee — not added on top of what the buyer pays

That last row is the one to read twice. A referral does not make the name more expensive. The buyer pays the same price either way; the share comes out of the protocol's cut.

Custom rates for KOLs

The public rate applies to everyone by default. For creators and communities who bring real volume, a custom per-address rate can be set — up to a maximum of 33%.

The override is per referrer, stored on-chain, and it does not need the referrer to do anything differently: they use the same referral link, and the contract looks up their rate when the sale settles.

Two ceilings, both immutable REFERRAL_BPS_CEIL (20%) bounds the public rate. REFERRAL_KOL_BPS_CEIL (33%) bounds any individual override. Neither can be raised by an admin — they are constants in the contract. So the maximum share that can ever leave the protocol through referrals is knowable in advance, which is the point of putting a cap in code rather than in a policy document.

Self-referral does not work

The contract compares the referrer to the address receiving the name and refuses a match. You cannot mint your own discount.

Partner programme

Where referrals are per-sale, the partner programme is a standing split: an ecosystem partner is registered on-chain with a share of revenue, and they receive it on every qualifying sale, forever, without doing anything per transaction.

Maximum partners4

Combined ceiling30% across all partners 🔒

PaidAutomatically, in the registration transaction

VisibilityOn-chain and publicly readable

Partners are for the integrations that make the namespace worth something — a wallet that ships native emoji-name support, a marketplace that lists the collection properly, an infrastructure provider carrying the resolution load.

The bounds compose safely Four partners at the combined ceiling plus a maximum KOL referral is a tested scenario, not a hopeful one. The registrar refuses any configuration where the outbound shares could exceed the fee, so no combination of partner deals and referral overrides can put the contract in a position where it owes more than it took.

Interested?

Partner slots are limited to four, and KOL rates are set per address. Reach out through the contact page — Stef handles operations, Buzz handles marketing and creator partnerships.

Referral dashboard A self-serve dashboard for generating referral links and reading your on-chain earnings ships alongside the mini-app. Until then, referral payouts are already fully visible on-chain — every one is an outgoing message from the registrar in the same transaction as the sale.

For developers

Referrals are one optional field in the reveal message. If you are building a checkout and want to earn on the names you sell:

revealBody({
  nameHash, salt, emojiCount, numYears,
  newOwner: buyer.address,
  referrer: yourAddress,   // <- that is the whole integration
  name, content, signature,
});

The share is computed and paid by the contract. You do not invoice anyone, and there is no state you have to maintain. See Integration for the full message shape.