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).

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).

A naming protocol on Chia whose rules are puzzles,not database rows.