zkAPI turns an Ethereum deposit into private spending credits for metered APIs, but it does not hide prompts, responses or network metadata.
ETH$2,739.79+2.39%USDCThe Ethereum Foundation introduced zkAPI on October 1, 2026, as a way to pay for metered APIs without revealing the payer’s identity. The working system runs on Ethereum mainnet and supports payments for AI models exposed through standard OpenAI and Ollama interfaces.
The useful distinction is simple: zkAPI hides who funded an API session, not what happens inside it. The provider still receives your prompts and generates responses. Your IP address may also connect requests to you.
You start by depositing assets such as ETH or USDC into a vault contract on Ethereum. The transaction is ordinary, but your resulting balance exists as a private note that cannot be traced back to the deposit.
When you make a request, software on your device creates a zero-knowledge proof showing two things:
The server checks the proof without learning your identity or the original deposit. One proof can authorize a single request or an entire session.
The server then creates a short-lived API key capped in dollars. That key stays in your device’s memory. Once it expires, the AI provider records actual usage in a signed receipt, and the server deducts that amount from your private balance. The final charge is based on metered use, not the full amount reserved at the start.
For users of supported tools, zkAPI does not require a completely new application. Its local client exposes the standard OpenAI and Ollama APIs. Existing apps, editors and chat clients can connect to the service through localhost.
The privacy depends on which party sees what. A zkAPI server learns that valid payment exists and the total dollar value of each session. The AI provider handles the prompts and responses. Ethereum records deposits, closes and withdrawals.
A user who remains within their balance is also kept unlinkable between spends. Deposits enter a Merkle tree, while each spend publishes a nullifier derived from the note’s secret. The nullifier prevents a second valid spend of the same note without exposing the private balance itself.
That does not make the activity invisible.
The provider can see the contents of each request, along with network metadata such as your IP address. It may also attempt to link sessions through repeated personal details, writing style, conversation history or project documents. zkAPI protects payment identity, not content identity.
There is a further risk for users on a stable IP address. The gateway could potentially correlate request patterns over time. The Ethereum Foundation suggests routing requests through Tor and using a fresh circuit for each session for stronger privacy.
zkAPI also includes a proxy mode in which the zkAPI server relays requests to the provider. It is easier to operate, but the relay can see the traffic. The direct setup keeps prompts on the user’s device, while the proxy reduces that separation.
The clearest use case is an AI interaction that you want separated from your deposit address, without giving the provider a conventional account tied to you. A proof establishes that you funded the session without exposing the deposit transaction as your payment identity.
The same model is designed for services where ordinary identity-based payment creates a persistent record. The underlying research gives two examples:
The Ethereum examples matter because Ethereum applications often need metered access to services, but posting a transaction for every request would be slow, costly and publicly visible. zkAPI moves verification off-chain while using Ethereum deposits to secure the credit system.
Vault verification still happens on-chain at deposit, close and escape. The stated purpose is to make those exits independent of the server. The technical stack uses Groth16 proofs on BN254, Poseidon hashing and a 32-level Merkle tree.
zkAPI does not make every use of Ethereum private. The vault contract still records deposits, closes and withdrawals. The privacy claim is narrower: Ethereum can see value entering the system without being able to connect later private API spending to that deposit.
The server also cannot rewrite the final bill because the provider records usage in a signed receipt. The server deducts that verified amount from the note. This separates payment authorization from the final metered charge.
That is a practical change for Ethereum users. You can fund usage once, authorize a session with local proof and avoid creating a blockchain transaction for every API call. Your existing OpenAI or Ollama software can use the same interface.
The Ethereum Foundation says the client, server and contracts are available, and it links to a live mainnet vault holding USDC credits, a Sepolia test deployment, code and an in-browser private chat. The supplied research did not establish actual usage, volume, costs or pricing.
The pages also did not provide a readable audit, independent security review or confirmed vault deployment address. Those gaps matter for a system handling funds, even though its privacy claims rely on cryptography and on-chain contract behavior.
The February research proposal also described rate limits, refunds and a policy-stake system for abuse. The launch post does not make clear whether all of those mechanisms are active in the shipped version.
So zkAPI is best understood as a working privacy layer for payments, not a shield around the full API session. It can separate a private credit from the Ethereum address that funded it. It cannot separate you from the words you send, your network address or patterns that reveal the same person across sessions.
Core Lightning says node operators using version 26.06.7 or earlier should upgrade after reported attacks on unpatched nodes.
BTC
Fiserv's Roughrider Coin is settling interbank payments on Solana for more than 90 North Dakota banks and credit unions.
SOL
The SEC proposal would let advisers hold certain client crypto directly and add state trust companies as qualified custodians.
