The October 1 launch hid the payer. It did not hide the prompt.
@ethereumfndn posted at 20:14 UTC. The caption calls zkAPI a new means for private AI. Deposit ether into a vault, sign a zk proof, get a fixed amount of private inference. When I read it, that post had 301,666 impressions and 1,321 likes. Eleven minutes earlier @kenziyuliu had already said what the protocol does. It is for accessing gated or paid APIs with unlinkability. He wrote that it is like a generalization of OA unlinkable inference that also abstracts payments away. That post had 154,209 impressions and 389 likes. @DavideCrapis quoted the foundation at 20:34 UTC. The design with @VitalikButerin was the start. The Open Anonymity team built it. His longer text says more is coming “to enhance user sovereignty and privacy in the age of AI.”
The page under those posts is Vittorio Rivabella’s, dAI team, same day. The summary’s first line is the product. zkAPI lets you pay for a metered API without being known. The next lines are the limit. The provider sees the requests. The payment layer sees the spend. Neither learns the link between them.
What the proof covers
You deposit once. ETH or USDC, one transaction, into a vault on Ethereum. After that the balance is a private note. Software on your machine produces a zero-knowledge proof that some funded note covers this spend, and that the note has not been spent before. The proof does not name the note, the deposit, or the person. The server checks it and mints a short-lived API key with a dollar cap. The key stays in memory on the device. Prompts go from the device to the model provider with that key. When the key expires, a signed receipt reports what the session used, and the server deducts that amount from the note instead of the reserved cap.
The double-spend check does not need your name. Deposits sit as commitments in a Merkle tree, 32 levels deep, so a proof can say the note is one of the valid ones without pointing at it. Each spend publishes a nullifier, a one-way serial number from the note’s secret. Stay inside the balance and the spends do not link to each other. Spend the same balance twice and the duplicate nullifier shows the attempt, and nothing else. Spend proofs are Groth16 on BN254. Commitments and nullifiers are Poseidon hashes. The server verifies spend proofs off-chain. The vault verifies the same kind of proof at deposit, close, and escape. A withdrawal does not depend on the server still being there.
The repo at github.com/ethereum/zkapi calls the protocol experimental. The blog points at the live vault, 0x4386fdbda35d995beb3bf8625118ec5982ec81fe, and says it holds USDC credits. I have not checked the balance. A Sepolia deployment has the same contracts with test funds. The client exposes the OpenAI and Ollama APIs on localhost, so an app you already use can point at it. There is a simpler proxy mode where the zkAPI server relays the request to the provider. Rivabella writes that the relay sees traffic. The runtime-key path is the one where the payment server does not.
This is the February 11 design, not a new theory of what a model may keep. Davide Crapis and Vitalik Buterin posted “ZK API Usage Credits: LLMs and Beyond” on Ethereum Research that day. Their example is a 100 USDC deposit and 500 queries the provider cannot tie back to the same depositor. The October 1 post is that design on mainnet.
What the provider still has
The zkAPI server learns that a valid payment exists, and the dollar total for a session. It does not learn who you are, what you asked, or which deposit paid. Ethereum sees deposits, closes, and withdrawals. It does not see what a balance paid for. The AI provider learns the prompts and the responses, because it runs the model. It does not learn who is paying.
The company running the model still gets the prompt and the answer.
The limitations section names two holes. No network anonymity. Leakage through what the prompt contains.
On the network side, the gateway can correlate requests if you keep sending them from a stable IP. The post says to use Tor, and a fresh circuit for each session, if you want more than that. An IP is not a billing name. It is still an address the gateway can sit on. The post does not claim to remove it.
On the content side, the inference provider can tie sessions back together when the same personal details, writing style, reused conversation history, or project documents show up again. The post says shared prompt contents can act as fingerprints for anyone who can read the prompts. Standalone queries leak less and help less, because the past context is gone. One mitigation they mention is a local or TEE model writing the outbound request from shared memory, so you are not the one pasting the identifying parts into the provider’s box.
That line is not in the announcement posts. If the context that makes the answer useful is also the context that identifies you, unlinking the bill does not unlink you. The provider does not need your old API key for that. It needs the paragraph.
Proxy mode adds a second reader. The relay sees the traffic. Runtime-key mode keeps the payment server off the content. Neither mode keeps the model company off it. OA Chat at chat.openanonymity.ai is the no-install client. I have not used it. The blog is what I am using for what it hides.
The caption and the table
@ethereumfndn’s line is deposit, proof, private inference. Private, in the post under that line, means the payment layer cannot attach the session to a deposit. It does not mean the model company cannot read the session or keep it. The post never says what that company does with the prompt after it answers. zkAPI stops the invoice and the transcript from sharing a customer id.
Rivabella’s opening is the part that holds. An API key points at an account, the account points at a payment method, and every prompt joins the record attached to both. Years of use become one profile because the bill has a name. Cutting that join is the product. It is not a receipt that the prompt was never stored.
If someone tells you zkAPI made the chat private, ask who still receives the prompt, and whether the text repeats a name, a project, or a style that provider has already seen. If the answer is the model company, and yes, the proof did its job. The transcript is still a copy.
The February note already said the provider gets valid paid requests and cannot link them to the depositor. It did not say the provider forgets the requests. The October 1 post says the same thing in a table, under a caption that says private AI.