did:openpayload:...@example.com.
The deployed spec 123 services accept domain-shaped Personas and single-label names such as compliance. Single-label names do not claim a domain and need no DNS challenge. The DNS flow below is for a domain-shaped Persona.
Single-label names
For a single-label name, prepare a DID-signed registration, sign the returnedcanonical_payload with an operator DID controller key, and submit it. Use action register_named_persona, the operator DID, controller keys, threshold 1, the current operator nonce, and a future valid_until. No DNS step is involved.
The current Directory API does not expose the operator nonce for a first Persona registration. Read that counter from chain state, or use operator_nonce from an existing Persona under the same operator DID. GET /personas/{persona}/nonces returns 404 for an unregistered name.
Persona policies can define routing, archive forks, or other explicit actions. A policy does not itself prove that a recipient belongs to the collective; the Persona operator handles membership outside OpenPayload.
Domain-shaped names
The canonical DNS name is globally unique in chain state. A new registration is rejected when that Persona already exists; an existing Persona must use the renewal or authenticated transfer flow instead.Before you begin
You need:- A canonical DNS name you control.
- An active operator DID.
- An authorized private signing key for that DID.
- Permission to publish a TXT record below the domain.
1. Request a DNS challenge
2. Publish the TXT record
Publish the returned value exactly:3. Verify DNS and prepare the payload
Send the complete unsigned registration intent to the verification endpoint. Use theoperator_nonce returned with the challenge.
canonical_payload for this intent.
4. Sign and submit
Decodecanonical_payload and sign those exact bytes locally with signer_key_id. Submit the full intent again, including the Directory attestation returned by verification, followed by the canonical payload and your signature:
PUT /personas/example.com. 202 Accepted means the request was submitted to the chain. Read the Persona until its revision and verification timestamps reflect finalized state.
Renewal and controller changes
Renew DNS verification beforeverification_expires_at. Choose an explicit future expiration when verifying the intent; it can be at most 90 days away:
- Create a challenge with action
renew_persona. - Publish and verify the new TXT value.
- Sign the returned canonical payload and submit it through
PUT /personas/{persona}.
PUT /personas/{persona}/controllers to change controller keys. Persona v1 requires a threshold of 1; the controller set may contain one through eight operator-DID signing keys, but each update uses one active-controller signature. The signing key must remain in the new set, so key removal is staged: add a replacement, wait for finalization, then use that replacement to authorize removal of the old key.
Transfer to a new operator
An operator transfer requires fresh DNS control plus authorization from both parties:- Create a challenge with
POST /personas/{persona}/transfer/dns-challengesand publish its TXT value. - Verify the complete transfer intent with
POST /personas/{persona}/transfer/dns-challenges/{challenge_id}/verify. - Have the new operator sign the returned
acceptance_payload, then send that signature to the matching/prepareendpoint. - Have a current Persona controller sign the returned
canonical_payload, then submit both signatures withPUT /personas/{persona}/operator.
new_controller_threshold must equal 1. The DNS verification can remain valid for at most 90 days.
Transfer clears the old Persona policy so the previous operator cannot leave routing instructions behind. Publish a new policy after finalization if required. Transfer also replaces Persona-specific delivery constraints; omit delivery_constraints only when the Persona should fall through to DID and network constraints.
Use DELETE /personas/{persona} with action revoke_persona to deactivate it. A revoked or expired Persona cannot win policy resolution.
DNS proof establishes control of the domain at verification time. It does not establish the identity, reputation, or trustworthiness of the organization operating it.

