Servers

Submit Host Profile

Register a host class (sek8s discover-profile.sh output) so Chutes can measure it.

One of three distinct operations: this REGISTERS, POST /servers/tdx/preflight CHECKS launchability, and GET /servers/tdx/host_profiles LISTS the generated set. A miner reaches this only when preflight says the class is not yet launchable. The API owns the fingerprint -- the miner sends raw platform metadata and gets back the class's retention lifecycle, which only ever advances:

  • accepted -- a measurement has already been generated for this class; retained from here on
  • pending -- parked in object storage, awaiting its first measurement generation

A real submission is always stored, so this never returns unknown. It answers only whether the class has been measured at all; whether the caller's specific image can boot is preflight's job. Signed by the miner hotkey, so the signature covers the request body.

post/servers/tdx/host_profiles

Headers

X-Chutes-Hotkeystring nullable
X-Chutes-Signaturestring nullable
X-Chutes-Noncestring nullable
Authorizationstring nullable

Request body

hostnamestring nullable
timestampstring nullable
pci_topologystring nullable

Response

Successful Response

fingerprintstring required
status'accepted' | 'pending' | 'unknown' required

Retention lifecycle of a submitted host class -- monotonic, only ever advances (unknown -> pending -> accepted) and never regresses.

accepted is class-level and version-agnostic: a measurement was generated for this fingerprint at some point, so the class is on the attestable set and retained (its profile is kept for RTMR0 regeneration). It is NOT the answer to "can version X launch here" -- that is POST /servers/tdx/preflight, which joins the caller's (version, rc) to the class's measurements. Submission only reports which of the three the class is in.

storedboolean required
detailstring required

Changes