By Introducing zkAPI: private usage credits for any API
tl;dr: zkAPI lets you pay for a metered API without being known. Deposit credits into an Ethereum vault once, then authorize bounded usage with zero-knowledge proofs instead of an identity. The provider sees the requests, and the payment layer sees the spend. Neither learns the link between them.
The Open Anonymity Project built it with the Ethereum Foundation, and it runs on Ethereum Mainnet today.
The problem
Every AI API call today carries an identity. Your API key points to an account, the account to a payment method, and every prompt you send joins the record attached to both. The provider can connect years of your usage into a single profile.
Prompts are personal. People ask AI models about their health, their finances, their doubts. Under the current model, using AI means handing a running transcript of your thinking to whoever holds the billing relationship. The alternatives were poor: pay per request onchain, which is slow, expensive, and traceable by anyone, or trust a middleman not to look.
The idea
zkAPI separates payment from identity. You deposit credits (ETH, USDC, etc.) into a vault contract on Ethereum, one ordinary transaction. From then on, your balance exists as a private note: digital cash that only you can spend and that nobody can trace back to the deposit.
To authorize spending, software on your machine produces a small zero-knowledge proof that says, in effect, that a funded note covers this spend and nobody has spent it before. One proof can cover a single request or a whole session. The server can check that the statement is true without learning which note, which deposit, or which person. At the payment layer, requests do not link to you, and they do not link to each other.
Two pieces of cryptography make this safe as well as private. Deposits live as commitments in a Merkle tree, so a proof can show “my note is one of the valid ones” without pointing at any particular one. Every spend publishes a nullifier, a one-way serial number derived from the note’s secret. A user who stays within their balance stays unlinkable. A user who tries to spend the same balance twice produces a duplicate nullifier, which exposes the attempt and nothing else.
How it works
The payment path (steps 1 to 3) and the conversation path (step 4) share two objects: the short-lived key and its usage receipt.
The server that handles money never sees content, and the provider that sees content never learns the billing identity behind a key.
- Your app talks to a small client running on your own device. Nothing about the app changes. It speaks the same API it always did.
- The client sends the zkAPI server a proof of payment, with no prompt and no identity attached.
- The server checks the proof and mints a fresh API key on the spot, short-lived and capped in dollars. The key exists only in your device’s memory.
- Your prompts go straight from your device to the AI provider with that key. When the key expires, the server charges your private balance for the metered usage rather than the reserved cap.
The spending cap works as a reservation. When the key expires, the provider side records the key’s total usage in a signed receipt, and the server deducts that amount from your note. Neither side can rewrite the bill afterward, and one authorization covers a whole session of requests rather than one proof per call.
zkAPI also ships a simpler proxy mode, where the zkAPI server relays requests to the provider itself. It is easier to operate, but the relay sees traffic. The runtime-key mode above exists so that no payment intermediary ever does.
zkAPI proves spends with Groth16 on the BN254 curve, hashes commitments and nullifiers with Poseidon, and keeps notes in a Merkle tree 32 levels deep. The server verifies spend proofs off-chain. The vault contract verifies the same kind of proof at deposit, close, and escape, so your exit never depends on the server’s honesty.
In practice
| Party | Learns | Never learns |
|---|---|---|
| zkAPI server | a valid payment exists, and total dollars per session | who you are, what you asked, which deposit paid |
| AI provider | prompts and responses, since it runs the model | who is paying |
| Ethereum (public) | deposits, closes, withdrawals | what any balance paid for |
-
Your funds stay yours: The vault is a contract on Ethereum rather than a company account: you can close your balance and withdraw onchain, even if every zkAPI server disappears.
-
Your tools stay the same: The client exposes the standard OpenAI and Ollama APIs on your own machine. Existing apps, editors, and chat clients work by pointing them at localhost.
Use cases
AI inference comes first because prompts are sensitive and the billing trail ties each one to you. The same client and contracts can front any service that charges per use:
| Use case | Metered unit | What the payment layer hides |
|---|---|---|
| AI chat and agents | model calls | which note paid, and any billing link between sessions |
| Blockchain RPC | queries | which funding source paid for the queries |
| Image and video generation | jobs | who paid for which jobs |
| VPNs and bandwidth | time and data | who paid for the connection |
| Machine-to-machine services | per-task spend | agents pay without an account |
zkAPI hides the payment link. A provider still sees what a request contains and network metadata such as your IP address, and it can try to correlate sessions by timing. Network anonymity and content privacy are separate layers: a VPN or Tor handles the network side, and confidential GPU computing is emerging for content.
For providers, integrating means accepting a proof instead of an API key and settling signed usage receipts instead of maintaining accounts. Pricing, rate limits, and infrastructure stay as they are.
Limitations
zkAPI’s protections have two limitations: the lack of network anonymity, and privacy leakage via prompt contents.
On the network side, the main issue is that the gateway can potentially correlate request patterns from a user if they send requests to zkAPI under a stable user IP address. Users seeking stronger privacy may route requests through Tor and use a fresh circuit for each session.
On the content side, individual sessions may be re-linked by the inference provider if the same personal details, writing style, reused conversation history, or project documents are presented. Shared prompt contents can act as fingerprints for anyone who can read the prompts. This is a privacy-utility tradeoff: standalone queries are more private but less useful since past context is missing. One mitigation is to leverage local or TEE models to generate requests on top of shared memory instead of the user manually writing them. See also discussions in the Open Anonymity project post.
Background and links
zkAPI is the working implementation of ZK API usage credits, a design published on Ethereum Research by Davide Crapis and Vitalik Buterin.
The Open Anonymity team helped turn that design into the client, the server, and the contracts you can run today.
zkAPI is live on Ethereum mainnet today. Try it:
Or build the local gateway and point any OpenAI-compatible app at it using the docs.
