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

# Z Inference Gateway Overview

The Z Inference Gateway is the front door to Z. It is a single OpenAI-compatible REST API that routes inference requests across multiple providers and trust tiers, and settles payment through fiat or on-chain rails on a unified credit ledger.

This page describes what the gateway provides, who uses it, and how the interface is shaped. The trust tiers, the API call format, the model registry, and the underlying node layer each have their own pages in this section.

## What the gateway provides

**One API for any model.** Frontier providers, open-source models, hardware-attested inference, and end-to-end encrypted inference are all reachable through the same endpoint. The model identifier and an optional tier suffix select what runs and under what guarantees.

**OpenAI compatibility.** The wire format follows the OpenAI Chat Completions specification for Tiers 1 through 3. Existing client code (OpenAI SDK, LangChain, Vercel AI SDK) works by changing the base URL. Tier 4 (end-to-end encrypted) requires a pre-flight handshake and is accessed through the Z TypeScript SDK.

**Cryptographically enforced trust tiers.** Tier selection is per request. The gateway does not silently downgrade; if the requested tier cannot be served by a healthy node, the request fails and the client decides whether to retry at a different tier.

**Unified settlement.** Stripe top-ups, x402 on-chain payments, and pre-authorized MPP sessions feed a single credit pool. Inference debits the pool; the rail of origin is preserved for reporting but not for entitlement.

**Architectural Zero Data Retention.** Z does not retain prompts or completions on any tier. On Tier 4, Z cannot retain them by design. The gateway holds no decryption key.

## Who uses the gateway

The user hierarchy, in priority order:

**AI agents** are the primary user. Agents authenticate via SIWE, pay per-request via x402 on Core and other supported chains like Z, Base, Solana, Tempo, etc., or run within MPP sessions for streaming workloads. The wallet-native path is built around the assumption that the principal is non-human and operates without supervised credentialing.

**Human developers** integrate the gateway as their primary inference endpoint. The OpenAI compatibility means most existing application code requires only a base URL change to begin issuing requests. The trust tier becomes a deployment parameter: an internal tool might run on Tier 1; a customer-facing healthcare assistant might require Tier 3 or Tier 4.

**Non-technical builders** use the gateway through AI coding assistants like Cursor. Because these tools accept a custom OpenAI-compatible base URL, they can target Z without an SDK or a dedicated integration. Tier selection still applies: a personal project runs fine on Tier 1, while anything touching sensitive user data should default to Tier 3 or higher.

**Enterprise organizations** deploy agents at scale and require Tier 3 or Tier 4 compliance guarantees. The hardware-attestation chain on these tiers is what makes the gateway a compliance-grade substrate, not a routing convenience.

## Shape of the interface

The gateway exposes a small surface of HTTP endpoints. The most important is `/v1/chat/completions`, which mirrors the OpenAI Chat Completions specification. For Tier 4 there is also `/v1/handshake`, which performs an ephemeral key exchange before the encrypted request is transmitted.

Authentication is by API key (for OAuth-linked accounts) or by signed wallet credential (SIWE for Ethereum-compatible chains, SIWS for Solana) for wallet-native users. Both paths resolve to the same credit pool.

The trust tier is selected by appending a suffix to the model identifier (`deepseek-v3:tee`) or by setting the `X-Z-Tier` header. The two are equivalent; the header exists for SDKs that do not permit model-string mutation.

Streaming responses use server-sent events in the standard OpenAI format. On Tier 4 the gateway relays an additional `z_metadata` event after the final encrypted chunk; this event carries the silicon-signed completion metadata that gates billing without requiring the gateway to decrypt the response payload.

Detailed request and response shapes are documented in the [z.infer() API](/docs/inference/api) page.

## How to think about the gateway

A useful mental model: the gateway is the inference equivalent of a payment processor. It abstracts a heterogeneous set of upstream providers behind a single interface, enforces a uniform set of guarantees across them, settles in a single accounting unit, and produces metering for every transaction. The differences from a payment processor are that the upstream providers are language models rather than card networks, the guarantees are about trust and privacy rather than fraud and chargebacks, and the metering is anchored, on Tiers 3 and 4, to hardware-signed evidence.

The implication for integrators is that the gateway is a stable abstraction layer. Upstream provider mix can change; routing logic can be tuned; new tiers can be added. The integrator's contract is with the gateway, not with any underlying provider.