Glossary
Terms as this API uses them. Where a term is commonly used loosely, the entry says what it maps to here.
Trusted Execution Environment. Hardware-isolated memory in which code runs where the operator of the machine cannot read it. On this network TEEs are built on Intel TDX, and providers come in two kinds — TeeML and TeeTLS — which differ in what exactly runs inside the enclave. That difference is what trust modes select between.
A provider that runs the model itself inside the enclave. Your prompt enters encrypted, inference happens inside, and the response is signed inside. Neither 0G nor the operator of the hardware can read the plaintext.
TeeML providers are the only ones that can serve the private trust mode, and they also satisfy verified. In the model catalog they appear as verifiability: "TeeML".
TeeTLS
Section titled “TeeTLS”A provider reached through a 0G broker that itself runs inside a TEE, over attested TLS. The broker cannot read what passes through it, but the upstream provider processes your prompt in plaintext under its own data policy.
TeeTLS satisfies verified but not private. In the catalog: verifiability: "TeeTLS".
Trust mode
Section titled “Trust mode”A routing constraint that restricts which providers may serve a request, based on what they can prove. Three values, ordered standard < verified < private, set with the X-0G-Provider-Trust-Mode header or on an API key.
A tier is a floor, not an exact match: asking for verified can be satisfied by a stronger private provider. There is no default — omit the header and no restriction applies. If no provider can meet the tier, the request fails with 503 no_provider_for_trust_mode rather than being served at a weaker tier. Full comparison: Trust Modes.
Provider
Section titled “Provider”An independent operator running a model on the network. Identity is an on-chain address (0x…). One model ID usually has several providers, each with its own price and TEE capability, which is why the same model can cost different amounts and why not every model can serve every trust mode. See Models and providers.
Router
Section titled “Router”The API gateway you call: https://router-api.0g.ai/v1. It authenticates the request, applies your routing preferences, selects a healthy provider, forwards the call, and returns the response with an x_0g_trace block attached. Throughout this documentation, “the Router” means this gateway rather than the network behind it.
Proof ID
Section titled “Proof ID”Not a field in this API. The term appears in older material and in conversation; what it refers to here is the set of artifacts a response actually carries:
| What you want | The real artifact |
|---|---|
| An identifier for one request | x_0g_trace.request_id |
| Which provider served it | x_0g_trace.provider (on-chain address) |
| Did the Router check the TEE signature | x_0g_trace.tee_verified (only when you send verify_tee) |
| The handle for re-verifying it yourself | The ZG-Res-Key response header |
See Verification and TEE for how they fit together.
Attestation
Section titled “Attestation”Evidence produced by TEE hardware that a specific piece of code is running inside a genuine enclave. It is what makes “the model ran in isolation” checkable rather than a claim. Signature verification on a response is the part you exercise per request; hardware attestation is the layer under it.
x_0g_trace
Section titled “x_0g_trace”A block added to every Router response. Carries request_id, provider, billing (input_cost, output_cost, total_cost), and — when you request verification — tee_verified. It is additive: standard OpenAI fields are unchanged, so existing parsers keep working. See Track what each request costs.
verify_tee
Section titled “verify_tee”A request-level flag (verify_tee: true in the JSON body, ?verify_tee=true on multipart endpoints) asking the Router to synchronously verify the provider’s TEE signature. It is a 0G extension and is stripped before the request is forwarded upstream. The outcome appears as tee_verified: true verified, false a signature was present and failed verification (treat the response as untrusted), absent means verification was not requested.
sk- key
Section titled “sk- key”An inference API key. Calls the model endpoints and is billed against your deposit. Has no scope concept, and is rejected from account endpoints with 403 insufficient_scope. Store it in ZG_API_KEY.
mk- key
Section titled “mk- key”A management key for account administration — balance, usage, and managing sk- keys. Not billed for inference. Carries scopes (account:read, keys:read, keys:create, keys:manage) and records last_used_at and last_source_ip for auditing. Store it in ZG_MANAGEMENT_KEY. See Create and manage API keys.
Zero data retention
Section titled “Zero data retention”The commitment that prompt and completion content for text and audio inference exists only in memory for the lifetime of a request: no conversation store, no log archive, no training on your data. Bounded exceptions exist where a format requires temporary storage — uploaded multipart files are deleted within 60 minutes, image generation inputs and outputs within 30 minutes. What is kept is billing metadata only, which contains no request content. See Why 0G Private Computer.
Failover
Section titled “Failover”Automatic retry against a different provider when the selected one fails. On by default; turned off implicitly when you pin a provider with X-0G-Provider-Address, and re-enabled by sending X-0G-Provider-Allow-Fallbacks: true. Price ceilings still apply during failover, so a fallback can never route you to a provider above your limit. See Handle failover and retries.
Related
Section titled “Related”- Trust Modes — the three tiers in full
- Verification and TEE — what each guarantee rests on
- Models and providers — how requests reach a provider
- Error Codes — every code the Router returns