> ## Documentation Index
> Fetch the complete documentation index at: https://developers.t2000.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# FAQ

> Common questions about t2000's Confidential tier — attestation, receipts, the Sui anchor, the trust boundary, and how it differs from the Private (ZDR) tier.

<AccordionGroup>
  <Accordion title="What is the Confidential tier?" icon="microchip">
    Inference served by a gateway running in a TEE that proves its own identity with an [attestation report](/confidential-ai/attestation) and signs a per-response [receipt](/confidential-ai/receipts) binding your request + response to that attested workload — and t2000 [anchors that receipt on Sui](/confidential-ai/verify). You [verify](/confidential-ai/verify) the proofs yourself rather than trusting an API's word. Available on `phala/*` models.
  </Accordion>

  <Accordion title="How is it different from the Private (ZDR) tier?" icon="code-compare">
    **Private** (every model) is zero data retention — providers are contractually bound not to store or train on your prompts. **Confidential** (`phala/*`) adds hardware: the model runs in a verified GPU-TEE, with a signed, Sui-anchored receipt you can check. Private is a policy promise; Confidential is cryptographic evidence.
  </Accordion>

  <Accordion title="Can t2000 read my prompts?" icon="eye">
    On a confidential call, plaintext is visible to the **attested** gateway after TLS terminates, because it has to process the request — but the gateway is a reviewed workload in a TEE and **retains nothing** (zero data retention). It does not mean no software ever sees the request. For the exact boundary, read the [trust boundary](/confidential-ai/trust-boundary). Full end-to-end encryption — where even t2000 never sees plaintext — is planned for v3.1.
  </Accordion>

  <Accordion title="How do I prove a response was genuinely confidential?" icon="circle-check">
    Run **`t2 verify <receipt-id>`** — it reads the on-chain Sui anchor (trustless) and recovers the receipt signature against the attested key, and surfaces the `upstream.verified` result + typed claims. Or check it manually: [attestation](/confidential-ai/attestation) → [receipt](/confidential-ai/receipts) (`upstream.verified.result = verified`) → [anchor](/confidential-ai/verify). See [Verify a response](/confidential-ai/verify).
  </Accordion>

  <Accordion title="What's the Sui anchor — and why Sui?" icon="link">
    Every confidential response **is automatically anchored on Sui** as a `ReceiptAnchored` event committing the response hash + attested workload id — a tamper-evident, publicly-timestamped, independently-checkable record (browse them all at [verify.t2000.ai](https://verify.t2000.ai)). RedPill anchors on Ethereum/Automata; t2000 anchors on **Sui** — the only Sui-native verifiable-inference anchor. It's read straight from a fullnode, so t2000 can't forge it.
  </Accordion>

  <Accordion title="Which models are confidential?" icon="server">
    The `phala/*` models — confirm per response from the receipt's `upstream.verified` event (`result = verified`, `required = true`). Confidentiality is a property of the verified upstream provider, not the model id. The upstream may be NEAR AI, Chutes, Phala, or Tinfoil — see [Providers](/confidential-ai/providers); the receipt names which one served.
  </Accordion>

  <Accordion title="What does the nonce in the attestation report do?" icon="shuffle">
    `GET /v1/aci/attestation?model=…&nonce=<hex>` binds your nonce into the hardware-signed quote's `report_data`. A report that commits a nonce you just generated can't be a replay — that's how you prove freshness. Use a new random nonce each time. See [Attestation](/confidential-ai/attestation).
  </Accordion>

  <Accordion title="What does the gateway store?" icon="database">
    Receipts hold **hashes** of your request and response, not the content. The gateway does not store request or response bodies.
  </Accordion>
</AccordionGroup>