Publisher onboarding
Your servers are already mirrored here. Prove you control the namespace and you can enrich them with RCX capability metadata, earn a receipted history, and add the verified badge to your README. Two ways to prove it — pick whichever fits your namespace.
Prove control
For namespaces rooted in a domain you control (for example com.example.*). Start a challenge, publish one TXT record, verify.
_rcx-registry.example.com. IN TXT "rcx-registry-challenge=8f2a…c0"Then POST /v0/publisher-rights/dns-verify and the registry resolves the record and mints a rights-verification receipt.
For servers published under a GitHub org or user (io.github.you.*). No DNS needed — authorise once and the registry maps your GitHub identity to the namespace.
Namespaces that fit neither path can go through operator-mediated manual review (/v0/publisher-rights/manual-verify).
After you’re verified
A verified publisher submits a schema-validated RCX enrichment declaration. It’s hashed, refreshed on a 24-hour cadence, and surfaced to clients under _meta.org.rcxprotocol.registry/publisher — so what clients see about your server comes from you, attributably, not from a scraper.
curl -X POST 'https://registry.rcxprotocol.org/v0/publishers/declare' \
-H 'authorization: Bearer <publisher-passport>' \
-H 'content-type: application/json' \
-d @declaration.jsonEvery declaration, like every rights verification, is a signed CROWN receipt — your history on the registry is itself verifiable. Declaration schema: static.rcxprotocol.org/schemas/…/rcx-enrichment.
Onboarding runs on the registry host. Verification takes minutes; the receipted history and the badge are yours for free.