zkAPI is a payment layer that lets you pay for AI models and other metered APIs from a prepaid Ethereum vault. It uses zero-knowledge proofs instead of an account, so the provider cannot tie your requests to who paid. It does not hide what you ask: the AI provider still reads your prompts, and network and writing patterns can still link sessions. The Ethereum Foundation announced it as live on Ethereum mainnet on Oct. 1, 2026. It was built by the Open Anonymity Project with the Foundation.
The problem it targets
An API key points to an account, and the account points to a payment method. Every prompt joins that record. The Foundation's post says a provider "can connect years of your usage into a single profile."
The post names the two older options and their costs. One is paying per request onchain, which it calls slow, expensive and traceable by anyone. The other is trusting a middleman not to look.
How a zkAPI payment works
The flow below is the "runtime-key" mode described in the announcement.
- Deposit once. You put credits into a vault contract on Ethereum in one ordinary transaction. Your balance becomes a private note that only you can spend.
- Send a proof. A client on your device sends the zkAPI server a zero-knowledge proof showing that a funded note covers this spend and has not been spent before. A zero-knowledge proof shows a statement is true without revealing the data behind it. The proof carries no prompt and no identity.
- Get a capped key. The server verifies the proof and issues a short-lived API key, capped in dollars and held only in your device's memory.
- Talk to the model. Prompts go from your device straight to the AI provider with that key. One key can cover a whole session, so you do not generate a proof per call.
- Pay for actual use. When the key expires, the provider side records total usage in a signed receipt and the server deducts that amount from your note. The cap was only a reservation. The post says neither side can change the bill afterward.
The announcement says the local client exposes the standard OpenAI and Ollama APIs on your machine, so you can point existing apps at it by changing the endpoint. The project's docs name OpenRouter as the upstream provider that issues the short-lived keys.
Two modes
- Runtime-key mode: your device talks to the provider directly, so no payment intermediary sees the traffic.
- Proxy mode: the zkAPI server relays requests to the provider. It is simpler to run, but the relay sees your traffic.
Who sees what
The announcement lists the following for runtime-key mode:
| Party | Learns | Does not learn |
|---|---|---|
| zkAPI server | That a valid payment exists; total dollars per session | Who you are, what you asked, which deposit paid |
| AI provider | Prompts and responses | Who is paying |
| Ethereum (public) | Deposits, closes, withdrawals | What any balance paid for |
What zkAPI does not hide
The announcement and the docs both list these gaps:
- Network metadata. The provider sees your IP address and can try to link sessions by timing. The gateway can correlate request patterns from a stable IP. The post suggests Tor with a fresh circuit per session.
- Content. Repeated personal details, reused chat history, project documents or your writing style can re-link sessions. The post frames this as a privacy-utility tradeoff: standalone questions are more private but less useful. It points to local or TEE-run models to compose requests, and describes confidential GPU computing as emerging.
- Onchain activity. Deposits and withdrawals are public.
| Layer | What can leak | Covered by zkAPI? |
|---|---|---|
| Payment | Who paid for which request | Yes |
| Network | IP address, timing | No (VPN or Tor suggested) |
| Content | Repeated details, style, documents | No |
What does zkAPI keep private for you?
Pick what you want to keep from the AI provider and the payment server, and see whether zkAPI covers it.
What do you most want to keep private when you pay for AI requests?
- Which account or deposit paid for my requests → next question
- What I ask and the answers I get → zkAPI does not hide your prompts
- My IP address and when I connect → Network metadata is not covered
Should the zkAPI server be kept out of your traffic to the AI provider?
- Yes, my device should talk to the provider directly → next question
- No, a simpler relay is fine → Proxy mode: the relay sees your traffic
Will your sessions repeat personal details, reused chat history, project documents or a recognisable writing style?
- Yes, they will → Your content can re-link sessions
- No, mostly standalone questions → Runtime-key mode covers the payment link
The zkAPI server learns only that a valid payment exists and the total dollars per session. The AI provider reads your prompts but not who is paying. Your IP address, connection timing and public onchain deposits and withdrawals stay visible, and the code calls itself experimental with no security audit cited.
In proxy mode the zkAPI server relays your requests to the provider. It is simpler to run, but the relay sees your traffic. Runtime-key mode is the one in which no payment intermediary sees it.
zkAPI separates payment from requests, but repeated personal details, reused chat history, documents or writing style can tie sessions back together. The announcement calls this a privacy-utility tradeoff and points to local or TEE-run models for composing requests.
The AI provider still reads your prompts and responses. zkAPI hides who paid, not what you ask. The announcement points to local or TEE-run models and describes confidential GPU computing as emerging.
The provider sees your IP address and can try to link sessions by timing, and the gateway can correlate request patterns from a stable IP. The announcement suggests Tor with a fresh circuit per session; a VPN is the other option the article lists.
This maps the privacy layers the announcement and docs describe; it does not test the code, judge whether deposits are safe, or settle whether the vault accepts ETH only or also USDC.
The cryptography underneath
- Deposits are stored as commitments in a Merkle tree 32 levels deep, so a proof can show a note is valid without pointing at which one.
- Each spend publishes a nullifier, a one-way serial number derived from the note's secret. Spending the same balance twice produces a duplicate nullifier, which exposes the attempt and nothing else.
- Spend proofs use Groth16 on the BN254 curve; commitments and nullifiers are hashed with Poseidon. The repository and docs add Baby-JubJub commitments and Schnorr signatures.
- The server checks spend proofs offchain. The vault contract checks the same kind of proof at deposit, close and escape, which is why the Foundation says you can withdraw onchain "even if every zkAPI server disappears."
From research post to mainnet
Davide Crapis and Vitalik Buterin published the "ZK API usage credits" design on Ethereum Research on Feb. 11, 2026. That design used rate-limit nullifiers: reusing a ticket index reveals the user's secret key, so a double-spender's deposit can be slashed. It also proposed signed refunds for unused cost and a split between a slashable stake and a burned policy stake.
The launched system differs. The announcement does not describe slashing; a duplicate nullifier simply exposes the attempt. The mainnet announcement came on Oct. 1, about seven and a half months after the design post.
What the code itself says
The project's own materials are more cautious than the launch post:
- The GitHub README says "The protocol is experimental" and describes the branch as "Not a production release." Until version 1.0.0, any interface may change.
- The docs say the checked-in proving keys "use a single-party setup with no multiparty ceremony," and the README says production keys need a multi-party setup.
- The docs state the Groth16 and Baby-JubJub construction is not post-quantum.
- Neither the announcement nor the repository cites a security audit.
The sources also disagree on which assets you can deposit. The announcement says you can deposit "ETH, USDC, etc." and describes the mainnet vault as one "holding USDC credits." The README and docs describe funding with native ETH only.
Beyond chatbots
The announcement lists other metered services the same client and contracts could front: blockchain RPC queries, image and video generation jobs, VPN time and bandwidth, and machine-to-machine services where agents pay per task without an account.
For providers, the Foundation says integration means accepting a proof instead of an API key and settling signed usage receipts, with pricing, rate limits and infrastructure unchanged. The announcement names no integrated providers, fees or timeline; the docs name OpenRouter as the current upstream.
How to try it
- Browser: OA Chat (chat.openanonymity.ai) is the Open Anonymity Project's private AI chat. The announcement links to it and describes it as running in the browser with no install.
- Your own apps: run the local gateway,
zkapi-clientd, from the GitHub repository and follow the docs. - Inspect the contracts: the ZkApiVault on mainnet is source-verified on Etherscan. A Sepolia deployment runs with test funds.
Before you deposit anything, note that the code calls itself experimental, its proving keys come from a single-party setup, and no security audit has been cited.
