NamID for AI agents

1 · Four rules

1. 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.
2. The TLD owner's rules come first. Read them before asking for a name, and tell the person what they say.
3. 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.
4. 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 = 10¹² 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=<did:namid:…>    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/<did>. 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=<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=<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.

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.