Plain answers

How a job is sealed

Every job is encrypted to exactly one device with a key that is used once and thrown away. The coordinator moves ciphertext and counts tokens; it does not keep the text. Here is the path a prompt takes.

The path of one prompt

  1. A buyer sends a prompt to the coordinator over TLS, like any API call.
  2. The coordinator picks one device for the job and generates a fresh key pair for this job only (X25519).
  3. It seals the prompt to that device's registered public key (NaCl box) and forwards the sealed job. The device is the only party that can open it.
  4. The device runs the model and returns the completion sealed the same way, chunk by chunk.
  5. The coordinator decrypts each chunk only at the relay boundary, in memory, to stream it back to the buyer and count tokens. Nothing is written to disk and nothing is logged.
  6. The job key is discarded. A later compromise of the coordinator cannot decrypt past jobs.

Who can see what

PartySees
The buyerTheir own prompt and completion, which device served it, and the price.
The device ownerAt the community tier, the owner is not prevented from inspecting the plaintext in memory on their own device. Buyers who need more require the attested tier.
The coordinatorCiphertext in transit, token counts, timing, model, tier and which device. Plaintext exists only transiently at the relay boundary and is never stored.
Anyone on the network pathTLS on the outside, a per-job seal on the inside. Nothing readable.

Trust tiers

What keeps this honest