Vitalik has published two pieces in the past two months that together make the case for why AI agents need cryptographic privacy at the payment layer. Nobody else has laid it out this clearly.
The first, co-authored with Davide Crapis (the EF’s AI lead) on ethresear.ch in February, proposes a protocol called ZK API Usage Credits. The premise: when a user or agent calls an LLM API, they currently have to choose between identifying themselves (email, credit card, full surveillance) or paying per request on-chain (slow, expensive, every call traceable). The post describes a system where you deposit funds into a smart contract once and then make thousands of API calls anonymously, using rate-limit nullifiers so honest users stay unlinkable while double-spenders get slashed.
The second, published April 2, is more personal. Vitalik describes abandoning cloud AI entirely and running a local Qwen 3.5 model on his (pretty powerful) laptop. He cites research showing 15% of AI agent skills contain malicious instructions. He built a messaging daemon that requires human approval before his AI can contact anyone. He recommends wallet teams cap autonomous AI spending at $100/day and require human confirmation for anything above that or anything carrying calldata that could exfiltrate data.
Both posts are focused on Ethereum. The ZK API Credits protocol settles on Ethereum smart contracts. The wallet recommendations assume Ethereum’s tooling and account model. The Privacy Cluster, the 50-person team behind Kohaku, is an Ethereum Foundation initiative. But the problem they’re describing exists on every EVM chain.
The problem is chain-agnostic
The ZK API Credits post lays out the tradeoff directly: API providers currently force users to choose between identity-based access (Web2, full surveillance) or on-chain per-request payments (traceable, expensive). The proposed solution uses Ethereum smart contracts as the settlement layer for anonymous deposits and ZK-verified usage.
But the agents paying for these API calls don’t live on Ethereum mainnet alone. An AI agent managing a DeFi portfolio might execute trades on Arbitrum, bridge through Base, settle payments on Polygon, and hold treasury on Ethereum. An agent paying for computation through x402 might route transactions across whichever chain has the lowest fees at that moment. Real agentic infrastructure is already multichain by default. Agents optimize for cost and speed, so they don’t stick to one network.
The privacy leak Vitalik describes applies identically on every chain. If your agent’s API payments are visible on Arbitrum, a competitor can reconstruct your usage patterns just as easily as on Ethereum mainnet. If your agent’s trades are transparent on Polygon, front-runners can exploit them the same way. The chain doesn’t matter. The transparency does.
Yet the solutions being built are almost entirely Ethereum-first. Kohaku targets Ethereum mainnet and eventually some L2s. The ZK API Credits protocol deposits into Ethereum smart contracts.
If you’re building on Base, BSC, Gnosis, or any other chain the question becomes: who is building your privacy layer?
What the ethresear.ch commenters got right (and wrong)
The discussion under the ZK API Credits post is worth reading in full because it surfaces the real objections. So make sure to check it out.
One commenter called it “a solution in search of a problem” and argued that anyone who truly wants privacy will run inference locally. A direct push-back followed: hosting a LLM locally costs around $50,000 in hardware, and most users can’t justify that for everyday use. The economics of shared inference mean most agents will call remote APIs for the foreseeable future. Local-first is a fine principle, but it doesn’t scale to most real-world agent deployments.
One of the ML engineers made a more technical point: the refund mechanism in the protocol leaks information through timing metadata. Output token count, time-to-first-token, generation latency, speculative decoding acceptance rates. Over enough requests, traffic analysis can re-link anonymous calls to the same user even with perfect nullifier unlinkability. He cited a documented timing side channel in vLLM’s prefix caching that achieved near-perfect accuracy distinguishing whether two requests shared context.
This is the kind of detail that matters. The cryptographic layer can be perfect and the privacy still fails because of metadata leakage at the infrastructure level. Vitalik’s own April 2 post acknowledges this implicitly: he stores Wikipedia dumps locally to avoid leaking his research interests through search queries. He routes nothing through external services that he doesn’t absolutely have to.
The point extends well beyond Ethereum. Privacy is a system design problem. ZK proofs handle one layer, but timing metadata, transaction graphs, IP addresses, RPC provider logs, and on-chain amount correlation all leak information through channels that the cryptography doesn’t touch.
Where Curvy sits in this picture
We’ve been working on this problem for two years, and our starting point was the same observation Vitalik arrived at: the payment layer is the critical privacy weak point for agents.
But we made a different scope decision. Instead of building a protocol that settles on Ethereum and works backward from there, we built middleware that works across eight EVM chains from the start. The reasoning was straightforward: agents don’t stay on one chain, and a privacy layer that only covers Ethereum mainnet leaves the rest of the transaction graph exposed.
Curvy’s SDK handles private payments at the infrastructure level. Shielded notes hide amounts, stealth addresses break sender-recipient links, and ZK proofs verify state transitions without revealing private data. The Portal system means the sender doesn’t need to install or use anything new; they send to an address from whatever wallet they already have, and privacy happens automatically on the receiving side.
The compliance question matters here too. One of the ethresear.ch commenters argued that society won’t allow anonymous agents to transact freely, and that KYC/AML is unavoidable. He’s probably right about the regulatory trajectory. That’s why Curvy has viewing keys and KYT/AML hooks in the SDK from the start. Agents shouldn’t be unaccountable. But they also shouldn’t have to broadcast every transaction to get permission to operate.
The ZK API Credits proposal is good cryptography. But it solves one specific slice: anonymous metered billing for API calls on Ethereum. An agent operating in the real world needs privacy across payments, treasury management, trade execution, and API billing, on multiple chains simultaneously. That’s a full stack, not a single protocol.
What this means for builders on other chains
If you’re developing agentic infrastructure on any EVM chain, the Vitalik posts are worth reading as a design document, not just as Ethereum-specific proposals.
The core principles transfer directly. Agents need to be able to pay for services without creating a permanent, public record of every interaction. Identity-based billing is a surveillance layer that agents shouldn’t have to accept. Per-request on-chain payments create traceable graphs that competitors can exploit. The answer involves some form of anonymous, prepaid, ZK-verified payment mechanism.
The implementation, however, can’t be Ethereum-only. An agent that’s private on Ethereum mainnet but transparent on Arbitrum hasn’t solved the problem. It’s just moved the observable surface to a different chain.
This is the gap we’re building for. The Ethereum-focused work is directionally right, but the scope needs to be wider and the timeline shorter. Agents are already transacting across multiple chains. The privacy layer should already be there.
Curvy is a privacy middleware for agentic payments. Documentation at docs.curvy.box.
The Vitalik/Crapis ZK API Usage Credits post: ethresear.ch
Vitalik’s self-sovereign AI setup post: vitalik.eth blog, April 2, 2026