Claims a validator slot and provisions its node, after proving the caller's…

Claims a validator slot and provisions its node, after proving the caller's wallet owns the slot's NFT.

POST /v1/validator

Validator → · All API references → · Six flows, four surfaces →


Address	`https://api.hanzo.ai/v1/validator`
Method	`POST`
Operation	`post_validator`
Auth	`Authorization: Bearer $HANZO_API_KEY`

Claims a validator slot and provisions its node, after proving the caller's wallet owns the slot's NFT.

The pipeline, all server-enforced: burn the single-use challenge (so a replayed or forged nonce dies before any chain read), recover the signer from the message this server rebuilds, require that wallet to hold Validator-tier GenesisNFT #tokenId on Ethereum mainnet, generate a fresh luxd staking identity and seal it into KMS, write a LuxNetwork CR for a NEW node, and ENQUEUE an owner-gated registration. The registration is never auto-submitted to any P-Chain — the owner co-signs it out of band — and the stake weight is set at co-sign time, never derived from the NFT.

It fails CLOSED at every gate: a bad signature, a non-owner, a non-tier slot or an unavailable KMS all leave no claim persisted and no key material exposed. Re-claiming a slot this org already holds re-applies the node CR and returns 200 with the existing identity (keys and NodeID are stable); a slot held by another org is 409. A cluster-less deployment still claims the slot, seals the keys and queues the registration, reporting the node as "node_pending".

Request

3 fields, body application/json (required).

Field	In	Type	Required	Description
`nonce`	body	string	—	Nonce is the value GET /v1/validator/challenge issued for this slot.
`signature`	body	string	—	Signature is the wallet's personal_sign over the challenge message, hex with a 0x prefix.
`tokenId`	body	integer	—	TokenID is the Validator-tier GenesisNFT token id being claimed.

Response

Status	Body	Meaning
`200`	slotView	ok

200 body — 15 fields.

Field	In	Type	Always	Description
`blsPubkey`	body	string	—	BLSPubkey is the node's BLS public key, hex.
`crName`	body	string	—	CRName is the LuxNetwork custom resource that materializes the node.
`createdAt`	body	integer	—	CreatedAt is when the slot was first claimed, as a Unix timestamp.
`namespace`	body	string	—	Namespace is the Kubernetes namespace the node's CR lives in.
`network`	body	string	—	Network is the luxd network slug the node joins.
`nodeID`	body	string	—	NodeID is the luxd node id derived from the sealed staking identity.
`nodeStatus`	body	string	—	NodeStatus is the provisioning state of the node: "node_created" once the CR is applied, "node_pending" when no cluster is reachable (the slot is still claimed…
`registration`	body	registrationView	—
`registration.id`	body	string	—	ID is the registration's handle.
`registration.nodeID`	body	string	—	NodeID is the luxd node the registration is for.
`registration.status`	body	string	—	Status is the registration's lifecycle state; "pending_owner_approval" until the owner co-signs it out of band.
`slot`	body	integer	—	Slot is the validator slot number — the same value as tokenId, under the name the portal reads.
`tokenId`	body	integer	—	TokenID is the GenesisNFT token id that IS this slot.
`updatedAt`	body	integer	—	UpdatedAt is when the slot last changed, as a Unix timestamp.
`wallet`	body	string	—	Wallet is the lowercase Ethereum address that proved ownership of the NFT.

Failure carries the platform error shape — see Errors.

Examples

hanzo validators create

import { Configuration, ValidatorApi } from 'hanzoai';

const api = new ValidatorApi(new Configuration({ accessToken: process.env.HANZO_API_KEY }));
const { data } = await api.postValidator({ nonce: "<nonce>", signature: "<signature>" });

from hanzoai.cloud import ApiClient, Configuration
from hanzoai.cloud.api import ValidatorApi

client = ApiClient(Configuration(access_token=os.environ["HANZO_API_KEY"]))
result = ValidatorApi(client).post_validator(nonce="<nonce>", signature="<signature>")

cfg := cloud.NewConfiguration()
cfg.AddDefaultHeader("Authorization", "Bearer "+os.Getenv("HANZO_API_KEY"))
client := cloud.NewAPIClient(cfg)

resp, _, err := client.ValidatorAPI.PostValidator(context.Background()).Execute()
if err != nil {
	return err
}

use hanzo_cloud::apis::{configuration::Configuration, validator_api};

let mut cfg = Configuration::new();
cfg.bearer_access_token = std::env::var("HANZO_API_KEY").ok();

let result = validator_api::post_validator(&cfg, Default::default()).await?;

import ai.hanzo.cloud.ApiClient;
import ai.hanzo.cloud.api.ValidatorApi;

ApiClient client = new ApiClient();
client.setRequestInterceptor(b -> b.header("Authorization", "Bearer " + System.getenv("HANZO_API_KEY")));

var result = new ValidatorApi(client).postValidator();

The method above is the one at the current release of the document. [email protected] (npm) and [email protected] (PyPI) were generated from an earlier release, where this operation carried a different id, so it spells the method differently — regenerating the clients is what makes the two agree. SDKs →

curl -X POST https://api.hanzo.ai/v1/validator \
  -H "Authorization: Bearer $HANZO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
       "nonce": "<nonce>",
       "signature": "<signature>"
     }'

The door reaches validator through the validators tool, which names its 4 operations with its own verbs — this one among them, under a name only the door declares. describe explains any of them:

curl -X POST https://api.hanzo.ai/v1/mcp \
  -H "Content-Type: application/json" \
  -d '{
       "jsonrpc": "2.0",
       "id": 1,
       "method": "tools/call",
       "params": {
         "name": "describe",
         "arguments": {
           "op": "list_validators"
         }
       }
     }'

Validator API · All Hanzo APIs · Interactive reference

Claims a validator slot and provisions its node, after proving the caller's…

Request

Response

Examples

On this page