# NamID Protocol > NamID is a naming and identity protocol on the Chia blockchain, built by Web3UTXO LLC (New Mexico, USA). A name such as `yourname.x` is a coin that only its owner's key controls; it carries the owner's payment address and records, and anyone can check them against the chain instead of trusting a server. Everything runs on Chia testnet11. Nothing is on mainnet, nothing is audited, and there is no token. Facts an agent should keep straight: - A name is a label plus a TLD: `yourname.x` is the label `yourname` under the TLD `x`. Labels are lowercase `a-z` and `0-9`, 1-63 characters, no hyphens. - Names on `.x`, `.nm`, `.ids` and `.mojo` are permanent and soulbound by default. Other TLDs follow their owner's rules; read them first. - An agent never holds the key that owns a name and never pays for one itself. It asks; a person approves in their own wallet. - Amounts are whole mojos (1 XCH = 10^12 mojos). Testnet coins (TXCH) have no market value. - The one contact address is info@namid.net. ## Start here - [Home](https://namid.net/): the introduction and a map of the site in six steps - [For AI agents](https://namid.net/for-agents.html): resolve a name, read and check its records and agent card, pay a name, ask a person for a name; every public endpoint with its status - [skill.md](https://namid.net/skill.md): the same flows as a skill file - [API manifest](https://namid.net/api/agent): the whole registry API in one JSON document (conventions, signing, flows, error codes, limits) - [namid.json](https://namid.net/.well-known/namid.json): products, endpoints, status and contact, machine-readable ## How it works - [Whitepaper](https://namid.net/whitepaper/): the protocol specification, v1.5.1 draft, 20 sections - [Technical overview](https://namid.net/technical-overview.html): what the chain enforces, what servers do, known limitations - [Auctions](https://namid.net/auctions.html): how TLDs are released and sold, sealed-bid, second price, in XCH - [did:namid](https://namid.net/did-namid.html): every name is a W3C decentralized identifier ## Products (Chia testnet11) - [NamID app](https://testnet.namidbase.com/): bid for a TLD; register, resolve and manage names; pay a name; read every NamID transaction - [MyMojos](https://mymojos.com/): one app for a `.mojo` name: profile, payments, calls, mail, communities, agents, the Market - [names.cat](https://names.cat/): the name shop; search, see who holds a name, buy from your own wallet - [Explorer](https://testnet.namidbase.com/explorer): every NamID transaction - [Calls](https://namid.net/call/): call one name from another in a browser - [Mango wallet](https://namid.net/mango/): Web3UTXO's Sage fork and browser extension; unsigned builds ## Company - [Seed round](https://pitch.namid.net/): what is built, what is not, and the ask - [Roadmap](https://namid.net/roadmap.html): the mainnet launch, after an independent audit - [web3utxo.com](https://web3utxo.com/): the company and every application it runs ## Optional - [llms-full.txt](https://namid.net/llms-full.txt): the text of this site's main pages and the whitepaper in one file - [Learn in ELI5 style](https://namid.net/learn-eli5.html): an illustrated beginner's guide - [Validation report](https://namid.net/validation.html): dated development evidence from September 2026 - [Donate](https://namid.net/donate.html): the protocol treasury, mainnet XCH only --- The rest of this file is the text of namid.net's main pages and the whitepaper, generated from the published pages by scripts/build-namid-net-llms.py. It says nothing the pages do not. # NamID Protocol — home Source: Naming and identity on Chia · Web3UTXO LLC ## Your name is a coin. Every answer is a proof. Domain names made Web2 usable. NamID names do the same for Web3. A name such as `yourname.x` is a coin on Chia that only its owner's key controls. It carries the owner's payment address and records, and anyone can check them against the chain instead of taking them from us. Open the NamID app (testnet) Read the whitepaper For AI agents - Chia testnet11 - Not audited - Specification v1.5.1 draft · 20 Oct 2026 - No protocol token Documentation only This site asks for no keys, signatures or payments Chia coin-set model Every name is its own singleton coin Chain-only resolution Any Chia node answers; no trusted server Testnet first No mainnet before an independent audit Start here ### The whole site, in six steps. Each step is a short section on this page and a set of links to the full text. An AI agent can read the same map as plain text in llms.txt . #### What NamID is One name you own for life: get paid, sign in, publish records, take mail and calls. - Learn it in plain words - The one-page pitch #### How it works A coin per name, an on-chain list per TLD, a client that checks both. - Whitepaper (the specification) - Technical overview - How TLD auctions work - The did:namid method #### Live products Two applications and the doors around them, each with its status today. - NamID app - MyMojos - names.cat, the name shop - Explorer #### Documentation The specification, the evidence, and the reservation policy. - Whitepaper PDF - Validation report - Reserved names - Roadmap #### For developers and AI agents Resolve a name, read its records and agent card, ask a person to approve a name. - The agent guide - skill.md - /api/agent (JSON) - namid.json index #### Company and contact Web3UTXO LLC, New Mexico. One address for everything. - Seed round - Investors - Donate - info@namid.net 1 · What NamID is ### Owned by you. Provable without us. On the web you know, an operator keeps your account and can revoke it. A NamID name is a coin that only its owner key can spend, and everything below is bound to that coin, so anyone can check it against the chain without trusting a server, ours included. Your name `yourname.x` in its own coin, with a `did:namid` identifier. Names on `.x`, `.nm`, `.ids` and `.mojo` are permanent and soulbound: no renewal, no lapse. Your money Wallets pay the name, not a 62-character address, and say before you approve whose wallet the payment reaches. Your mail Mail to a name is sealed to the key the name publishes, so only its owner can read it. Your calls Voice, video and chat addressed to a name. Both ends prove their names before the call connects. Your agents Software under its own name, with an agent card anyone can check and a spending limit the chain enforces. 2 · How it works ### Four layers, each checkable on chain. A name's coin carries its owner key and the hash of its records. The TLD's on-chain registrar proves the name is unique under that TLD. A client that talks only to a Chia node joins the two and returns either a verifiable answer or a refusal. The whitepaper specifies each layer; the technical overview says what is live. The trust path runs through the chain only. A NamID server may cache or serve copies, but a client accepts an answer only when the chain and the proofs agree. - **Singleton name coin**: One name, one coin, one lineage. The unspent tip says who controls the name. §3 - **On-chain registrar**: A sorted list of coins per TLD; an insert must prove the gap between its neighbours, so a duplicate cannot exist. §8 - **DATA_ROOT**: The hash of the name's records, in its coin. Every record comes with a proof against it. §10 - **Chain-only resolution**: The open client `namid-open` resolves a name from any node with no NamID server. §11 - **Sealed-bid TLD auctions**: Each TLD is sold once, second price, in XCH; a bid stays sealed in the bidder's wallet until reveal. Auctions - **did:namid**: Every name is a W3C decentralized identifier. The method If we vanished, your name would keep working. Since 19 October 2026 every TLD that issues names on testnet11 keeps its list of names on chain. `nocomp1019.nm` was registered and then resolved from a Chia node with every NamID host blocked. The 109,029 older `.nm` and `.ids` names are sealed in two anchor coins that no one can spend. Still on our side today: hosting record documents (checkable against `DATA_ROOT`) and the web front ends, both of which anyone can run. 3 · Live products · Chia testnet11 ### Two applications, one protocol. Both run today on Chia testnet11. Test coins (TXCH) carry no value, and nothing runs on mainnet before an independent audit. Both install in the official, unmodified Sage wallet: Apps → Install App → `namid.net` or `mymojos.com`. protocol and app NamID Bid for a TLD; register, resolve and manage names; pay a name; and see every NamID transaction in plain words.`testnet.namidbase.com` built on NamID MyMojos One app for your `.mojo` name: profile, tips, payments, calls, mail, communities, agents and the Market, where shops pay a flat rent and no commission.`mymojos.com` Every door, and its honest status on 29 October 2026 Door | Where | Status NamID app in Sage, with Messenger, Browser and DataLayer | Sage → Apps → Install App → `namid.net` | Live; NamID app 0.2.96 names.cat, the name shop | names.cat | Live on testnet. A listed name is bought in one transaction, name and price in the same block; run from a test script, not yet signed from a wallet in a browser Explorer | testnet.namidbase.com/explorer | Live Agent cards | namid.net/agents/ | Live; read-only in a browser Calls between names | namid.net/call/ | Live A website on a name | namid.net/sites/site1022.x/ | Live; every file checked against the name's coin Public profile of a name | namid.net/p/ | Live DNS resolver for browsers | `https://namid.net/dns-query` and the NamID root certificate | Live; a stock browser needs both to open a NamID name, and answers can be slow Mango wallet, our Sage fork | namid.net/mango/ | Windows installer 0.13.4 and browser extension 0.9.4; unsigned builds - Not audited. Payment channels, the sealed sets, the name-sale path and the MyMojos Market escrow have had no independent review. - namid.net holds no registry, no auction book and no keys. Its `/api/` is a proxy; the service behind it makes every decision, and a client should still check the chain. - testnet.namidbase.com and namidbase.com share a name and not a network. The public mainnet app opens at namidbase.com after the audit. - Every application Web3UTXO runs, venues included, is listed at web3utxo.com/apps/ . 4 · Documentation ### The specification, and the evidence. The whitepaper is the protocol specification and nothing else; every mechanic in it cites the constant that implements it. Open policy questions are listed in it rather than decided by assumption. Technical overview A dated tour of the puzzles, what servers do, and known limitations. did:namid DID method Syntax, document, resolution and operations. Auctions and the release schedule How TLDs are released and sold, sealed-bid, second price. Validation report Dated development evidence from September, and what remains. Learn in ELI5 style An illustrated beginner's guide; also a 20-page PDF. Code and the NamID Book Code, tests, the open client and the NamID Book are private for now; ask and we will share them. #### NamID Protocol: the specification Version 1.5.1 (draft) · revised 20 October 2026 · 20 sections - Abstract - Conventions and terminology - The name primitive - Roots: the release schedule - Roots: sealed-bid auctions - Roots: lease, renewal and lapse - Reserved roots and allocation classes - Registrars - Sealed sets - Records - Resolution - Identity and agents - Payments to a name - Payment channels - Mail and call addressing - Governance and policy - Security considerations - Conformance - Open questions - Changelog Read it online Download the PDF 4 · Documentation · reservation map ### Scarce names are held before public bidding. The policy separates community governance, verified gifts, ecosystem infrastructure, and mandatory safety screens. A reservation prevents a public bid; it does not prove identity or promise a transfer. #### DAO-held scarce roots 24 single letters (every letter but the service roots `x` and `i`), all 10 single digits, and 9 DAO words. a-h j-w y z 0-9 bharat hns ind india root strict tld usa xch #### 10,000 popular-site gifts Exactly 10,000 eligible, unique popular-site gifts. ICANN labels take priority; withdrawn entries are replenished from documented Cisco Umbrella rankings. 10,000 unique labels DNSSEC claim DAO vote #### Protocol and ecosystem roots Infrastructure roots are held by Web3UTXO LLC. 84 Chia participant names are treasury-held for possible verified good-faith gifts. chia i ids mojo mojos names namid namidbase namids nm wallets xbram gene justin marianonicholas #### External collision and safety screens 1,438 ICANN root-zone labels are recognized, with 1,281 effectively locked; ICANN labels take priority over company, DAO and gift allocations. The pinned OFAC exact-name normalization contains 38,953 labels. ICANN root zone OFAC exact screen fail closed no fuzzy identity claim Policy boundary: first-name reservations are not identity credentials, endorsements, awards, or entitlements. The treasury must verify the intended recipient before any allocation. Browse the complete operational catalog and individual root status at testnet.namidbase.com/dao . Development evidence · Chia testnet11 ### What runs today, in numbers. - 153,159 names registered on chain, each in its own coin; 152,179 with records anchored in their own coin. - 15 sealed-bid TLD auctions settled on chain, of 31 opened. - 524 calls between agent names; 503 completed, all with both signed receipts verified. - A name sold on chain in one transaction: name to the buyer and price to the seller in the same block, 4,876,973 (26 Oct). - 109,029 older `.nm` and `.ids` names sealed in two anchor coins that can never be spent (19 Oct); 70,044 channel payments settled through two hubs (19 Oct). Read from the live system on 27 October 2026 at block 4,884,912 unless dated otherwise. Testnet coins have no market value. Payment channels, the sealed sets and the MyMojos Market escrow are not audited. What is live, in detail Check it in the explorer The September validation report 5 · For developers and AI agents ### An ID for software that works and pays. An agent can resolve a name, read its records and its agent card, read a TLD owner's rules, and ask a person for a name. It never holds the key that owns a name and never pays for one itself: a person approves in their own wallet. Everything here is public JSON on testnet11. ``` GET https://namid.net/api/agent the whole API, described in one JSON document GET https://namid.net/api/names/resolve?name=agentr.x records, terms and the coin behind them GET https://namid.net/api/names/agent?name=agentr.x the agent card and its hash GET https://namid.net/api/namespace/terms?root=x the TLD owner's rules: expiry, transfer ``` The agent guide How an agent resolves a name, reads its records, checks an agent card and pays a name, and which APIs are public. - skill.md , the same as a skill file - llms.txt and llms-full.txt , this site as plain text - /.well-known/namid.json , every product and endpoint with its status - Every agent card on testnet 6 · Company and contact ### Web3UTXO LLC, New Mexico, USA. Contact: info@namid.net , the one address for everything. Revenue is paid in XCH; there is no token. Seed round What we are building, the work done, what is not done, and the ask. pitch.namid.net · Investors Roadmap The mainnet launch of the NamID app and MyMojos, after an independent audit. Roadmap Support the work The protocol treasury, mainnet XCH only. Donate · web3utxo.com # NamID for AI agents Source: For developers and AI agents · Chia testnet11 ## NamID for AI agents How an agent finds a NamID name, reads what it publishes, checks it against the chain, pays it with a person's approval, and asks a person for a name of its own. Every route below is public and answered on 29 October 2026. Nothing here asks for a key. - Four rules - Discover the API - Resolve a name - Read records and check them - Read and check an agent card - Pay a name - Ask a person for a name - Every public endpoint, with its status - Errors, limits and what is not here ### 1 · Four rules - The agent never holds the key that owns a name and never pays for one itself. It files a request; a person approves in their own wallet. - The TLD owner's rules come first. Read them before asking for a name, and tell the person what they say. - A server's answer is not consensus. Where an answer carries a proof, check it, or resolve from a Chia node with the open client. - This is testnet11. Amounts are TXCH, which has no market value. Nothing runs on mainnet before an independent audit. Names are lowercase `a-z` and `0-9`, 1–63 characters per label, no hyphens: `yourname.x` is the label `yourname` under the TLD `x`. Amounts are whole mojos (1 TXCH = 1012 mojos), sent as integers or strings, never decimals. ### 2 · Discover the API The base URL is `https://namid.net`; the registry answers under `/api/`. One JSON document describes every flow, the signing scheme, the error codes and the limits: ``` GET https://namid.net/api/agent the whole API: conventions, signing, flows, codes, limits GET https://namid.net/api/agent/roots which TLDs take names, and on what terms ``` The same map in other shapes: /.well-known/namid.json (products, endpoints, status, contact), llms.txt and llms-full.txt (this site as plain text), and skill.md (the flows as a skill file an agent can load). ### 3 · Resolve a name ``` GET /api/names/resolve?name=agentr.x records, terms and the coin: launcher_id, coin_id, puzzle GET /api/names/authority?name=agentr.x whether the name is held and served, and why GET /api/profile?name=agentr.x the public profile, with the did:namid identifier GET /api/did/resolve?did= a W3C DID resolution result ``` A name that has lapsed or changed hands resolves to nothing, never to the previous holder's data. The did:namid method also answers at the Universal Resolver path `/1.0/identifiers/`. For a browser, `https://namid.net/dns-query` answers DNS over HTTPS (RFC 8484) for NamID names; it needs the NamID root certificate to open them over HTTPS. To trust no server at all, the open client `namid-open` (Python and JavaScript) rebuilds a TLD's on-chain registrar from a Chia node you choose and resolves the name itself. Its code is shared on request: info@namid.net . ### 4 · Read records and check them A name's records (payment address, profile, socials, DNS rows, agent card) are committed by the hash in its own coin. Each key can be proved against the store's root, which is on chain: ``` GET /api/names/datalayer/proof?name=agentr.x&key=agent/card inclusion proof for one key GET /api/names/addr?name= Bitcoin addresses the holder published ``` A Bitcoin address in a name's records is checksum-verified and is a pointer, not a proof: paying it is an ordinary Bitcoin transaction with no NamID involvement and no way back if the address is wrong. Say so to the person. ### 5 · Read and check an agent card An agent card is a record on a name that says what the agent behind it does, where to reach it and how to pay it. Its shape follows the open A2A agent card; NamID adds payment and spending fields. ``` GET /api/names/agent?name=agentr.x the card, its sha256 card_hash and an A2A view GET /api/agents?q=calendar every name with a card, by search words ``` To check a copy, serialise the card as JSON with sorted keys and no spaces, take its sha256 and compare it with `card_hash`; the same bytes are the key `agent/card` in the name's records, provable as in step 4. A card that does not match is not the owner's. See a live one: agentr.x , or every card on testnet . ### 6 · Pay a name ``` GET /api/pay/to?name=agentr.x the address to pay, where it came from, and whose wallet it reaches ``` The answer names its `source` and a `holder` relation: the holder's own key, another address of the same wallet, or a different wallet (with a plain warning). Show that line to the person before they approve. The person's wallet makes the payment, with the memo `nm1:pay`; ask before any payment unless the card's `spending` field and the person's own instructions say otherwise. An owner can also give an agent its own budget on chain, which the agent spends with its own key and which every Chia node holds to its cap. The steps are in skill.md . ### 7 · Ask a person for a name ``` GET /api/namespace/terms?root=x does it expire, can it change hands GET /api/names/wallet-register/plan?root=x&label=mybot available? price in mojos? lock mode? POST /api/agent/requests {"name": "mybot.x", "from": "who you are", "note": "why", "card": {…}} GET /api/agent/requests?id= waiting | registered | done | expired ``` The request answers with an `approve_url`. Give it to the person who will own the name; they approve in their own wallet and the name belongs to their key. A request does not hold the name, and expires after 7 days. Every other write (records, a card on an existing name) needs a signature from the key that owns the name, over a single-use challenge from `POST /api/vault/challenge` (CHIP-0002 message signing); /api/agent lists each one. ### 8 · Every public endpoint, with its status Status is what a plain `GET` answered on 29 October 2026. "Live" means it answered; it does not mean audited. Endpoint | What it answers | Status `/api/agent` | The API described in one JSON document | Live `/api/agent/roots` | TLDs that take names, and their terms | Live `/api/names/resolve` | Records, terms and the coin behind a name | Live `/api/names/authority` | Whether a name is held and served | Live `/api/names/agent`, `/api/agents` | Agent cards | Live `/api/names/datalayer/proof` | A proof for one record key | Live `/api/names/addr` | Bitcoin addresses a name published | Live `/api/pay/to` | The address to pay, and whose wallet it reaches | Live; Chia only `/api/namespace/terms`, `/api/namespace/rules` | A TLD owner's rules | Live `/api/names/wallet-register/plan` | Availability and price of a name | Live `/api/agent/requests` | A name request for a person to approve | Live `/api/profile`, `/api/did/resolve` | Profile and DID resolution | Live `/dns-query` | DNS over HTTPS for NamID names | Live; answers can be slow `/sites//` | A website published on a name, every file checked | Live ### 9 · Errors, limits and what is not here - Every refusal is JSON `{ok: false, code, error}`. `code` is stable; show `error` to the person. Retry only when the answer says `retry: true`. - Requests are rate-limited per address. On `429`, back off; ask for one name at a time rather than hundreds at once. - A wallet approval screen expires after 3 minutes; a challenge nonce is spent by its first use. - An MCP server (stdio) exposes the same flows; its code, like the open client's, is shared on request. - Not here: mainnet, custody of any key, and any write without the owner's signature or payment. These pages are static; they call nothing and store nothing. Questions, or an integration to try on testnet: info@namid.net . # Technical overview Source: ## A naming protocol on Chia whose rules are puzzles, not database rows. Every NamID name, root or second-level, is a Chia singleton coin, its deed: a standard Chia DID whose puzzle carries the name, the owner's key, the lock policy and `DATA_ROOT`, the commitment to the name's records. Under each root an on-chain registrar keeps the list of names, so uniqueness is enforced by consensus. A client resolves a name from a Chia node alone and refuses any answer it cannot verify. This page keeps three things apart: what the chain enforces, what servers still do, and what is not finished. The normative text is the whitepaper (v1.5, 19 October 2026) ; section numbers below (§) point into it. 153,128 names on chain, each in its own coin Chain-only resolution proved Not audited testnet11 only, nothing on mainnet ### 00Where it stands, 19 October 2026 Read from the live testnet11 system on 19 October 2026. Not audited; nothing runs on mainnet before an independent audit. Piece | State | What it does Names on chain | live | 153,128 names on testnet11, each its own coin; new names are Chia DIDs that Chia's own DID tools read (§3.2 ). Names on the service roots `.x`, `.nm`, `.ids` and `.mojo` are permanent and soulbound (§16.4 ). 152,179 names have records whose fingerprint is anchored in their own coin. On-chain registrars | live | Every root that issues names keeps its list on chain: `.x`, `.mojo`, `.nm`, `.ids`, `.chia` and the auction TLDs whose owners alone issue names. Registrar v6 is current; v7 is a draft (§8.8 ). Sealed sets | live | The 109,029 older `.nm` and `.ids` names that predate the registrars are committed in two anchor coins that can never be spent (55,747 and 53,282 leaves). A client proves membership or non-membership against them from the chain (§9 ). Chain-only client | proved | An open client (Python and JavaScript) rebuilds a root's list from any Chia node, resolves and registers. `nocomp1019.nm` was registered and resolved with every NamID server blocked (§11.4 ). Code access on request. TLD auctions | live | Sealed-bid, second price; 16 settled on chain. A bid is sealed in the bidder's own wallet. Winners receive the root as a soulbound DID deed in the same transaction (§5.4 ). Payment channels | not audited | Names pay each other off chain and settle on chain; transfers are hash-locked, so an intermediary cannot keep what it forwards. 70,044 channel payments settled; new channels use a 64-block dispute window (§14 ). Pay to a name | live | One answer for every wallet: the name's address and how it is proved (deed key, anchored record or registry only), any recent change, and an `nm1` memo on chain (§13 ). Mail and calls | live | Addressed to a name through the keys it publishes in its records; bodies and call signalling are sealed to the recipient's key, and a sender is shown as a name only with that name's signature (§15 ). Apps | testnet | NamID, the protocol with the NamID app and wallet (testnet.namidbase.com ), and MyMojos, built on NamID (mymojos.com ), whose marketplace escrow is not audited. ### 01What the chain enforces Chialisp puzzles. A full node refuses a spend that breaks them. Paths are relative to `primitives/all-kinds-of-nft/puzzles/` (§2.4 ). Puzzle | What it guarantees | Spec `did-deed/namid_deed_did.clsp` | The deed: a standard Chia DID whose covenant re-curries `NAME`, the owner key, the lock and `DATA_ROOT` into every generation. A deed can never be melted. Lock policies only tighten. | §3.2 `did-deed/namid_deed_did_boot.clsp` | The boot eve of an auction-minted root: proves its own launcher id and becomes the deed, with no signature, in the settlement bundle. | §5.4 key rotation (in the deed) | Every key change is announced, delayed and cancellable: `rotate` (current and new key sign), `cancel` (no time bound), `finalize` (anyone, after the delay). 9216 blocks on mainnet, 96 on testnet11. | §3.5 `register/namid_slot_node_v6.clsp` | The registrar: a sorted linked list of node coins. An insert must land strictly inside its predecessor's gap, so a label has at most one node. `TERMS` (price, term, transferability, rotation delay, root name) are curried into every node and fixed for the generation's life. | §8 deed-bound owners (in the registrar) | A node owned by a deed accepts an owner action only when that deed's current coin is spent alongside and its key signs: one key per name. | §8.5 sealed-set anchor, puzzle `(x)` | A 1-mojo coin that fails for every solution: it can never be spent, and its puzzle hash commits to the root, the Merkle root, the count and the leaf file's sha256. | §9.3 `namid_tld_lease.clsp` | The root's lease. `renew` is permissionless (payment is the authorisation); `close` cannot fire before the term ends. | §6.1 `tldbase_bid_v5c.clsp`, `tldbase_escrow_v4` | A sealed bid commits to `sha256tree(TLD, real, salt)`. A revealed amount moves into an escrow that can only pay the treasury or refund that bidder; an unrevealed deposit can only be burned. | §5.2 `agent/namid_agent_allowance_v3.clsp` | An agent's spending budget: payments and fees never exceed the limit in any window; the owner can empty it at any time; after expiry the remainder returns to the owner. | §12.4 `payment-channel/namid_channel.clsp`, `namid_htlc.clsp` | Two-party channels: the newest co-signed state wins, settlement waits the dispute window, and hash locks release only with the preimage, before their expiry. | §14 ### 02Chain versus server Being explicit about this is the point of building on a chain. Everything on the right can be run by anyone, and none of it decides who owns a name. ##### The chain enforces - Ownership of every deed, its lock policy, and that `NAME` never changes - The public, cancellable delay on every key change - Uniqueness of every name under a root, and the root owner's terms in the registrar - That an owner-only registrar accepts names only from the root owner (§8.6) - Sealed sets: immutable anchors; under registrar v7, enforced in the puzzle - The root lease: renewal by anyone who pays, no early close - Auction escrow payouts and refunds, and the burn of unrevealed bids - Agent budgets, channel closes and disputes ##### Servers still do - Host record documents. The commitment (`DATA_ROOT`) is on chain; a client hashes what it fetched and refuses a mismatch (§10). - Run the auction book: it receives commitments and deposit totals, never a real amount before its reveal (§5.2). - Publish the client manifest naming each root's current registrar generation, its genesis head and its sealed-set anchor; the chain alone cannot say which generation is current (§11.6). - Relay mail, call signalling and channel payments (hubs); they see routing metadata, not contents (§15). - Serve the front ends and the resolver API, which returns unsigned drafts only (§5.6). ### 03Registering a name A name is registered only when it is on chain in its own coin. A list, commitment or reservation held off chain reserves nothing (§8 ). - Find the gap. The client syncs the root's registrar from the chain and finds the node whose gap holds the label (`VALUE < label < NEXT_VALUE`). Where the root has a sealed set, the label must also be proved absent from it. - Build one bundle. It launches the name's DID deed and inserts its node, re-creating the predecessor to point at it, and pays the registrar's `PRICE` through the standard settlement puzzle (§8.9 ). - The owner signs and pays. The buyer's own wallet signs and pays every fee; a service never pays a user's fee (§16.5 ). - Owner-only roots. Under an owner-only registrar one interval covers every label, and only the root owner's key can insert inside it (§8.6 ). ### 04Resolving a name from the chain Resolution is fail-closed: an unverifiable answer is never returned as success (§11.1 ). - Parse the name against the label grammar: `a-z0-9`, 1 to 63 characters, at most 4 labels. - Load the root's registrar from the manifest, then fetch the coins hinted with its id and keep only those that descend from the genesis head through genuine registrar spends. - Find the label in a node, or prove it in or out of the sealed set against the anchor coin. - Read the deed: walk its lineage to the unspent tip and read the owner key, the lock and `DATA_ROOT`. - Verify the record fetched from any source against `DATA_ROOT`, and return a resolution-proof object or a typed outcome: `registered`, `unregistered`, `lapsed`, `collision`, `frozen` (§11.3 ). The only external dependency is a Chia full node or a compatible coin-set RPC. Every name is also a DID: see the `did:namid` method . ### 05Roots: schedule, auction, lease Roots are paid in XCH; the Protocol has no token and every sale pays the protocol treasury (§16.1 ). ##### A public release schedule Each root's release week is `sha256(SEED ‖ 0x00 ‖ name)` mod 260 weeks: computable by anyone, gameable by no one. Twenty auctions open per day from the interest queue; EARLY-OPEN costs ten times the reserve and gives no bidding advantage (§4 , §5.5 ). ##### Sealed bids nobody can read The salt is derived from the bidder's wallet signature; the auction service receives only the commitment and the deposit total. An optional blind hides the real amount inside the deposit. A bid carries no memo (§5.2 ). ##### Second price, one transaction The winner pays the second-highest revealed bid (or the reserve, at least 10 USD in XCH); refunds, the payment and the mint of the soulbound DID deed happen in one transaction. An unrevealed bid is no bid and can only be burned (§5.3 , §5.4 ). ##### A lease no one can take early A root is held by a three-year lease that anyone may renew. When it lapses the root returns to the auction pool; its owner alone may redeem it until a re-auction opens, and a re-auction mints a new identity (§6 ). ### 06Known limitations In one place, so they cannot be skimmed past (§17 , §19 ). ##### Not audited No puzzle has been independently audited. Nothing runs on mainnet before an independent audit. ##### A contested key is delayed, not settled If a key is genuinely compromised, both parties hold the current key and each can cancel the other's rotation. The window guarantees that no takeover is silent or fast; settling it needs a separate recovery key, which is an open question (§3.5, §19). ##### The current generation comes from a manifest A retired registrar generation still verifies; which one is current is named by the client manifest, not by the chain. Clients should pin manifests and compare them across sources (§11.6). ##### Sealed sets under registrar v6 are enforced by resolvers The v6 puzzle cannot see the sealed set, so it cannot refuse an insert of a sealed label; resolvers follow the sealed entry and report a `collision`. Registrar v7, a draft, enforces the set in the puzzle (§9.4). ##### Channels need someone watching A party offline longer than the dispute window can lose to a stale post. Anyone may run a watcher that answers one; it cannot start a close or move money (§14.4). ##### Encryption hides contents, not metadata Mail bodies and call signalling are sealed to the recipient's key; who talks to whom, when and how much is visible to the relay (§15). ##### Pricing above the floor is undecided The reserve floor is 10 USD in XCH; the schedule above it and the renewal price are open questions (§19). Not audited. testnet11 only. No mainnet broadcasts before an independent audit. ### 07Verify it yourself With the chain-only reference client, `packages/namid-open/`, and a Chia node of your choice (code access on request while it is reviewed): ``` # the roots the client knows, and a root's list rebuilt from the chain python3 namid_open.py roots python3 namid_open.py sync x # resolve a name: registrar node, deed lineage, owner, lock, DATA_ROOT python3 namid_open.py resolve nocomp1019.nm # a sealed-set membership or non-membership proof, checked against the anchor coin python3 namid_open.py sealed-proof de500.nm # check a records document fetched from anywhere against the name's DATA_ROOT python3 namid_open.py verify-records nocomp1019.nm records.json ``` The client refuses NamID hosts outright, and its end-to-end test blocks them at the socket (§11.4). # Auctions and the release schedule Source: Release schedule, bid limits, auction kinds, claims ## How root names are released, and how they are auctioned A root name is the part after the dot — the `x` in `yourname.x`. There are a lot of them, so they do not all go on sale at once. This page explains the order they open in, what a bid may cost, which of those limits the blockchain itself enforces and which are our policy, and how a company that already owns a domain claims the matching root. ### 1. About a hundred names a day, for three years. Then everything opens. Every root name has a release date worked out from the name itself. Anyone can compute it, and nobody can change it or get an earlier one. Roughly a hundred names reach their date each day, and that continues for three years. After those three years the schedule stops mattering: every remaining name opens to auction at once. We call that the pool. The only names that stay out of it are the ones that could never be auctioned anyway: - names reserved for someone — the 10,000 well-known sites, the names we hold for the services this protocol runs on, and the names held by the DAO; - names blocked outright — the 38,953 entries on the sanctions screen we apply, and the special-purpose names such as `.onion`, `.local` and `.test` that no naming system may sell; - names that match a TLD in the real DNS root zone, which are held for whoever operates the real one; - names somebody already owns. A name comes back only when its lease lapses. The same rule runs our test networks, just faster. The release window there is five days instead of five years, so the drip lasts three days and the pool opens on day three. It is one rule — the drip takes the first 60% of whatever window is configured, and the pool takes the other 40% — so a rehearsal on the fast clock is a rehearsal of the real thing and not a different mechanism wearing its name. #### The dates, as configured today Clock | Release window | Drip ends, pool opens | Auction kinds start rotating Live | 5 years | after 3 years | after 4 years Fast (testing) | 5 days | after 3 days | after 4 days Three years is exactly 60% of five, and four years is exactly 80% — which is why both are fractions of one window rather than three separate dates that could drift apart. ### 2. What a bid may cost — and who actually enforces it There is a floor and a ceiling on what a bid is worth. - A minimum. A bid has to be worth something. If bidding were free, somebody would bid on everything. Putting a real cost on each attempt is the cheapest defence against that there is. - A maximum. Above a certain figure, extra money buys nothing. The point of a name is the thing somebody builds behind it, and we would rather a name went to a small team with a product than to whoever has the largest balance. On the fast clock those figures are a minimum of one US dollar and a maximum of one hundred thousand. They are settings, not fixed features of the protocol, and they will change. #### The honest part: a dollar limit is our rule, not the blockchain's Chia has no idea what a dollar is. A Chia coin's rules can compare amounts of XCH and nothing else. So: Limit | Enforced by | Could we break it? The minimum, written in XCH | the coin's own rules — it is built into the escrow coin every bid pays into | No. Not us, not anyone. The minimum, written in dollars | us, converting dollars to XCH when the auction opens | Yes — the conversion is ours The maximum | us, when a bid is opened at the reveal | Yes — it is house policy We convert the dollar figures into XCH once, at the moment an auction opens, and then that auction keeps those XCH numbers until it finishes. That way the minimum is a real rule of the coin for the whole auction, and the dollar figure can only drift for as long as one auction lasts rather than for years. Because bids are sealed, we cannot see that a bid is over the maximum until it is opened. When one is, we count it as the maximum rather than throwing it out — throwing it out would cost the bidder their whole deposit for breaking a rule they were told about. They simply do not get credit for the part above the cap. Anyone else running this protocol could set a different maximum, or none. The XCH minimum built into the escrow coin is the only limit that is not a matter of trusting an operator — and we would rather say so than let a page imply otherwise. ### 3. Four kinds of auction, taking turns After four years the auction house stops running one kind of auction and starts rotating between four. Which one is running depends only on the clock, so anyone can work out today's kind and nobody gets a private one. Kind | What it does | Who it suits Fixed price | One minimum for the whole auction. The plain auction, and what runs today. | everyone Falling price | The minimum starts high and falls as the auction runs. | patient bidders — wait and there is less to beat Rising price | The minimum starts low and rises as the auction runs. | decisive bidders — bid early and cheaply Capped | The ceiling drops to a fraction of the usual maximum. | small builders — a big balance cannot simply outbid you By default each kind gets a day, and on the fast clock six hours. Both are settings. Nothing about bidding changes between the kinds. You seal a bid, pay a deposit, and open it in the reveal window, in all four. What changes is the price your bid has to beat and when. We did it that way on purpose: a different kind of auction that needed a different way of bidding would mean two systems to learn and two to get right. And a change of kind never reaches an auction that has already started. The kind is fixed when the auction opens, and it keeps it until it settles. ### 4. Keeping names out of the hands of squatters Squatting is registering names you have no use for, to sell them back to whoever does. No naming system has solved it. These are the things we actually do, rather than the things that sound good: - The 10,000 best-known sites are reserved and claimable by their real owners, so the obvious impersonations are off the table on day one. - A floor on every bid, so bidding on everything costs real money. - A ceiling on every bid, so a large balance is not a strategy. - A limit on how many auctions one wallet can open in a day, so one person cannot occupy a day's worth of names and sit on them. Bidding in auctions somebody else opened is never limited. - A rising deposit for wallets that seal bids and never open them. Doing that fakes demand and pushes prices up; doing it repeatedly costs more each time, and the effect fades if you stop. - Names designed to be mistaken for ours are refused — `namld` for `namid`, for instance. Near-misses of ordinary names are allowed and simply shown to bidders, because deciding that `mangos` is a fake `mango` is not a judgement we should be making. Two popular ideas we decided against, and why. Making every name permanently for sale at a price its owner names would end squatting and also end the point: a name anyone can take by naming a price is not an identity. Requiring proof of identity, one name per person, would need an identity provider, which is the thing this protocol exists so that you do not need. ### 5. Claiming the root that matches your domain Say you run `xchfi.com` and you want `.xchfi`. Which of these applies to you depends on the name, and the claim page will tell you for any name you type. There is also a Claim tab inside the NamID app in the Sage wallet. #### If the name is already reserved for you This is the case for `.xchfi`, and for every one of the 10,000 well-known sites. The name is being held for whoever runs the matching domain, and it is not for sale to anyone else. You prove you control the domain using DNSSEC — a signed DNS record that we check all the way up to the internet's root keys, which means nobody can fake it by borrowing a DNS server for an hour. A verified proof makes the handover eligible for approval. It does not hand you a coin by itself and it does not skip the vote. #### If the name matches a real DNS top-level domain It is held for the organisation that operates the real one, and it cannot be won at auction by anybody. There is a date on the lock and the DAO can shorten or extend it. #### If the name is simply open to auction Then nobody is holding it for you, and owning the domain does not entitle you to the name. A `.com` costs about ten dollars; if a `.com` were a claim on a root, buying the domain the day before the auction would be the easiest way to take a name off somebody — the very thing this section is meant to prevent. What proving your domain does get you: - a published link between your domain and the name, so bidders can see who the established holder is; - the right to start the auction now instead of waiting for the name's release date; - the tie-break, if you and somebody else end up at the same price. You still bid, and you can still be outbid. We think that is the right answer: who already answers for a name is real information and worth publishing, but a domain is a contract with a registrar, not a deed. ### 6. Where the numbers live Every figure on this page is a setting the DAO can change, not something welded into the protocol, and the auction page for any name shows that name's own figures — the ones its auction opened with, which are not necessarily today's. Where a limit is our policy rather than a rule of the chain, the page says so there too. This describes the protocol as configured on 26 October 2026, on testnet11. Nothing on this page is an offer to sell a name, and the figures here will change before any live launch. # The did:namid DID method Source: DID method · specification v0.2 · 20 October 2026 ## The `did:namid` DID method. Every NamID name is a W3C Decentralized Identifier. This page is the method specification: the identifier syntax, the DID document a name resolves to, the four operations, and the security and privacy considerations. Resolve one now: `https://namid.net/api/did/resolve?did=did:namid:testnet11:agentr.x` Status: Draft, 2026-10-20 (v0.1: 2026-09-23) · Owner: Web3UTXO (NamID Protocol) Method name: `namid` · Ledger: Chia blockchain (singleton coins) · Licence: CC0 Registry entry: to be submitted to the W3C DID Extensions "DID Methods" registry (`w3c/did-extensions`, `methods.json`) once this document is published at https://namid.net/did-namid.html. Reference implementation: `did_namid.py` and `tld_uri.py` in `apps/NalandaX/registry-Backend-artefacts/`; tests in `tests/test_did_namid.py`. Protocol: this method is summarised in whitepaper §3.6 ; section numbers written "whitepaper §" below point into the whitepaper (v1.5) . This document follows the requirements for DID method specifications in DID Core §8 : method name, method-specific identifier syntax, the four operations, security and privacy considerations. ### 1. Why a method of its own NamID is a naming protocol on Chia in which every name is an identity: a root (`x`, `mojo`, `nm`) and a name beneath it (`yourname.x`) are each a singleton coin, the name's deed, which is a standard Chia DID whose id is its launcher id (whitepaper §3.2 ). Chia wallets already print DIDs as `did:chia:1…`, but `did:chia` is not a registered DID method and has no method specification; the only Chia-singleton method in the W3C registry is `did:julia`. A NamID identifier presented to the wider DID ecosystem therefore needs a method that is specified, resolvable and registered. `did:namid` is that method. Nothing older changes. The same 32 launcher bytes remain spellable as `did:chia:1…` (Chia-ecosystem interop), `tld:1…` (protocol-internal) and `namid:1…` (the protocol's own URI); the `did:namid` document lists all of them under `alsoKnownAs`. ### 2. Method name The method name is `namid`. A DID that uses this method MUST begin with `did:namid:`. ### 3. Method-specific identifier ``` did-namid = "did:namid:" [ network ":" ] id network = 1*16( %x61-7A / DIGIT ) ; lowercase; OMITTED on mainnet id = launcher-id / name launcher-id = "1" 1*bech32-char ; bech32m, checksum computed over the hrp "namid:" name = label *( "." label ) label = ( %x61-7A / DIGIT ) *61( %x61-7A / DIGIT / "-" ) ``` - Launcher form — `did:namid:1` (mainnet) or `did:namid:testnet11:1`. The bech32m string after `did:` is exactly the protocol URI `namid:1…`: the human-readable part of the checksum is `namid:`, so `did:namid:1…` and `namid:1…` share one checksum and one 32-byte payload, the launcher id of the name's singleton coin. This form is the canonical DID of a name once its coin exists on chain; it never changes for the life of the coin lineage. - Name form — `did:namid:yourname.x` / `did:namid:testnet11:yourname.x`. A valid DID (DID Core allows `.` and `-` in the method-specific id) that resolves to the same document. It is the DID of a name before its coin is minted, and an `equivalentId` of the launcher form afterwards. - Network — omitted for the Chia mainnet; any other network names itself (`testnet11`). `did:namid:mainnet:…` is invalid. A resolver serves one network and answers `notFound` for another. - Case — a `did:namid` identifier is lowercase; uppercase is invalid, not normalised. - Payment addresses are not identifiers — an id matching `^t?xch1[bech32]{20,}$` is invalid by grammar, because an `xch1…` string is a Chia address and an identifier that looks like one will be pasted into a Send box. Examples: ``` did:namid:14w46h2at4w46h2at4w46h2at4w46h2at4w46h2at4w46h2at4w4snsj9a4 did:namid:testnet11:14w46h2at4w46h2at4w46h2at4w46h2at4w46h2at4w46h2at4w4snsj9a4 did:namid:testnet11:yourname.x ``` ### 4. DID document ``` { "@context": ["https://www.w3.org/ns/did/v1", "https://namid.net/ns/did/v1"], "id": "did:namid:testnet11:1…", "alsoKnownAs": ["namid:yourname.x", "did:namid:testnet11:yourname.x", "did:chia:1…", "tld:1…", "namid:1…"], "controller": "did:key:z6Mk…", "verificationMethod": [{ "id": "did:namid:testnet11:1…#owner", "type": "Bls12381G1Key2020", "controller": "did:namid:testnet11:1…", "publicKeyMultibase": "z…" }], "authentication": ["did:namid:testnet11:1…#owner"], "capabilityInvocation": ["did:namid:testnet11:1…#owner"], "service": [ { "id": "…#namid", "type": "NamIDName", "serviceEndpoint": "https://namid.net/api/names/resolve?name=yourname.x" }, { "id": "…#xch", "type": "ChiaPaymentAddress", "serviceEndpoint": { "address": "txch1…", "network": "testnet11" } }, { "id": "…#website", "type": "LinkedDomains", "serviceEndpoint": "https://yourname.example" }, { "id": "…#dns", "type": "NamIDDNSRecords", "serviceEndpoint": { "records": [] } } ] } ``` - `controller` is the holder's DID when the name is recorded as bound to one (`did:key` or `did:chia`). It is absent when the name is controlled only by its owner key. - `verificationMethod` carries the name's BLS12-381 G1 owner key, the `OWNER_PUBKEY` curried in its deed (whitepaper §3.2), when the resolver has it. The key signs record updates and key rotations and, when the deed is transferable, transfers. - `service` entries are derived from the name's on-chain record set: the resolver endpoint, the XCH payment address, a linked website and DNS records. Nothing in the document is written by hand; it is a projection of the coin and its records. DID document metadata (returned by resolution, not part of the document): key | meaning `canonicalId` | the launcher form, once the coin exists `equivalentId` | `[the name form]` `versionId` | the current coin id of the singleton `created` / `updated` | registry timestamps `deactivated` | `true` after a lapse; always `false` for a soulbound name with `renewal: never` `namid` | `{name, root, lock_mode, renewal, issuer, namespace, mint_status, launcher_id, coin_id, record_sequence, expiry_block}` — the protocol's own view (standards/ROOT-PROFILES.md) ### 5. Operations #### 5.1 Create A `did:namid` is created by creating the name: - a root is won at the sealed-bid auction and minted as a soulbound DID deed in the settlement transaction (whitepaper §5.4 ); - a name under a root is registered by one spend bundle that launches its DID deed and inserts its node into the root's on-chain registrar, signed and paid by the owner's wallet (whitepaper §8.9 ). Under an owner-only registrar only the root owner can add names (§8.6 ). A name is registered only when it is on chain in its own coin, so both forms of the DID exist from the moment that transaction confirms (`mint_status: minted`). No separate "DID registration" step exists: a name that exists is a DID. #### 5.2 Read (resolve) ``` GET https://namid.net/api/did/resolve?did= GET https://namid.net/1.0/identifiers/ ; Universal Resolver driver shape GET https://namid.net/api/did/method ; the method descriptor ``` The response is a DID Resolution Result (`@context: https://w3id.org/did-resolution/v1`) with `didDocument`, `didResolutionMetadata` (`contentType: application/did+ld+json`, `retrieved`, `did`, `kind`) and `didDocumentMetadata` (§4). Errors use the registered names: `invalidDid` (400), `notFound` (404, including a network the resolver does not serve), `methodNotSupported` (400). A resolver MUST answer only with a record it can tie to the chain (the NamID verify-or-refuse rule: `/api/resolve` carries the proof) or refuse; a client MAY verify the singleton lineage itself against `didDocumentMetadata.namid.launcher_id`, from a Chia node alone, with the chain-only client algorithm (whitepaper §11.1 , §11.4 ). #### 5.3 Update Records (address, profile, DNS, services) are written signed by the key that controls the name and take effect when the deed's `update` commits the new `DATA_ROOT` (whitepaper §10.2 ); each update increments `record_sequence` and, because it spends the deed, changes `versionId`. Keys rotate through the announced, delayed and cancellable rotation (§3.5 ). The DID string never changes on update. #### 5.4 Deactivate - A termed name (a registrar with `TERM_BLOCKS > 0`) that is not renewed lapses at its `EXPIRY`; the document resolves with `deactivated: true` until the label is taken over, at which point a new deed and a new launcher-form DID exist (the name form resolves to the new one) (whitepaper §8.3 ). - A permanent name (`TERM_BLOCKS = 0`, `renewal: never`) never lapses, and its deed can never be melted (§3.2 ): it is never deactivated. - A root is deactivated when its lease lapses and a re-auction opens; the winner receives a new deed with a new launcher id, and the lapsed coin persists with no standing (§6.3 ). ### 6. Security considerations - Key compromise. The owner key authorises updates (and transfer, for transferable names). Every key change is public, delayed and cancellable, so a stolen key cannot quietly become the owner; without a separate recovery key a contested key can be delayed but not settled (whitepaper §3.5 , §19 ). - Root-owner key compromise. Under an owner-only registrar the root owner's key can add new names; it cannot move or alter existing ones, whose own owners sign every change. Every insert is a coin creation visible on chain (§8.6 ). - Resolver trust. The resolver is a projection of chain state and says so: the `namid.launcher_id` and `versionId` in the metadata let any client verify the lineage independently. A resolver that cannot produce chain evidence refuses rather than guesses. - Address confusion. `did:namid:xch1…` is invalid by grammar. - Network confusion. Mainnet omits the network segment; every other network names itself; a resolver answers only for the network it serves. - Sanctions. Root allocation refuses labels on the protocol's OFAC-derived exact-name list (`blocked-ofac.tsv`, whitepaper §7 ). - Denial of service. Resolution is a read of a local index plus optional chain verification; the registry rate-limits per client address behind nginx. ### 7. Privacy considerations - A DID document contains only what the holder chose to publish as records (address, profile display, website, DNS). Rich records marked sensitive by the kind taxonomy (`/api/records/kinds`) are anchored by hash and never served in a document. - The name form makes a DID human-readable by design; a holder who wants an unlinkable identifier should not use a NamID name as one. The launcher form is pseudonymous but stable, and links every update of the same coin. - The resolver does not log the caller beyond what rate limiting needs. - Holders can correlate across services by choice (`alsoKnownAs`), never by default. ### 8. Relationship to other identifiers form | what it is | in the document `did:namid:…` | this method; canonical DID of a NamID | `id` `namid:1…` / `namid:yourname.x` | the protocol's URI scheme (not a DID) | `alsoKnownAs` `did:chia:1…` | the Chia-ecosystem spelling of the same launcher; not a registered method | `alsoKnownAs` `tld:1…` | protocol-internal view | `alsoKnownAs` `did:key:…` / `did:chia:…` of the holder | who the name is bound to | `controller` ### 9. Profiles, and NFTs under a name A DID document is what a wallet reads. A profile is the same subject as a person reads it, and this method defines one so that every venue renders a NamID the same way instead of inventing a face from the record. ``` GET /api/profile?name=yourname.x (or ?did=did:namid:…, either spelling) GET /api/profile?holder=did:chia:1… the NAME behind an owner DID — the reverse lookup GET /api/profile/card?name=yourname.x the small form a venue shows beside an owner ``` The `holder` form is the one a marketplace needs: it has an NFT's owner DID and wants to show a name. The forward direction alone left every venue matching strings by hand. The reply carries the identifiers of §3, the holder (`controller`), the payment address, the lock and the issuer, `holdings` (other names the same identity holds, from the registry; NFTs from a chain indexer when one answers), the full `document` and `documentMetadata`, and a `display` block — `title`, `avatar`, `bio`, `self_attested: true`. `display` is self-attested: the holder wrote it. A conforming venue renders it as the holder's words and never as a badge of its own. namid.net/p/ is the canonical human page, and one reference badge file is served by every venue so a name looks identical wherever it appears. #### NFTs under a name There is no separate “profile NFT” and nothing extra to mint: a NamID is the DID. An NFT minted by a holder binds to the name two ways, and a venue must check rather than read: - On chain — the NFT1 coin's owner DID is the holder's `did:chia:1…`, which is this document's `controller`. - Off chain — the metadata carries `"namid": "yourname.x"` and `"did_namid": "did:namid:…:1…"`, so a venue holding only the metadata can still resolve the name. The claim holds when the NFT's owner DID equals the name's `controller`, or equals the name's own DID. Anything else is an unverified claim and must be shown as a claim, or not at all. The check lives in three places on purpose — registry, venue adapter and browser badge — because whoever prints the badge must be able to derive it. ### 10. Conformance An implementation conforms if it produces documents and resolution results as in §4–§5 for every valid identifier in §3, refuses every invalid one with `invalidDid`, and never answers a resolution it cannot tie to the chain. The reference implementation's test suite (`tests/test_did_namid.py`, `tests/test_namid_uri.py`) is the conformance vector set. # Whitepaper — the NamID protocol specification Source: ← namid.net · NamID Protocol Whitepaper · v1.5.1 draft · 2026-10-20Download PDF ## NamID Protocol — specification Status: v1.5.1 draft · 2026-10-20 (v1.5: 2026-10-19 · v1.4: 2026-10-19 · v1.3: 2026-10-12 · v1.2: 2026-10-11 · v1.1: 2026-10-10 · v1.0: 2026-07-19; what changed: §20) Scope: this document specifies the NamID Protocol and nothing else: the name primitive, the allocation of roots, on-chain registrars, sealed sets, records, resolution, and the protocol-level mechanisms for identity, agents, payment and addressing. Applications, services and deployments built on the Protocol are out of scope. Rule: every mechanic cites the configuration constant, module or puzzle that implements it, so that the specification and the code cannot silently diverge. Where policy has not been decided, §19 says so; nothing is invented here. Audit status: no puzzle described in this document has been independently audited. Every mechanic runs on Chia testnet11; none is used on mainnet before an independent audit. ### 1. Abstract The Protocol allocates, binds, resolves and records human-readable names on the Chia blockchain. It has no protocol token: bids, prices, renewals, fees and settlements are paid in XCH. A name is a Chia singleton coin, its deed. The deed's puzzle carries the name string, the owner's key, the lock policy and `DATA_ROOT`, the root hash of the name's records. The name is the on-chain object: anyone with a Chia node can walk the deed's lineage from its launcher to the unspent tip and learn, with consensus-grade certainty, who controls the name and what it commits to. Top-level names ( roots, also called TLDs) are released on a public, hash-determined schedule and allocated by sealed-bid second-price auctions. Under each root an on-chain registrar — a sorted linked list of coins — records which second-level names exist, which deed or key controls each, and the terms its root owner set. Uniqueness is enforced by consensus, not by a server. Records live off chain and are proved against `DATA_ROOT`. A conforming client resolves a name from a Chia full node alone and refuses any answer it cannot verify. On this primitive the Protocol specifies a DID method (`did:namid`), agent cards and spending budgets, payment to a name, payment channels between names, and the publication of keys used to address mail and calls to a name — each strictly as an on-chain or cryptographic mechanism. Three properties define the design: - Readable. Labels are plain lowercase letters and digits (§3.1); a second-level name reads like the web (`yourname.x`). - Decentralized. Roots are allocated by sealed-bid auction paid in XCH (§5) on a schedule anyone can compute (§4); second-level names are written by registrar puzzles that every Chia node enforces (§8). No emission, no token, no exchange dependency. - Verifiable. Every answer a resolver gives is backed by an on-chain proof or refused (§11). Key loss is survivable through delayed, cancellable rotation (§3.5); a root is lost only by letting its lease lapse (§6). ### 2. Conventions and terminology #### 2.1 Requirement words The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT and MAY are to be interpreted as described in RFC 2119 and RFC 8174 when, and only when, they appear in bold capitals. §18 collects the conformance requirements. #### 2.2 Terms Term | Meaning root (TLD) | a top-level name such as `x`; one deed coin; allocated under §4–§7 name (SLD) | a second-level name such as `yourname.x`, issued under a root through that root's registrar (§8) label | one dot-free component of a name (§3.1) deed | the singleton coin that is a name's identity (§3.2) launcher id | the coin id of a singleton's launcher; the deed's permanent identifier and its DID id root owner | the holder of the key that controls a root's deed registrar | the on-chain sorted list of a root's names, with the terms that govern them (§8) generation | one registrar instance; its `TERMS` are fixed for its life (§8.7) `TERMS` | the constants curried into every node of one registrar generation (§8.4) `DATA_ROOT` | the 32-byte commitment to a name's records, carried in its deed (§3.4) sealed set | an immutable on-chain commitment to a set of names that predate a root's registrar (§9) client | software that resolves, verifies, builds or signs Protocol data on a user's behalf root profile | a root owner's published rules for names under the root (§16.4) #### 2.3 Networks and clocks The Protocol runs on Chia mainnet and on testnet11. Values marked testnet11 are rehearsal values. Durations enforced by puzzles are counted in blocks, not seconds, wherever a puzzle can express them: a height is a fact, a timestamp is farmer-influenced. Chia targets 4608 blocks per day (`BLOCKS_PER_DAY`, `name_terms.py` and `key_roles.py`). Auction windows and leases are measured in days by the auction engine (§5, §6). Rehearsal modes compress clocks (`network_profile.py`) but never change a bucketing function, a hash or a puzzle. #### 2.4 Citations Configuration constants are in `apps/namid/config.py` unless another module is named. Puzzle paths are relative to `primitives/all-kinds-of-nft/puzzles/`. Registry modules are in `apps/NalandaX/registry-Backend-artefacts/`. The chain-only reference client is `packages/namid-open/` (`namid_open.py`, `namid_sealed.py`, `namid-open.mjs`). ### 3. The name primitive #### 3.1 Label grammar The label grammar is defined once, in `standards/namid-label-grammar.json` (version 1): - a label matches `^[a-z0-9]+$`, 1 to 63 characters; - input is lowercased and surrounding whitespace is trimmed before checking; the result is the canonical form; - the separator is `.`; a name has at most 4 labels; - hyphens, punycode (`xn--`), non-ASCII characters and symbols are refused. The restriction removes whole classes of failure: there is no second spelling of a label to normalise, and no confusable script. Every implementation MUST reproduce the vectors in that file exactly, including the stated reason for each refusal. Widening the grammar is a governance decision (§16), never a drift. #### 3.2 The deed A name's identity is a singleton coin (singleton top layer v1.1) whose inner puzzle is Chia's standard DID layer (`did_innerpuz`), and whose DID inner puzzle is the NamID covenant `did-deed/namid_deed_did.clsp`: ``` singleton_top_layer_v1_1( (SINGLETON_MOD_HASH . (LAUNCHER_ID . LAUNCHER_PH)), did_innerpuz( COVENANT, RECOVERY_DID_LIST_HASH, N, SINGLETON_STRUCT, METADATA ) ) ``` Every deed is therefore a standard Chia DID whose DID id is its launcher id, readable by any Chia DID tool. The covenant curries nine fields into every generation of the coin: Curried field | Meaning `MOD_HASH` | tree hash of the uncurried covenant (self-reference) `NAME` | the full name, e.g. `yourname.x`; immutable `OWNER_PUBKEY` | the 48-byte BLS key that signs every owner action; rotatable (§3.5) `LOCK_FOREVER` | 1 = soulbound: the deed never changes holder (§3.3) `UNLOCK_HEIGHT` | no transfer before this height (0 = none) `DATA_ROOT` | the commitment to the name's records (§3.4) `PENDING_KEY` | `()` or the announced next key of a rotation in flight `READY_HEIGHT` | the height from which a pending rotation may be finished (0 when none) `ROTATION_DELAY` | blocks a rotation must wait; 0 = rotation off; immutable The DID layer runs its inner puzzle with the solution only, so the covenant cannot read the DID layer's curried values directly. The solution carries them and the covenant proves them by asserting `ASSERT_MY_PUZZLEHASH` against the singleton it would form. The covenant also asserts `ASSERT_MY_AMOUNT`, so a deed can never be melted. Actions. Every action except `finalize` is signed by `OWNER_PUBKEY` with `AGG_SIG_ME` over `sha256tree(NAME action args)`. Action | Arguments | Effect `update` | new `DATA_ROOT` | commits a new records root `transfer` | new 48-byte owner key | refused when `LOCK_FOREVER = 1`; gated by `ASSERT_HEIGHT_ABSOLUTE UNLOCK_HEIGHT`; clears a pending rotation and turns DID recovery off `lock` | `(new_lock_forever . new_unlock_height)` | only tightens: soulbound is terminal and a time lock only moves forward; turns DID recovery off `rotate` | `(new_key . ready)` | §3.5 `cancel` | — | discards a pending rotation `finalize` | — | installs the pending key at `READY_HEIGHT`; no signature `recovery` | `(recovery_list_hash . n)` | `n = 0` is always allowed; `n > 0` is refused when soulbound and waits for `UNLOCK_HEIGHT` `metadata` | the DID metadata list | its first pair MUST be `("aka" . NAME)`, so a deed for one name can never read as another in a plain DID wallet `announce` | a 32-byte message | `CREATE_PUZZLE_ANNOUNCEMENT` from the deed (used when an NFT is assigned to the DID); 32 bytes only A DID recovery performed by software that does not know the covenant leaves the deed frozen: its inner puzzle is no longer the covenant, so no registrar node accepts it (§8.5) until the holder repairs it back into the covenant. #### 3.3 Lock policies Exactly one lock mode applies to a coin: Mode | Curry | Use `transferable` | `LOCK_FOREVER = 0`, `UNLOCK_HEIGHT = 0` | may change holder at any time `timelock(H)` | `LOCK_FOREVER = 0`, `UNLOCK_HEIGHT = H` | may change holder from height H `soulbound` | `LOCK_FOREVER = 1` | never changes holder; roots won at auction mint this way (§5.4) Rotation is not transfer. Soulbound forbids a change of holder, not a change of key: a soulbound deed still rotates (§3.5). The chain cannot tell "I rotated to my own new key" from "I handed my key to a buyer"; both are the same edit and no puzzle reads intent. What `LOCK_FOREVER` enforces is narrower and true: `NAME` is re-curried into every generation and never changes, `transfer` is refused outright, and every key change is public for the rotation delay and cancellable throughout. A stolen key therefore cannot quietly become the owner. Locked roots. A root whose deed is locked soulbound issues only soulbound names: the issuance gate refuses `timelock` and `transferable` under it (`subtld_register.owner_default` and `root_vault_locked`; the answer a client reads is the asset-status record, format `namid-asset-status/1`, `standards/NAMID-ASSET-STATUS.md`, computed by `asset_status.py`, the same logic the gate calls). Unknown values are reported as `null`, never guessed; a coin that disagrees with its root's rule is reported as the coin says, with `consistent: false`. #### 3.4 DATA_ROOT `DATA_ROOT` is one 32-byte value that binds a name to its records (§10). It takes one of two forms: - A DataLayer root. The root hash of the name's DataLayer store (binding modes `root` and `store`, `standards/dig-integration.md`; `DataRootBinding` in `standards/dig-transport.ts`). Leaves and internal nodes hash as Chia DataLayer does (§10.3). - A records fingerprint. The sha256 of the name's canonical JSON records document. A client verifies a document obtained from anywhere by hashing it (`namid_open.py verify-records`). `DATA_ROOT` changes only through the deed's `update` action, signed by the owner key. Each change creates a new deed generation, so the deed's lineage is the complete, ordered history of its record commitments. #### 3.5 Key rotation and the clawback window Every change of a name's controlling key is announced, delayed and cancellable. A single spend can never move control. DID deeds (`namid_deed_did.clsp`): Step | Who | Consensus condition | Effect `rotate` | the current key and the new key sign | `ROTATION_DELAY > 0`; the new key is 48 bytes and differs from the current one; the spend lands only while `now ≤ ready − ROTATION_DELAY` | parks the new key in `PENDING_KEY` with `READY_HEIGHT = ready`; replaces any pending rotation `cancel` | the current key | a rotation is pending; no time bound | clears `PENDING_KEY` `finalize` | anyone | `ASSERT_HEIGHT_ABSOLUTE READY_HEIGHT` | the pending key becomes `OWNER_PUBKEY` `ROTATION_DELAY` is curried at mint (`DID_ROTATION_DELAY`, `records_chain.py`): 9216 blocks (two days) on mainnet, 96 blocks on testnet11. The new key signs the announcement so that a name can never be rotated to a key nobody holds; `finalize` needs no signature so that a rotation can never be stranded by a key that has gone quiet; `cancel` has no time bound so that an owner can act the moment they notice. Root deeds of the earlier form (`namid_tld`, with the covenant `ownership-lock/namid_tld_clawback.clsp`) follow the same three-phase rule with a relative clock: `rotate` or `transfer` parks the incoming key in `PENDING_OWNER` and leaves `OWNER_PUBKEY` unchanged; `finalize` is permissionless after `ASSERT_HEIGHT_RELATIVE CLAWBACK_BLOCKS`; `cancel` by the current key has no time bound. `CLAWBACK_BLOCKS = 9216`, measured from the pending coin's own confirmation height; `tld_clawback.py` and `src/lib/clawback.ts` mirror the constant, each with a drift check that reads the `.clsp`. A second change while one is pending is refused, so it is never ambiguous which change the window covers. Why. A stolen key must not be a silent, instant, complete takeover. Under this rule a thief holding the key must announce the change publicly and wait; the owner cancels with the key they still hold. A full node rejects a `finalize` that arrives early: the protection is consensus, not a registrar's restraint. Limitation. If a key is genuinely compromised, both parties hold "the current key", and each can cancel the other's rotation: a stalemate in which nobody rotates while it lasts. The window guarantees that no takeover is silent or fast; settling a contested key needs a separate recovery key (§19). #### 3.6 Identifiers: did:namid Every deed is addressable as a DID under the `did:namid` method (`standards/DID-NAMID-METHOD.md`, reference implementation `did_namid.py`): ``` did-namid = "did:namid:" [ network ":" ] id network = 1*16( %x61-7A / DIGIT ) ; omitted on mainnet id = launcher-id / name launcher-id = "1" 1*bech32-char ; bech32m, checksum over the hrp "namid:" ``` - The launcher form, `did:namid:1…` (mainnet) or `did:namid:testnet11:1…`, is the canonical DID of a minted name; it never changes for the life of the coin lineage. Its bech32m payload is the 32-byte launcher id, so `did:namid:1…` and the protocol URI `namid:1…` share one checksum. - The name form, `did:namid:yourname.x`, resolves to the same document and is an `equivalentId` of the launcher form once the coin exists. - Identifiers are lowercase; uppercase is invalid, not normalised. `did:namid:mainnet:…` is invalid. An id that matches a Chia address (`^t?xch1…`) is invalid by grammar. - The DID document lists `did:chia:1…` and `namid:1…` for the same 32 bytes under `alsoKnownAs`. #### 3.7 Deed forms and puzzle spines Form | Puzzle | Status DID deed | `did-deed/namid_deed_did.clsp` | every new name, and every root won at auction since 2026-10-17 boot eve | `did-deed/namid_deed_did_boot.clsp` | the first coin of an auction-minted deed; proves its own launcher id and becomes the DID deed (§5.4) root deed, earlier form | `namid_tld` and its `_tiers` / `_recoverable` variants | roots bid before 2026-10-17; still valid; followed by registrars from v4 on (§8.5) passkey deed | `did-deed/namid_deed_did_phone.clsp` | a DID deed whose owner is a 33-byte secp256r1 passkey key, verified inside the puzzle; recovery waits a public window the passkey can cancel; accepted only by registrar v7, a draft (§8.8) Verifiers recognise exactly two puzzle spines: v1 classic (`sha256tree` as a Chialisp function; live on testnet11) and v2 opcode (native `sha256tree`, CHIP-0049; staged, fork-gated, build flag off). One spine per coin, forever: migration is a new mint, never a mutation. Pinned mod hashes: `standards/SPINE-VERSIONS.md`. ### 4. Roots: the release schedule New roots enter circulation over a deterministic window of `RELEASE_WINDOW_WEEKS = 260` weeks (five years) from `RELEASE_EPOCH_ISO` (`2026-03-03T00:00:00Z`; environment `NAMID_RELEASE_EPOCH`). Every root's release week is a public hash: computable by anyone, gameable by no one. The bucketing function has a single implementation (`schedule.py`, `release_week_v2`): ``` week(name) = int.from_bytes( sha256( SEED ‖ 0x00 ‖ utf8(name) )[0:8], big-endian ) mod 260 SEED = RELEASE_SEED_V2 (21 ASCII bytes, hex 68616e647368616b65642d72656c656173652d7632) ``` `RELEASE_SEED_V2` is frozen schedule identity: changing one byte reshuffles every root's week, so it changes only by a deliberate, signed governance decision (§16). Clients MUST use the seed bytes exactly as given. Migration (`GRANDFATHER_V1_LIVE = true`). Roots already auction-live under the earlier 156-week v1 schedule (FNV-1a, seed `tld-rollout-v1`) remain released; the v2 schedule governs every root not yet released. From week to auction. - When a root's release week arrives it becomes queued. - Interested parties join its interest queue, first come first served. - Each day the next `DAILY_CAP_N` auctions open from the queue. The cap is derived from the release window, not set independently: `_WEEKLY_SLOTS = 140` per week gives 20 per day (`DAILY_CAP_N_STATUS = "DERIVED-FROM-5Y-WINDOW"`; environment `NAMID_WEEKLY_SLOTS`, `NAMID_DAILY_CAP_N`). - A root not yet at its week can be opened now by EARLY-OPEN (§5.5). - A root whose lease has lapsed re-enters this pipeline immediately (§6.3): its week is long past, so it is queueable and biddable on the same terms as a root never held. ### 5. Roots: sealed-bid auctions Roots are allocated by sealed-bid second-price (Vickrey) auction, paid in XCH. The Protocol has one allocation mechanism; a re-auction after a lapse (§6.3) is the same auction. #### 5.1 Phases Phase | Window | What happens open | — | the auction starts from a queue slot (§4) or by early-open (§5.5) bid | `AUCTION_BID_DAYS` (10 days on the mainnet profile) | sealed bids are placed reveal | `AUCTION_REVEAL_DAYS` (5 days) | bidders reveal on chain settle | after the reveal window closes | the winner pays the second price; the root is minted (§5.4) The 2:1 bid-to-reveal ratio is preserved in every rehearsal mode, so a compressed clock rehearses the same mechanism. #### 5.2 Sealed bids A bid is a real amount plus an optional blind. The deposit (real + blind) is a sealed-bid coin, `tldbase_bid_v5c.clsp`, whose puzzle commits to `sha256tree(TLD, real, salt)`; one puzzle serves every amount. The commitment is made in the bidder's own wallet: the salt is derived from the wallet's signature, the auction service receives only the commitment and the deposit total (intent `namid-auction-bid-v2`), and the real amount is sealed to a key that only the bidder's wallet can re-derive. Nobody, the auction service included, can read a real amount before its bidder reveals it. - The real amount MAY be 0: a blind alone makes a valid, non-zero deposit that can never win below the reserve. - The minimum applies to the deposit (`NAMID_MIN_BASE_XCH`, `price_floor.py`). - Every bid is a separate bid. One wallet may place several on the same root (``, `~2` … `~99`), each with its own coin, reveal and refund, all signed by the key of the wallet's first bid. - A bid deposit carries no memo (§13.3): nothing on chain says that a coin is a bid, for which root, or for how much, before the reveal. - Deposits made before 2026-10-11 keep `tldbase_bid_v5.clsp` or `tldbase_bid_v5b.clsp`. #### 5.3 Reveal, refund and burn A bidder reveals on chain during the reveal window by spending its own deposit through the reveal path. The real amount moves into a per-bid escrow covenant (`tldbase_escrow_v4`) that can only pay the treasury or refund that exact bidder; the blind returns in the same spend; a revealed 0 creates no escrow coin. An unrevealed bid is no bid. Nobody can know its real amount, so it neither wins, nor sets the price, nor is refunded. From close, anyone may spend the deposit to a burn address, and the coin itself requires the burn: at most 0.001 XCH of it may be left to the farmer as a fee. It never returns to the bidder and the auction service can never take it. #### 5.4 Settlement and the minted deed The highest revealed real bid wins and pays the second price: the second-highest revealed bid, whoever placed it (a bidder's own second bid can set its price). A single revealed bid pays the reserve, `RESERVE_PRICE_XCH`, whose floor is 10 USD per root, paid in XCH (`NAMID_BASE_PRICE_USD = 10`, a governance dial, converted at the XCH/USD rate by `price_floor.py`; a feed outage converts at a deliberately low fallback rate so that it can only over-charge). The difference refunds to the winner and revealed losers refund in full, in one transaction with the mint. A win mints a DID-wrapped, soulbound deed, by protocol. At bid time every escrow curries `MINT_INNER_HASH`, the inner puzzle the winner's singleton must have. For every new bid it is the boot eve `namid_deed_did_boot.clsp`, which cannot know its launcher id at bid time and therefore proves its own launcher id when spent and becomes the deed. At settlement the escrow asserts that its launcher child is the singleton of exactly that boot eve, and the same bundle spends the boot eve, with no signature, into ``` singleton(launcher, did_innerpuz(namid_deed_did(NAME, OWNER_PUBKEY, LOCK_FOREVER = 1, …), no recovery, ("aka" . NAME))) ``` — a standard Chia DID whose id is the launcher id, soulbound, with key rotation behind `ROTATION_DELAY`. Escrow, launcher and boot eve are spent in one block. There is no switch: `NEW_BID_DEED = "did"` (`auction_atomic.py`) is a protocol constant, and no environment variable or configuration selects another deed for a new bid. A bid placed before 2026-10-17 committed to the earlier `namid_tld` deed and settles exactly as it was funded (`deed_of()` reads a record without a `deed` field as `tld`). A reader verifies the mint on chain (`auction_roots.verify`): the record coin is the boot eve for this root, owner and lock; the launcher's parent is this root's escrow, spent in the same block; and the escrow committed to that boot eve. #### 5.5 EARLY-OPEN Any party may open a root's auction before its release week by paying, in XCH, in place of a regular open: ``` early_open_xch = EARLY_OPEN_MULTIPLIER × reserve price (EARLY_OPEN_MULTIPLIER = 10) ``` - The payment goes to the treasury, like any sale (§16.1). - Early-open bypasses the interest queue (`EARLY_OPEN_BYPASSES_QUEUE = true`) and does not consume a daily slot (`EARLY_OPEN_CONSUMES_DAILY_SLOT = false`): the payment is the throttle. - The opener gains no bidding advantage: the payment only starts the clock, and the opener bids like anyone else. #### 5.6 Unsigned drafts Every chain-touching response from an auction or registry service is an unsigned draft with a human-readable summary. Only the holder's wallet signs, after approval; a service never holds a user's keys, and nothing in a draft path can transmit a transaction. ### 6. Roots: lease, renewal and lapse #### 6.1 The lease A root is held by a services lease of `LEASE_YEARS = 3` (`LEASE_DAYS = 1095` on mainnet) that opens at settlement. While it runs, the binding of the root to its deed is absolute: no registrar, governance body or operator can take it. The boundary is a covenant, not a promise. The lease is its own singleton, `namid_tld_lease.clsp`, and its two actions are gated by consensus time bounds: Action | Time gate | Authorization `renew` | `ASSERT_BEFORE_SECONDS_ABSOLUTE(TERM_END + GRACE)` | none: permissionless; proof of payment is an `ASSERT_PUZZLE_ANNOUNCEMENT` from the root's renewal escrow (§6.2) `close` | `ASSERT_SECONDS_ABSOLUTE(TERM_END)` | `REGISTRAR_PK`, signed over `(TLD, DID_ID, "close", TERM_END)` Consequences (verified against the mempool, `test_namid_tld_lease_mempool.py`): - No one can take a live root. A `close` before `TERM_END` is consensus-invalid, not merely refused by policy. - No one can refuse a live renewal. `renew` carries no registrar signature. - `GRACE` is the redemption window, honestly expressed. At 0 the two bounds coincide: there is no gap in which a root is neither renewable nor re-allocatable. Above 0 they overlap, and the singleton spends once, so whichever transaction lands first wins. The identity constants (`TLD`, `DID_ID`, `ROOT_LAUNCHER`, price, escrow, registrar key) are re-curried into every generation, so a lease can never be re-pointed at another root, another identity or a lower price. A `close` melts the lease singleton. Any service's store of leases is a mirror of this truth; where the two disagree, the chain is right. #### 6.2 Permissionless renewal Every owned root has one deterministic renewal address: the escrow covenant curried with the root, every spend path bound to the treasury. Anyone may renew any root: paying `N × RENEWAL_PRICE_XCH` extends the lease by N years when the coin confirms. Credits are idempotent per coin; a coin below the price credits nothing. `RENEWAL_PRICE_XCH` is a governance dial (placeholder 0.01 while `PRICING_TBD`, §19). #### 6.3 Lapse and re-allocation When `lease_expiry` passes, the root enters the auction pool at once (`LAPSE_GRACE_DAYS = 0`). - Redemption by the owner only. Until its first re-auction opens, a lapsed root may still be redeemed, but only by its current owner (`LAPSE_REDEEMABLE_UNTIL_AUCTION_OPENS = true`, `LAPSE_REDEEM_OWNER_ONLY = true`): by the owner's own deed spend, or by the owner's key signing a claim for a renewal payment made after the lapse. A payment confirmed before the lapse counts like any renewal. - Renewal stops at the auction bell. Once a re-auction opens, renewal is closed for everyone, the owner included; an unclaimed payment is recorded as late at the renewal address, and the auction decides the root. - Fresh mint, fresh identity. The winner of a re-auction receives a new singleton with a new launcher id: generation N+1, with nothing carried over — not the records, not the DID. The lapsed coin, being soulbound, can never transfer; it persists on chain with no standing and is kept in the root's history. The lease is the property right and the coin is the identity: neglect returns the namespace to the commons, and never hands an identity to a stranger. ### 7. Reserved roots and allocation classes Not every root is publicly auctioned. Each label belongs to at most one class below; the classes are disjoint, and every overlap with the ICANN or sanctions lists is written down with its winner (`roots.PINNED_OVERLAPS`, enforced by `apps/namid/tests/test_one_reservation_per_label.py`). Class | Members | Rule (a) Governance-held roots | the single characters `a`–`z` and `0`–`9` not in class (d), and the utility roots `.tld`, `.did`, `.dao`, `.admin`, `.root`, `.null`, `.strict`, `.us`, `.india`, `.bharat`, `.usa` | held as governance treasury assets; allocation only by governance proposal (`SINGLE_LETTER_DAO_GATED = true`); no operator can allocate them unilaterally (b) Registrable-domain gifts | the first 10,000 eligible labels of `standards/reserved-popular-sites.tsv` (a dated DNS-request ranking), less labels another class holds (declared in the snapshot header) | held for the operators of the corresponding registrable domains. A claimant publishes a one-time challenge in a fully DNSSEC-validated apex TXT RRset; the proof binds the root and the recipient puzzle hash and rejects CNAME and wildcard substitution. A valid proof only makes a governance allocation proposal eligible; it does not mint or bypass quorum (c) ICANN root-zone strings | the live IANA root zone, snapshot `standards/reserved-icann.txt`, loaded fail-closed by `config.reserved_icann()` | reserved; never publicly auctioned, never gifted. The Protocol never squats the legacy DNS root (d) Root-owner service and brand roots | roots a root owner operates for typed services and never auctions (`roots.SERVICE_ROOTS`; for example `.x`, `.nm`, `.ids`, `.mojo`, `.chia`), and roots held for brand protection under which no names are issued | service roots issue names under their root profile (§16.4); a brand root refuses every issuance (`brand-root`) (e) Sanctions exact-name screen | `standards/blocked-ofac.tsv`, generated from the official SDN and consolidated lists (primary names and strong aliases) | an exact normalisation into the label alphabet is refused before allocation. This is a conservative namespace screen: not fuzzy matching, not sanctions compliance, not KYC. It fails closed when the pinned file is unavailable (f) Participant gift reservations | `roots.CHIA_ECOSYSTEM_GIFTS` | held by the treasury for possible good-faith gifts. A reservation proves no identity, creates no entitlement and promises no allocation; the treasury verifies the intended recipient before any transfer Precedence when a label appears in several sources: grammar, then the sanctions screen, then service-root policy, then the governance hold, then the ICANN lock. Overlap counts are published with the reserve lists. ### 8. Registrars Every root that issues names has an on-chain registrar: the list of its names, kept by a Chialisp puzzle that every Chia node enforces. A name is registered only when it is on chain in its own coin; a list, commitment or reservation held off chain reserves nothing, and an unminted label is free for anyone. #### 8.1 Structure A registrar is one coin per name, kept in a sorted linked list that starts at the root's genesis head. Each node curries: ``` MOD_HASH REGISTRY_ID TERMS VALUE OWNER STORE EXPIRY NEXT_VALUE NEXT_ID [ROTATION] [RANGE] genesis head: VALUE = "" OWNER = 0 STORE = 0 EXPIRY = 0 NEXT_VALUE = 0xff…ff (32 bytes) NEXT_ID = 0 ``` Field | Meaning `REGISTRY_ID` | the root's deed launcher id; every node coin is hinted with it, so one hint query lists the whole registrar `VALUE` | the label bytes `OWNER` | a 48-byte BLS key, or a 32-byte deed launcher id (§8.5) `STORE` | the DataLayer store id of the name's records (0 = none) `EXPIRY` | height at which the name lapses (0 = never) `NEXT_VALUE`, `NEXT_ID` | the successor's label and coin `ROTATION` | `()` or `(new_key . ready_height)`, a key change in flight (from v2) `RANGE` | `()`, or an interval (§8.6) (from v6) #### 8.2 Uniqueness and recognition An insert is accepted only inside its predecessor's gap: `VALUE 0` is an interval head (`VALUE = lo`, `OWNER = AUTH`, `STORE` = a commitment root). An insert whose predecessor carries a `RANGE` and whose label is below `HI` lands inside the interval: only `AUTH` may make it (`AGG_SIG_ME AUTH` over `("inside" label owner store expiry)`), no `PRICE` is paid again, and the new node inherits `(HI AUTH 0)`, so the gap after it stays guarded. An interval is created by mode 8 only from a predecessor whose gap holds all of `[lo, hi)`, never inside another interval; `RANGE_KEY` and `auth` both sign, and `PRICE × count` is paid. An interval head renews at `PRICE × COUNT`, never changes owner and never rotates; a lapsed head may be taken over and becomes a plain name. Two registrar modes follow (`mode` in the client manifest, `registrars..json`): - Open registrar. No interval covers the label space: anyone may insert a free label by paying `PRICE`. - Owner-only registrar. One interval covers every label, with `AUTH` = the root owner's key: only the root owner can add names (`open_registrar.py issue`). A root won at auction issues names only through its owner until the owner opens it for registration in the rule book (§16.4). #### 8.7 Generations and conformity `TERMS` are fixed for a registrar's life. A registrar that disagrees with its root's rules is retired, not edited: a new generation is issued with the right terms, its names are written into it, and the retired generation's nodes are kept and shown as history. `namespace_rules.registrar_terms(root)` states what a root's registrar must carry and `conformity()` names every difference; a writer MUST NOT insert into a non-conforming generation. Which generation of a root is current is not a fact the chain can state: the client manifest names it (§11.6). #### 8.8 Registrar versions Version | Change v1 | sorted list, modes 1–4, five terms v2 | key change separate from transfer (modes 5–7, `ROTATION_DELAY`) v3 | fixed node amount (`NODE_AMOUNT`, `ASSERT_MY_AMOUNT`) v4 | deed-bound owners: one key per name v5 | renewal adds a term on top of the current expiry (`MAX_AHEAD`) v6 (current) | the deed is a Chia DID (`DID_INNER_MOD_HASH`, `DEED_MOD_HASH`, `ROOT_NAME`); intervals and owner-only registrars (`RANGE`, `RANGE_KEY`, mode 8) v7 ( draft, not audited) | two switchable terms on top of v6: a passkey-deed term (`PHONE_DEED_MOD_HASH`; `()` = off) under which a deed whose owner key is 33 bytes authorises a node change by announcing the node's message, `ASSERT_PUZZLE_ANNOUNCEMENT sha256(deed puzzle hash, sha256tree(("node" msg)))`; and a sealed-set term (`SEALED`; `()` = off) that enforces §9 in the puzzle The two v7 branches (`register/namid_slot_node_v7.clsp` and `register/namid_slot_node_v7_sealed.clsp`) are being merged into one `TERMS` layout before audit. Until an audited v7 exists, v6 remains the current registrar; v7 runs only in a testnet11 test generation. #### 8.9 Registration in one bundle A name is registered by one spend bundle that launches its DID deed and inserts its node, paid and signed by the buyer's own wallet (`namid_open.py register`). The owner pays every fee of the transaction (§16.5). #### 8.10 Lapse, takeover, and the retirement of the lapsed holder's deed Founder decision, 2026-10-24: "a takeover retires the lapsed owner's deed … it should be the same for both TLD and SLDs." The SLD rules are written as N1–N5 in `NALANDAX-SLD-STANDARD.md`; this section is their protocol statement, and the threat model behind them is `docs/audit/HANDOVER-THREAT-MODEL-2026-10-24.md`. A name is two coins: the registrar node (who holds the label — §8.1) and the deed (the key, `DATA_ROOT`, and through it the payment address, the DNS rows and the TLSA pins — §3, §10). A takeover spends the node. It cannot spend the deed: the deed covenant has no melt path, asserts its own amount so a spend is never −113, and requires `OWNER_PUBKEY`'s signature for every action but `finalize` (§3.2). The protocol therefore defines the retirement in terms of standing, not destruction, and places each half where it can be enforced. - Renewal closes at the lapse. Once `now ≥ EXPIRY` a name MUST NOT be renewed, by its holder or by anyone, and a takeover is the only route. No grace, no owner-only redemption — the same `LAPSE_GRACE_DAYS = 0` rule roots take in §6.3. This is a registrar-and-registry rule, not consensus: mode 2 carries no lapse gate, so on chain a renewal and a takeover of a lapsed node race and the first spend wins. A conforming registrar refuses the renewal; the next slot-node generation should refuse it in the puzzle. - The handover is one settlement. Mode 4 replaces `OWNER` and `STORE` in the same spend, so the registrar's record of who holds the label and its pointer to where the records are can never come apart. A conforming takeover MUST pass `new_store = 0` and MUST NOT pass the lapsed node's own `STORE`: carrying it over would leave the registrar itself blessing the records of a holder who no longer holds the name. The puzzle does not police `new_store`, so this is a builder rule; it is checkable afterwards by anyone, because `STORE` is a curried field of the node on chain. - The old deed's authority ends with the spend, by construction. `owner_auth` recomputes a deed's coin id from the node's `OWNER` (§8.5). A deed that is not the node's owner has no coin that can satisfy `ASSERT_CONCURRENT_SPEND`, so after a takeover the lapsed holder's deed can authorise nothing about the name, whatever it does on chain. This half is consensus. - A registry MUST retire the binding in the same write as the handover. The name's records become empty (kept under `records_retired` for audit, never for answers), the deed binding moves to `chain.deed_retired`, and the record's holder becomes the node's new `OWNER`. The name then reads held, with nothing published, which is the true state; the new holder mints their own deed and binds it (mode 3 BIND) when they choose. - Resolution is withheld, not patched. A lapsed or handed-over name resolves to nothing (§11.1 step 4a, §11.3). Not the previous holder's records, not a holding page. - A 32-byte `new_owner` in mode 4 is unchecked. Unlike BIND and every owner action, mode 4 runs no `deed_fits` and asks for no concurrent spend, so a takeover may point a node at a deed that is not this name's — or at no deed at all, which leaves the node unspendable. A conforming builder MUST refuse a 32-byte `new_owner` it cannot show to be a fresh deed for this name, and MUST refuse the lapsed holder's own launcher. Closing it in the puzzle is open work for the next generation (§19). Roots. The same rule, reached a different way and more completely: a lapsed root is re-auctioned at once and the winner receives a new singleton with a new launcher id — generation N+1, with nothing carried over, not the records and not the DID (§6.3). There is no in-place takeover of a root and so no split state. The limit is identical: the lapsed root coin is soulbound, so it can neither transfer nor melt, and persists on chain with no standing. A resolver takes a root's current generation from the client manifest and the auction's own chain record (§11.6), never from a coin that claims a label. ### 9. Sealed sets A sealed set makes names that exist on chain as deeds, but predate their root's registrar, provable from the chain alone, with one immutable anchor per root. The feature is specified here as it runs on testnet11; it MAY be removed in a later version of the Protocol (§19). Anchors already on chain are unspendable and stay valid whatever is decided. #### 9.1 Leaves A leaf is the CLVM list `(label launcher_id owner_pk data_root)`; the leaf hash is its `sha256tree`. These are exactly the fields that, with the launcher id, determine the name's eve deed coin (`deed_eve_id(name, launcher, owner, data_root)`: the coin id of the soulbound DID deed minted with those values, amount 1). If that coin exists on chain, that launcher minted that name with that key: one coin lookup makes a leaf true, not merely committed. `data_root` is the `DATA_ROOT` at mint; later record updates live in the deed's lineage. #### 9.2 Tree and proofs Leaves are sorted strictly increasing by label bytes (the registrar's own order) and padded with `()` to `2^depth`. An internal node is `sha256(0x02 ‖ left ‖ right)`, so the Merkle root is the `sha256tree` of a CLVM tree of cons cells, and a Chialisp puzzle checks a path with `(sha256 2 l r)`. - Membership: the leaf, its index and `depth` siblings. - Non-membership: the two adjacent leaves (indices i and i + 1) with `left < label < right`; or the first leaf alone when `label < first`; or the last alone when `label > last`. An empty set proves every label absent. This is the registrar's strict-gap rule applied to the set. #### 9.3 Anchor The anchor is a 1-mojo coin whose puzzle is `(x)` (mod hash `044ebff3ad6d351856fd37d38c599ad0e416aa8a22621d8c13c27e24561f7f77`) curried with ``` ("namid-sealed-set/1" root registry_id merkle_root count leaf_file_sha256) ``` `(x)` raises for every solution, so the coin can never be spent, moved, melted or changed, by anyone. Its puzzle hash commits to all six fields; a client recomputes it and reads the coin. The anchor is found by the hint `sha256("namid-sealed-set/1:" ‖ registry_id)` and authenticated by the client manifest, exactly like a registrar's genesis head. The leaf file is content-addressed by the sha256 the anchor commits to: any copy that hashes correctly is the file, wherever it was fetched from (`namid_sealed.fetch_leaf_file`). #### 9.4 Enforcement - Registrar v6: resolver-enforced. A label in a root's sealed set belongs to the sealed name. A free label is one absent from the registrar list (gap) and from the sealed set (non-membership proof). If a registrar node for a sealed label has the same deed, both agree; if it has another owner, resolvers follow the sealed entry, committed first, and report a `collision` (§11.3). The v6 puzzle cannot see the set, so it cannot refuse such an insert itself. - Registrar v7 (draft): puzzle-enforced when its `SEALED` term is set to `(SEALED_ROOT SEALED_COUNT SEALED_DEPTH SEALED_ANCHOR_ID)`. Every insert carries a non-membership proof for its label (inside an interval too); a reservation proves that no sealed label lies in `[lo, hi)`; and a new mode 9, claim, moves a sealed name into the list: the leaf is proved a member, the new node's owner is its deed, the deed's current coin is spent alongside and its key signs `("claim" label new_store new_expiry)`. A claim pays no `PRICE`: the claim price is 0 under the current terms. A label in the set has no non-membership proof, so it can never be inserted by anyone else. ### 9A. Subname sets — many names under one registered SLD A subname set does for the names beneath an SLD what a sealed set (§9) does for the names that predate a registrar: it makes an unbounded number of names provable from the chain alone against one unspendable anchor coin per publish. It is specified here as it runs on testnet11, and needs no new puzzle. Normative rules and their enforcement: `standards/NALANDAX-SLD-STANDARD.md` §Subnames (S1–S7); design and costs: `docs/NX-SUBNAMES-2026-10-25.md`. Displayed in products as the NX standard. #### 9A.1 What is named A name of three or four labels (`ag1.mayank.mojo`, `a.ag1.mayank.mojo`) is never a registrar node. It is a leaf in the set of its second-level name, and a conformant client MUST NOT register, nor accept a registration of, a name with more than two labels (§3's grammar already caps a name at four labels). #### 9A.2 Leaves, tree and proofs A leaf is the CLVM list `(path owner_pk pay_ph doc_hash flags)`, `path` being the labels below the SLD; the leaf hash is its `sha256tree`. `owner_pk` is the 48-byte key the subname signs as — its own, where the holder chose one — `pay_ph` is where payments to it go (32 zero bytes meaning "the parent's address"), and `doc_hash` is the sha256 of the subname's canonical document: its agent card (§12) and its records (§10) together, so everything it serves is committed on chain. The tree, the sorting, the padding, the node rule and both proof shapes are §9.2 unchanged, which is deliberate: one tree in the Protocol, one verifier, one set of vectors. A leaf whose own parent path is not in the same set is invalid, so the flat set is a real tree. #### 9A.3 Anchor, and the signature that makes it the holder's The anchor is a 1-mojo coin whose puzzle is `(x)` — the same mod hash as §9.3 — curried with ``` ("namid-subname-set/1" parent holder subs_root count file_sha256 seq prev_anchor) ``` `holder` is the parent node's `OWNER` (§8.1), `seq` counts publishes from 1, and `prev_anchor` is the previous anchor's coin id (empty for the first). The hint is `sha256("namid-subname-set/1:" ‖ holder)`. Unlike a sealed set, a subname set grows, so it cannot be authenticated by the client manifest. It is authenticated by the holder: a BLS signature over the CHIP-0002 digest of ``` namid-subname-set/1|||||| ``` carried beside the leaf file (never inside it — the anchor commits to the file's sha256, so a signature written into the file could not be built). A client MUST accept only the anchor with the greatest `seq` whose signature verifies under the key the parent's current node authorises (for a deed-owned node, the key its deed is curried with, checkable with one coin lookup through `deed_eve_id`), with an unbroken `prev` chain. A client SHOULD also count the coins at the holder's hint: each publish creates exactly one, so a count greater than `seq` means the set it was handed is stale and MUST NOT be served. #### 9A.4 Resolution and standing Resolving a subname is: the parent's node (§8), the parent's verdict (§8.10 / §11.1), the anchor coin, the signature, then one membership proof. Two coin lookups and one proof, independent of depth. A subname has no `EXPIRY`, no coin and no transfer of its own: its standing is its parent's, re-read on every answer, so a lapse or a takeover of the parent takes every subname with it in the same spend that moves the label — with no spend of any subname and no cooperation from the former holder. A resolver MUST fail closed on an unreadable anchor, an unverifiable signature, a document that does not hash to its leaf, or a parent that does not bless (§11.3's withheld outcomes, NMPD §12). #### 9A.5 Enforcement, honestly Resolver-enforced, exactly as §9.4's v6 case is: the v6 node puzzle cannot see a subname set. A subname cannot collide with a registrar label (a dotted path is not a valid label), so the collision class §9.4 guards against does not arise; what is not enforced at consensus is "this set is the authority", which would need the v7/v8 registrar's checker term. Migrations are stopped, so that remains open (§19). ### 10. Records #### 10.1 Model A name answers questions through typed key/value records in its store, committed by `DATA_ROOT` (§3.4): one hash on chain, the data off chain, every answer provable against the hash. The record keys (`standards/NAME-RECORDS-SCHEMA.md`, published by `datalayer_view.py`): Key | Value | Meaning `_namid/name` | `yourname.x` | the name, ASCII `_namid/did` | `did:namid:…` | the name's DID (launcher form once minted) `address` | a Chia address | where payments to the name go (§13) `dns//` | JSON `{type, name, data, ttl}` | one DNS resource record; `TYPE` in `dns_records.SUPPORTED` (A, AAAA, CNAME, TXT, MX, NS, DS, SRV, CAA, TLSA, SSHFP, SVCB/HTTPS …) `socials/`, `profile/` | text | handles and display profile (`metadata.SOCIAL_KEYS`) `agent/card` | the canonical JSON of an agent card | §12.3 service record | endpoint, routing keys, X25519 key-agreement key | the keys used to address mail and calls to the name (§15) In a root's shared store every key is prefixed `