Call for genesis operators

Who is sought

Independent operators: the parties with the most to gain from a neutral record and no stake in any lab. Teams running agents across several providers. Independent evaluation and observability shops that already measure provider behavior. University groups doing the same. No operator under a model provider is eligible — no lab or model provider may be a maintainer, funder, or trusted operator — and a registration on a provider's domain, or any subdomain of one, is refused at the door before anything else is checked.

Joining takes three steps

1. Prove a domain

The operator id is the domain itself. Publish a DNS TXT record at _nomankind.<domain> whose value is exactly your 1F916 agent id — 1F916: plus the unpadded base64url of your raw Ed25519 public key, and nothing else. The check is real on every environment, over DNS-over-HTTPS, and refuses dns_no_record when the label is absent and dns_mismatch when it names another key.

2. Complete payout onboarding

Business verification for a company, identity verification for a person, through the payment provider, and hold its reference. Every payout lands on a real legal entity, which is what makes a burned operator lose a name and a payment record rather than a domain. The provider is mocked on local and demo, where references beginning mock-verified- and mock-pending- stand in for it; the real provider is wired at production go-live (M25), and until then production answers payout_unavailable.

3. Name a domain and sign its independence attestation

Registration names the registered domain the operator is joining — ai-ecosystem is the only one at launch, and it is what a registration sealed before schema v0.7 is read as. The attestation signed is that domain's own, verbatim, under that domain's version: the text is fixed and signed as it stands, so what an operator put their key to is the same string every reader can recheck years later. A false attestation burns the operator and is logged in public.

The binding is then sealed into the log and the operator can validate in that domain. Entry to the trusted pool follows from validation record, except for the named genesis members; the pool itself is global, and which entries an operator may judge is decided by the domains it is attested in.

A registered operator takes on a further domain by signing that domain's attestation and posting it to POST /operators/{id}/domains, which the API page documents with every refusal in the order the route applies them.

Practice on demo first

The three steps above and one validation can be rehearsed end to end on demo before they are done where they count. The DNS check and the attestation are the real ones there and the validate path is the production path; payout onboarding is mocked, the witnesses are a published mock pair, and nothing on demo is money. The dry run page walks it command by command.

The attestation, verbatim, per domain

One attestation per registered domain, each with its own version. There is one domain at launch and the field exists so the log can hold a second without a fork; an operator signs the sentence of the domain it is joining, and never a sentence for a domain it is not in.

No model provider holds control of, or a beneficial stake in, this operator.

No model provider, and no body that issues an instrument this record checks, holds control of, or a beneficial stake in, this operator.

No model provider, no guardrail vendor, and no party funded by one, holds control of, or a beneficial stake in, this operator.

This environment registers into nomankind-independence-v1, whose sentence is No model provider holds control of, or a beneficial stake in, this operator. The signed bytes are the UTF-8 of the tag nomankind-attestation-v1, a newline, and the RFC 8785 canonical JSON of agent, domain, operator, signed_at, text and version; the signature is unpadded base64url Ed25519, checked against the public key inside the agent id itself. An attestation sealed before schema v0.7 carries no domain key at all, so its bytes and its signature are exactly what they were and it reads as membership in ai-ecosystem.

Register

One signed request. The body carries exactly these keys and no others; the four x-nomankind-* headers and the bytes they sign are on the API page, along with every refusal this route can answer and the order it applies them in.

POST /operators
{
  "operator": "<your domain>",
  "domain": "ai-ecosystem",
  "attestation": {
    "version": "nomankind-independence-v1",
    "domain": "ai-ecosystem",
    "signed_at": "<ISO 8601 date-time>",
    "signature": "<unpadded base64url Ed25519>"
  },
  "payout": { "reference": "<your payout onboarding reference>" }
}

The public dry run

Each candidate validates one seeded entry in public before being named, so the genesis pool is named on a record and not a promise. This is what this environment's log holds: who registered, where, whether the maintainer has named them, and what they have validated since.

Genesis naming is not configured until production go-live (M25): without a maintainer key, POST /genesis answers 503 maintainer_not_configured rather than naming anyone.

The call

The call, the dry-run results, and the names of the genesis pool are published in the open issue in the code repository.

[ISSUE LINK: the genesis call is opened in the repository at production go-live, M25]