Games, sidechains and gamer tags

Register your game once. Every player can then own theirname@yourgame: a gamer tag that anyone can send Divi to, that shows up in every Divi wallet, and that ties their accounts across all the products that join.

1. Register your game or sidechain

A top-level name is a namespace. Register it from the studio's own Divi wallet (that address becomes the owner — keep it cold) and name a signer: a separate hot key your game server uses to approve tags.

POST https://name.divi.cx/api/v1/build
{ "network": "mainnet", "op": "register", "name": "yourgame",
  "payer": "DStudio…", "divi": "DStudio…",
  "fields": {
    "kind": "game",
    "signer": "DServerHotKey…",
    "site": "https://yourgame.example",
    "policy": "closed"
  } }

Pay what send says (500 DIVI for a 6+ letter name), broadcast, POST /notify. With the CLI:

dvns register yourgame --wif-file studio.wif \
  --field kind=game --field signer=DServerHotKey… --field site=https://yourgame.example

2. Let players claim gamer tags

Choose how open your namespace is:

The verified flow

1. The player, logged in to your game, asks for knight@yourgame and gives the Divi address that should receive payments.
2. Your server checks the player really is knight, then signs DVNS1 auth knight@yourgame <owner> <divi> with the signer key (Divi signmessage, base64).
3. The player's wallet calls /build with that auth, pays 10 DIVI, and owns the tag. The signature only works for that name, owner and address.

// Game server (Node). Signs with a divid that holds the signer key,
// or shell out to: dvns sign-auth --wif-file signer.wif --name … --owner … --divi …
app.post("/divi-tag", requireLogin, async (req, res) => {
  const tag = req.user.gameName.toLowerCase();         // you decide the tag
  const { address } = req.body;                        // player's Divi address
  const name = `${tag}@yourgame`;
  const message = `DVNS1 auth ${name} ${address} ${address}`;
  const auth = await diviRpc("signmessage", [SIGNER_ADDRESS, message]);
  res.json({ name, auth, account: req.user.id });
});

// Player's browser, with the IronDivi extension or any Divi wallet
const { name, auth, account } = await (await fetch("/divi-tag", { method: "POST", … })).json();
const built = await (await fetch("https://name.divi.cx/api/v1/build", {
  method: "POST", headers: { "content-type": "application/json" },
  body: JSON.stringify({ op: "register", name, payer: address, divi: address, auth,
                         fields: { kind: "gamertag", "chain.yourgame": account } })
})).json();
// wallet pays built.send.amount to built.send.to with built.send.memo, then POST /api/v1/notify

If /build answers 409 for a tag, its auth_message is the exact text your server must sign. Check a tag first with GET /api/v1/fee?name=knight@yourgame.

3. Use the names

GET /api/v1/resolve/knight@yourgame            → pay a player, show their address
GET /api/v1/names?ns=yourgame&limit=1000       → every gamer tag in your game
GET /api/v1/names?address=DPlayer…             → every name this player has, in any game
GET /api/v1/names?kind=game&top=true            → every game on Divi

Prizes, tips, trades and refunds can go to a gamer tag instead of an address. Any Divi wallet that supports names sends to knight@yourgame directly.

Connect accounts across products

When a player's tags in different games point at the same Divi address, one lookup ties them together — no shared login, no data deal between studios. That is the cross-marketing hook:

• Recognise players from partner games. names?address= shows knight@othergame; greet them, grant a crossover item, skip onboarding.
• Carry identity. Put the in-game account in the tag (chain.yourgame=player-48213) so a partner can map a Divi name back to an account in your game.
• Run shared events. A tournament across several titles pays winners by gamer tag; every studio sees the same names.
• Launch the next title fast. Your new game's namespace can offer existing players their same tag first by checking your other namespace.

Players stay in control: they own their tags, choose which address each points at, and can update or delete them (10 DIVI).

Rules worth knowing

• Tags are 1–32 of a-z 0-9 - _; namespaces need 3+ characters. Everything is lower-case.
• Records apply once confirmed, ordered by block height then txid. The first valid claim wins.
• Update replaces the whole record — resend fields you want to keep. Transfer by updating owner.
• To rotate a leaked signer key, update the namespace with a new signer. Tags already registered stay.
• Names are as safe as addresses: show the address beside the name before sending.

Next: the developer guide, the OpenAPI spec, or llms.txt for your AI agent.