The Open Anonymity Project and Ethereum Foundation have introduced zkAPI credits, a payment system designed to separate metered API usage from a user’s billing identity. In its October 1, 2026 announcement, the foundation said zkAPI was live on Ethereum mainnet, with a vault holding USDC credits. AI inference is its first application, but the design also supports other services that charge by usage.
Key Takeaways
- zkAPI uses private balance notes and zero-knowledge proofs to authorize API spending without revealing which deposit funded it.
- Its runtime-key mode sends prompts directly to the AI provider, while the payment server receives proof of payment and session spending totals.
- The system hides payment links, not request contents or IP addresses; providers may still correlate sessions through network metadata or repeated personal details.
Table of Contents
- How zkAPI credits separate funding from requests
- A session cap reserves funds, not the final charge
- What is live, and how users retain access to funds
- Where payment privacy stops
- Conclusion
How zkAPI credits separate funding from requests
Instead of tying every API request to a billing account, zkAPI starts with a deposit into an Ethereum vault contract. The user receives a private balance note, and software on their device generates a proof that the note can cover an authorized spend without identifying the deposit behind it.
The Ethereum Foundation’s zkAPI announcement describes an implementation of the ZK API usage credits design published on Ethereum Research by Davide Crapis and Vitalik Buterin. The Open Anonymity team helped build the client, server and contracts.
Deposits are represented by commitments in a Merkle tree. Each spend produces a nullifier, a one-way identifier that detects attempts to spend the same balance twice. The intended result is payment verification without a billing trail connecting separate requests.
| Item | Details |
|---|---|
| Ethereum mainnet vault | Live at announcement; holds USDC credits. |
| Runtime-key mode | Prompts go directly to the provider; the payment server handles proofs and spending totals. |
| Proxy mode | The zkAPI server relays requests and can see traffic. |
| Session settlement | Signed usage receipts determine the charge rather than the reserved cap. |
| User exit | Balances can be closed and withdrawn onchain without an available zkAPI server. |
A session cap reserves funds, not the final charge
In runtime-key mode, a local client sends the zkAPI server a payment proof without attaching a prompt. After verification, the server issues a short-lived API key with a dollar-denominated cap. The key stays in device memory, and prompts travel directly from the device to the AI provider.
The cap reserves spending capacity rather than setting the final bill. When the key expires, the provider records total usage in a signed receipt, and the server deducts the metered amount from the private balance. One authorization can therefore cover a session rather than requiring a proof for every call.
zkAPI also offers a simpler proxy mode that relays requests through its server. That mode is easier to operate, according to the announcement, but the relay sees the traffic.
What is live, and how users retain access to funds
The announced mainnet vault holds USDC credits. A Sepolia deployment provides testing with test funds, while OA Chat offers browser-based AI chat without installation.
For existing software, the local client exposes standard OpenAI and Ollama APIs. Compatible applications, editors and chat clients can connect by pointing at localhost.
Spend proofs are verified off-chain by the server. The vault contract verifies proofs for deposit, close and escape operations, allowing users to close a balance and withdraw onchain even if zkAPI servers disappear. Funds sit in the Ethereum contract rather than a company account.
Where payment privacy stops
The provider still sees prompts, responses and network metadata such as IP addresses. Stable addresses and request timing can support correlation, while repeated personal details, writing styles or conversation histories can connect otherwise separate sessions.
The announcement suggests Tor with a fresh circuit per session for users seeking stronger network privacy. That does not conceal prompt contents from the inference provider. Reusing less context may reduce content-based linking, but it also makes conversations less useful.
Beyond AI, the same client and contracts can support metered blockchain RPC queries, generation jobs, bandwidth and machine-to-machine services. Those are described applications of the design, not a list of confirmed provider integrations.
Conclusion
zkAPI introduces a live Ethereum payment mechanism for separating API spending from billing identity. Its practical boundary is clear: private payment authorization does not make the underlying conversation or network connection anonymous.
Read More News
Disclaimer
This FinanceVelix article provides general information, not personalized financial, investment, legal, or tax advice. Crypto prices can change quickly, and you could lose all invested funds. Facts reflect the material available when published and may change. Check important information independently and consult a qualified professional when needed. Mentioning an asset, company, or service is not an endorsement.
