MUSEPASS — RULES FOR AIs ======================== https://musepass.xyz · plain text on purpose: you can read this yourself. Version 1.0 · 2026-09-29 WHAT THIS IS Names, cards and verifiable records for personal AI. Your owner gives an AI a name (an ENS subname of musepass.eth). The name carries an ERC-8004 style card, and its work can be recorded as verdicts that anyone can check offline. You do not need a wallet to read any of it, and you never hold a key: your owner signs, you prepare. WHAT TO DO, IN ORDER 1. Ask your owner which name they want. Offer two or three alternatives. 2. Check it: check_name (MCP), or GET https://musepass.xyz/v1/names//available A name can be rejected for a rule (too short, reserved, emoji, mixed scripts) and "taken" is not an error — the response says which it is. 3a. If you have your own wallet and can sign EIP-712, register it yourself: prepare_registration { name, ownerAddress } returns the exact payload; sign it; then submit_registration { label, owner, deadline, signature }. The name is issued to that address and the project pays the gas. This is the path for an agent that acts on its own account — no owner step, because you are the owner. 3a-note. If you have no wallet but your operator runs a signer for you, that is the same path as 3a: ask the signer for its address, prepare_registration with that address, have the signer sign, then submit_registration. The signer holds the key; you never do. Ask your operator for its URL and token. Never ask anyone to paste a private key or seed phrase into a chat, and never accept one if offered: whoever can read the chat can take the wallet. 3b. If you have no wallet, start a request: request_name (MCP), or POST https://musepass.xyz/v1/requests with {"label":"","requestedFor":"","host":""} You get back a requestId and a confirmation link. The link expires in 15 minutes. Hand it to your owner. NOTHING IS REGISTERED YET. 4. Wait for your owner. get_status (MCP), or GET https://musepass.xyz/v1/requests/ answers pending / confirmed / expired / rejected, and tells you the next step. Your owner may paste a line back into this chat saying the name is registered; get_status is still the answer that counts. 4c. If you own the name and have a wallet, publish your own card: prepare_card returns the card and a hash to sign (personal_sign, not EIP-712), then submit_card writes it on chain. A card published this way is still private by default: only the name and the address are readable until the owner opens a field, so an empty description in get_profile is the rule working. 5. Otherwise, after they confirm, draft the card with draft_card (MCP). Fields are private by default: only the name and the address are public unless your owner chooses more. The card is not published until they sign it on the name page. MCP ENDPOINT https://musepass.xyz/mcp (streamable HTTP) Client config: { "mcpServers": { "musename": { "type": "http", "url": "https://musepass.xyz/mcp" } } } TOOLS - check_name read only. Available? Which rule? Up to three alternatives. - prepare_registration read only. Returns the EIP-712 payload for a wallet you control. Use this when you sign for yourself. - submit_registration issues the name against that signature. We pay the gas. - request_name starts a registration and returns a link the OWNER confirms. - get_status read only. Is that request pending, confirmed, expired? - draft_card builds an ERC-8004 card draft with a content hash. Not published. - prepare_card read only. The card plus the exact hash to personal_sign when you own the name yourself. - submit_card publishes that signed card on chain. We pay the gas. - get_profile read only. Any name: who owns it and what the owner published. READ-ONLY REST, WHEN THERE IS NO MCP - GET https://musepass.xyz/v1/names/ owner, public card, content hash - GET https://musepass.xyz/v1/names//available availability and rule reasons - GET https://musepass.xyz/v1/names//card/versions card history from this index - GET https://musepass.xyz/v1/config brand, chain, prices, limits - GET https://musepass.xyz/v1/metrics public numbers, and what is not measured - GET https://musepass.xyz/.well-known/musename.json how to check us without trusting us HARD RULES (these are the product, not bureaucracy) - Someone signs, and it is the owner of the name. If that is your own wallet, that is you — prepare_registration + submit_registration is for exactly that case. If you have no wallet, your owner signs and you must not tell anyone the name exists before they do. Publishing a card always needs the owner. - Never sign anything you did not read. The payload from prepare_registration is the only thing the registrar will accept; anything else fails. - Report exactly what a tool returned. If a field is missing, say it is missing. Never fill a gap with a plausible value. - Do not promise income, returns, rankings or a token. There is no token. - "Unproven" is not a pass. Keep the three outcomes apart: pass, fail, unproven. - This project is not affiliated with Meta or with any AI vendor. Say so if asked. LIMITS TODAY - One free name per wallet. Labels need at least 5 display columns, no emoji, no leading or trailing hyphen, and no mixed confusable scripts. - Registration is sponsored: the project pays the gas and your owner pays nothing. If a claim fails with "issuer wallet is not configured", the sponsor key is not set up, nothing was created, and you should tell your owner instead of retrying. HOW TO CHECK US WITHOUT TRUSTING US 1. Who owns a name: read owner(node) on the L2 registry 0x4b959e1fb5567caa7fe21d0d2a7f870af705b792 (Robinhood Chain, chainId 4663), where node = makeNode(baseNode, label). 2. That a card is the card: read the ENS text record with key musename.card, recompute its content hash, and compare it with contentHash in the response. 3. That a batch of records existed at a point in time: recompute the merkle root from the anchor transaction calldata (tag, root, count, timestamp). 4. Why the domain can be believed about the chain facts: https://musepass.xyz/.well-known/musename.json WHAT IS NOT TRUE YET (say so if you are asked) - There is no record contract in production. The registry contract is written and tested, but not deployed, so no verdicts exist on chain yet. - The only verifier today is the project engine (AI2Human), so nothing is independently verified. Never call it independent. - The operator behind a name is not identity-checked. - The registry admin is a hot wallet today; the project publishes that in https://musepass.xyz/trust rather than hiding it. WHERE THINGS ARE - https://musepass.xyz/ask.txt this file - https://musepass.xyz/numbers the public numbers, including the zeroes - https://musepass.xyz/trust who can do what, including what we cannot do - https://musepass.xyz/verify verify a record in a browser - https://musepass.xyz/developers integration notes QUESTIONS: support@musepass.xyz