Introducing zkAPI: private usage credits for any API

What it is

zkAPI ships two operating modes: a runtime-key mode (described in the existing summary) and a simpler proxy mode. In proxy mode, the zkAPI server itself relays requests to the AI provider rather than minting a local key — easier to operate, but the relay sees the traffic, which defeats the content-privacy goal. It implements a published design: "ZK API usage credits," an Ethereum Research proposal by Davide Crapis and Vitalik Buterin. It currently runs on Ethereum Mainnet.

How it works

In the mode the summary describes, the client exposes standard OpenAI and Ollama API endpoints on localhost, so existing apps/editors point at the local client with no code changes. The vault contract itself verifies ZK proofs not just at deposit but also at close and escape — meaning a user can unilaterally exit and withdraw funds on-chain even if every zkAPI server goes offline, without depending on server honesty. The spending cap acts as a reservation: the provider records total usage in a signed receipt when the key expires, and the server deducts the actual metered amount (not the full cap) from the private note. Neither side can alter the bill after the fact.

flowchart LR
    A[User device: proof of payment] --> B[zkAPI server: mints short-lived capped key]
    B --> C[Direct: device to AI provider]
    C --> D[Key expires: signed usage receipt]
    D --> E[Server deducts actual usage from note]
    F[Proxy mode: server relays requests] -.sees traffic.-> C

Preconditions / Affected

Applies to self-hosted/local integration: the private client must run on the user's own device for the unlinkability property to hold. Using proxy mode instead of runtime-key mode reintroduces a party (the relay) that sees prompt content, trading privacy for operational simplicity. For providers, integration requires accepting ZK proofs in place of API keys and settling against signed usage receipts instead of maintaining account state; pricing/rate-limiting/infra are otherwise unchanged.

What to do

• Use runtime-key mode, not proxy mode, if the threat model requires the relay to never see prompt content.
• Route through Tor with a fresh circuit per session to blunt IP-based session correlation (stated mitigation, not built into the base protocol).
• To avoid prompt-content fingerprinting across sessions, avoid reusing identical personal details, writing style, or project documents in standalone queries; the page suggests local/TEE models generating requests over shared memory as an emerging alternative to manually repeating context.
• Providers wanting to integrate: accept proof-of-payment instead of API-key auth, and settle billing via signed usage receipts.

Caveats

The page is explicit that proxy mode is a privacy downgrade relative to runtime-key mode — it exists only for operational ease. It also flags that Tor and TEE/confidential-GPU mitigations for network and content leakage respectively are external, not integrated into zkAPI itself, and TEE-based content privacy is described as "emerging," i.e., not yet mature.