Introducing zkAPI: private usage credits for any API

What problem does zkAPI address?

Today, every AI API call is tied to an identity: an API key maps to an account, which maps to a payment method, and each prompt becomes part of a permanent usage record. This creates a privacy risk because personal queries—about health, finances, or beliefs—are permanently linked to the payer. The Ethereum Foundation report asks whether it is possible to decouple payment from identity while keeping the same developer experience.

How does zkAPI work?

The solution is a two‑step architecture built by the Open Anonymity Project with the Ethereum Foundation. First, users deposit credits (ETH, USDC, etc.) into a smart‑contract vault on Ethereum. That deposit becomes a private note stored in a 32‑level Merkle tree. When a request is made, a client on the user’s device generates a tiny Groth16 zero‑knowledge proof that the note covers the spend and has not been spent before. The proof is sent to the zkAPI server, which validates it off‑chain and issues a short‑lived API key that exists only in memory. The provider receives the request with this key, sees the prompt content, but never learns the payer’s identity or the link between requests.

Main findings and limitations

The report demonstrates that zkAPI can be run on Ethereum mainnet today, with a live vault holding USDC credits and open‑source client and server code. It confirms that the payment path and the conversation path remain unlinkable, and that users retain full control over their funds—withdrawals are possible even if every zkAPI server disappears. However, the authors note two privacy gaps: the system does not hide network‑level metadata, so a stable IP can be correlated, and prompt content itself can act as a fingerprint, especially when users reuse personal details or writing style. They recommend routing traffic through Tor or using local/TEE models to mitigate these risks.

Implications for developers and users

For API providers, integration is straightforward: they replace traditional API keys with zkAPI proofs and settle signed usage receipts, while keeping pricing and rate‑limit logic unchanged. For developers, no code changes are required—the client exposes standard OpenAI and Ollama endpoints on localhost, allowing existing applications to point to the local gateway. Users gain a privacy‑preserving payment layer but must still consider network anonymity and the potential for content‑based re‑identification.

Outlook

zkAPI represents a practical implementation of the ZK API usage credit design first published on Ethereum Research by Davide Crapis and Vitalik Buterin. By leveraging zero‑knowledge proofs and on‑chain vaults, it offers a viable path toward private, metered API consumption. Future work will likely focus on integrating network‑level anonymity and refining prompt‑privacy techniques to close the remaining gaps.