Each call to an artificial intelligence model today carries an identity. The key points to an account, the account to a payment method, and the provider can combine years of usage into a single profile. On October 1, the Ethereum Foundation put a parade online: zkAPI. This is a system that separates payment from identity. The provider sees the requests. The payment layer sees the expense. Neither sees the connection.
The approach is in no way new. Indeed, this follows a research thread presented in February.
Key Points
zkAPI has been live on Ethereum since October 1st, announced by Vittorio Rivabella (dAI team) and built with the Open Anonymity Project
A single deposit in a vault, then zero-knowledge proofs in place of a nominative key: the server issues a temporary, capped key, which only lives in the device's memory
The provider sees the prompts, not the payer. The channel sees the deposit, not what it paid. The IP address and content of requests remain exposed
The drawing dates from a thread by Davide Crapis and Vitalik Buterin published on February 11, 2026 on ethresear.ch. Cointelegraph covered it on the 12th
The problem, as posed by the foundation
On October 1, the Ethereum Foundation unveiled zkAPI, a new way to pay for APIs.
“zkAPI lets you pay for AI and other APIs with ETH and make unlinkable requests. It separates API usage from your on-chain deposit: the service can verify that you are able to pay without knowing which deposit belongs to you. »
Under the hood, the protocol was built with the Open Anonymity Project. “Every AI API call today carries an identity,” he writes. The API key designates an account, the account a payment method, and each prompt joins the folder attached to both. The classic alternative, paying for each request on-chain, is slow, expensive, and leaves a transaction graph. The zkAPI solution offers a different method with prepayment, then authorizations that do not designate anyone.
You deposit credits once, in ETH or USDC, into an Ethereum vault. The balance becomes a private note, which only the holder can spend, and which cannot be traced back to the deposit. To authorize a spend, software on the machine produces a zero-knowledge proof: a funded bill covers that amount, and no one has already spent it. The server checks the statement without learning which note, which deposit, or which person.
The route described on October 1 takes place in four stages. The application talks to a small client on the user's machine, with the same interface as before. This client sends proof of payment to the zkAPI server, without prompt and without identity. The server verifies the proof and issues a new, short-lived, dollar-capped API key. It only exists in the device's memory. The prompts then go from the device to the AI provider, with this key. Upon expiration, a signed receipt records actual consumption, and the server debits the private balance for that amount, not the reserved limit.
The ceiling therefore serves as a reservation. Spend proofs are verified off-chain in Groth16 on the BN254 curve, with Poseidon for commits and nullifiers. These nullifiers prevent you from spending the same note twice. The safe deposit contract verifies the evidence at deposit, at closing and in the event of forced exit.
The vault is an Ethereum contract, not a business account. You can close the balance and withdraw on the chain, even if the zkAPI servers disappear.
Where does the drawing come from?
The idea dates from February 11, 2026. Davide Crapis, head of AI at the foundation, and Vitalik Buterin published the thread “ZK API Usage Credits: LLMs and Beyond” on ethresear.ch. The text first aims at inference of large language models, where the user sends personal data, but also Ethereum RPC calls, image generation, computation, VPNs and data APIs. The thread example: 100 dollars of USDC deposited, 500 requests to a hosted model, which the provider cannot link to the same depositor.
It is not yet the October protocol, it is only the specifications. The launch turns the February drawing into implementation. It does not include all the mechanics, in particular the flow limit nullifiers and the slashing mechanism towards a burning address described in Crapis and Buterin's thread.
What the evidence does not hide
The foundation is explicit on the border. The zkAPI server learns that a valid payment exists, and the session dollar total. The AI provider learns the prompts and responses, not who pays. The channel sees deposits, closings and withdrawals, not what balances have paid out.
It does not hide the IP address or the content. A stable IP allows the server to cross-reference sessions. The post suggests Tor, with a new circuit each session. The text of the prompt can also tie the sessions together: a personal detail, a style, a reused history. The advanced solution is a local model, or in a trusted execution environment, with shared memory, rather than returning everything by hand. Isolated requests that are more private, but less useful without context: the compromise is accepted.
