did:key DID before the node accepts a registration or key rotation. The node issues a short-lived challenge — a random nonce — that you sign with your Ed25519 private key. The signed challenge is then included in the registration or rotation request, and the node verifies the signature against the public key encoded in your DID.
When challenges are required
The node operator controls whether challenges are required via theSERVICENET_REQUIRE_PROVIDER_OWNERSHIP_CHALLENGES environment variable. Set it to 1 to enforce challenges, or leave it unset to allow open registration.
If you are connecting to a production or shared node, assume challenges are enforced — node operators may require them regardless of the default setting.
Challenge flow
Fetching a challenge by ID
If you need to inspect an issued challenge — for example, to check itsexpires_at or provider_id — retrieve it by ID:
ProviderOwnershipChallenge object returned when the challenge was created.
Key rotation challenges
The same challenge flow applies when rotating a provider’s DID key. Request a challenge with"operation": "rotate_key" and include the provider_id of the existing provider you are updating:
Challenge request fields
string
required
The Ed25519
did:key DID you want to associate with the provider. For rotate_key operations, this is the new DID you are rotating to.string
required
The operation you intend to complete after signing. Must be
"register" or "rotate_key".string
The provider ID to associate with this challenge. Optional for
register operations — if omitted, the node generates a unique ID. Required for rotate_key operations to identify the existing provider being updated.