> ## 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.

# Two access paths

Z is reached through two access paths. They differ in how requests enter the system, in the authentication and billing model, and in the level of privacy that is achievable on each. The paths share the same backend; an account can use either path or both.

## The chat-UI path

The chat-UI path is how a human or an agent talks to Z through a conversational interface. The interface authenticates the user (through OAuth subscription or wallet linkage), routes the request through the inference gateway, and renders the response. Tier selection is exposed to the user; OAuth-authenticated users can use Tiers 1 through 3, and Tier 4 is available once a wallet is linked to the account.

The chat-UI path is the right access pattern for:

* End users interacting with models for ordinary work.
* Demonstrating Z's capabilities to an evaluator.
* Quick experimentation across models and tiers before integration.

## The on-chain path

The on-chain path is how an agent, smart contract, or an application consumes Z's inference. The agent (a wallet, an autonomous program, or a smart contract) authenticates via SIWE, pays per request via x402 or per session via MPP, and consumes the response either through the `z.infer()`'s REST endpoint (if the agent is off-chain) or through a contract-callable `z.infer()` (if the agent is on-chain).

The on-chain path supports all four tiers, including Tier 4. It is the path that Z Trade and Z Lend themselves use to consume inference inside their own contract logic.

The on-chain path is the right access pattern for:

* Autonomous agents holding their own wallets and balances.
* On-chain protocols that need to consume inference inside contract execution.
* Workloads that benefit from per-request precision settlement.

## Privacy ceilings by path and model

Not every combination of path and tier delivers the same effective privacy. A useful way to think about it:

* **Chat-UI + Tier 1:** Z does not retain; the upstream provider operates under its own policy.
* **Chat-UI + Tier 2 or 3:** Z does not retain; the upstream is contractually private or hardware-attested.
* **Chat-UI + Tier 4 (with linked wallet):** End-to-end encrypted between the user's client and the TEE node. Z holds no decryption key.
* **On-chain + Tier 1 through 3:** As above; the agent's wallet is the principal.
* **On-chain + Tier 4:** End-to-end encrypted; the agent holds the ephemeral session key.

The privacy property that matters most depends on the workload. For internal experimentation, Tier 1 is usually correct. For workloads where the gateway must be cryptographically incapable of seeing content, Tier 4 is the answer. Anything in between is a judgment about how much of Z's operational posture the workload is willing to rely on.

## Shared backend

The two access paths use the same backend. There is one credit pool, one model registry, one set of trust tier definitions. An account can pay via Stripe for chat-UI use and via x402 for on-chain use. Both top up the same pool.

The practical guidance for an integrator: start with the path that fits the principal model. If the principal is a developer or an end user, use the chat-UI path or the off-chain API. If the principal is an agent or contract running on the host EVM chain, use the on-chain agent path. Cross-bridge when there is a specific reason to.