What changed
On 1 October 2026 the Ethereum Foundation dAI team published zkAPI, a way to pay for a metered API without attaching the spend to an identity. Vittorio Rivabella wrote the post. The Open Anonymity Project built the client, the server, and the contracts with the Foundation, and the system is running on Ethereum mainnet.
A user deposits credits once, in ETH or USDC, into a vault contract. After that deposit the balance is a private note. Software on the user's own machine produces a zero knowledge proof that a funded note covers the spend and that the note has not been spent before. One proof can cover a single request or a whole session. The API provider sees the requests. The payment layer sees that a valid payment exists and how many dollars a session used. Neither side learns which deposit paid for which prompt.
The design the code implements was published on Ethereum Research by Davide Crapis and Vitalik Buterin. zkAPI is the working version of that design. It is not a new token and it is not a testnet only demo. The Foundation says it is live on mainnet today.
Why it matters
Every ordinary AI API key points at an account, and the account points at a payment method. Prompts about health, finance, or internal plans then sit on the same record as the bill. Teams that send sensitive work to a hosted model have had two poor choices. They can pay per request on chain, which is slow, expensive, and readable by anyone watching the chain. Or they can trust the billing provider not to join the transcript to the payer.
zkAPI splits those records. An app keeps speaking the API it already speaks. A small client on the user's device 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. That key is short lived, capped in dollars, and exists only in the device memory. Prompts go from the device to the model provider with that key. When the key expires, a signed usage receipt settles the metered amount against the private note, rather than the reserved cap. Neither side can rewrite the bill afterward. One authorization can cover a session instead of one proof per call.
The cryptography is specific, and the Foundation names it. Spends are Groth16 proofs on the BN254 curve. Commitments and nullifiers use Poseidon. Notes sit in a Merkle tree 32 levels deep, so a proof can show that a note is one of the valid ones without pointing at it. Each spend publishes a nullifier, a one way serial number derived from the note secret. A second spend of the same balance produces a duplicate nullifier and exposes the attempt, not the user's other activity. The server verifies spend proofs off chain. The vault contract verifies the same kind of proof at deposit, close, and escape, so the exit is not supposed to depend on the server staying honest.
Who is affected
Builders of apps that already speak the OpenAI or Ollama API can point a tool at localhost. The Foundation says the client exposes those standard APIs on the user's own machine, so editors and chat tools do not need a new interface to try the path.
API providers that want this kind of payment would accept a proof instead of a long lived account key and settle signed receipts. Pricing, rate limits, and infrastructure stay with the provider. The Foundation is explicit that integrating means replacing the account relationship, not redesigning the model host.
The intended uses are any service that charges per use. AI chat and agents come first, because prompts are sensitive. The same client and contracts can front blockchain RPC queries, image and video jobs, VPN time and bandwidth, and machine to machine tasks where an agent pays without an account. In each case the payment layer is supposed to hide which note paid, not the content of the request.
The live vault is the ZkApiVault contract on Ethereum mainnet. The Foundation describes it as holding USDC credits. A Sepolia deployment exists for tests. A browser demo, OA Chat, runs without a local install. There is also a proxy mode, where the zkAPI server relays requests to the provider. That mode is easier to operate. The relay sees traffic. The runtime key mode is the one in which the payment intermediary does not see the prompt.
What to do next
Treat this as a privacy control for the billing link, and test it before changing a production key. A team that already sends sensitive prompts to a hosted model can run the local client from the public zkAPI repository, point one internal tool at localhost, and compare the receipt with what the provider dashboard shows.
Do not treat the proxy mode as the private mode. If the server relays the request, it sees the traffic. Use the runtime key path when the point of the trial is to keep the payment intermediary away from the prompt.
Brief legal and security on the two limits the Foundation states in the same post. The gateway can correlate requests that share a stable IP address. Users who want a stronger network barrier are told to route through Tor and to use a fresh circuit for each session. The model provider still sees prompt text. Repeated personal details, writing style, reused conversation history, or project documents can tie sessions back together. Standalone queries are more private and less useful, because past context is missing. A VPN or Tor is a separate layer. Confidential computing for the model is a separate layer. zkAPI does not replace either.
Funds are supposed to remain the user's. The vault is a contract on Ethereum rather than a company account. The Foundation says a user can close a balance and withdraw on chain even if every zkAPI server disappears. A pilot should include that exit, not only a successful prompt.
What to watch
The next verifiable signals are provider adoption and contract use. Watch whether any major inference API documents proof based settlement. Watch whether mainnet vault deposits and closes grow beyond a Foundation demo. Watch whether the Ethereum Research thread records a change to the Groth16, Poseidon, or 32 level Merkle design.
Image: Ethereum Foundation. The official diagram shows the payment server learning that a payment is valid while the model provider sees the request.
Sources
- Primary — Ethereum Foundation, Introducing zkAPI: private usage credits for any API (1 October 2026). Establishes the mainnet launch, the vault flow, the cryptography, the two modes, and the stated limits. Posted by Vittorio Rivabella, dAI Team.
- Primary — Davide Crapis and Vitalik Buterin, ZK API usage credits on Ethereum Research. The design this implementation follows.
- Primary — Ethereum, zkAPI repository. Client, server, and browser SDK.
- Primary — ZkApiVault on Ethereum mainnet. The live vault the Foundation describes as holding USDC credits.
- Secondary — Open Anonymity, project site and OA Chat. The team that built the implementation with the Foundation, and the browser demo.
Related in Blockchain
Continue reading