zkAPI Makes API Billing a Zero-Knowledge Session Primitive

The Ethereum Foundation and the Open Anonymity Project have introduced zkAPI, an experimental protocol for paying for metered APIs without exposing the payment identity behind each request. The system is live on Ethereum mainnet and is presented first for AI inference, but its design also targets RPC calls, image generation, bandwidth, and other usage-priced services.

The key idea is to turn a prepaid balance into a private note. A user deposits funds into a vault, then produces a zero-knowledge proof showing that a valid note can cover a bounded session and has not already been spent. The server verifies the proof without learning which deposit or person funded it. A nullifier prevents double spending, while a Merkle tree lets the proof establish membership without identifying a particular note.

The implementation separates the payment path from the request path. A local client proves authorization to the zkAPI server, which issues a short-lived, spending-limited API key. In the runtime-key mode, the user’s device sends prompts directly to the provider. When the key expires, signed usage information is used to settle the actual cost rather than the reserved cap. The repository documents a stack built around Groth16 on BN254, Poseidon hashing, note-bound commitments, and a 32-level Merkle tree.

That separation is the more interesting developer primitive than the AI demo. An ICP application that calls a metered external service could, in principle, treat “permission to spend up to this amount” as a proof-bearing session capability rather than attaching every request to a durable account. The application would still need an appropriate verifier, settlement service, and key-management design; zkAPI does not provide an ICP integration, and this is an architectural inference rather than a released ICP feature.

There is an important privacy boundary. zkAPI breaks the link between payment and usage, but it does not make the request itself anonymous. The provider can still see prompts and responses, the user’s network metadata may remain visible, and timing or repeated content can correlate sessions. The Ethereum Foundation explicitly describes network anonymity and content privacy as separate layers.

For ICP developers, the practical takeaway is to model three independent questions: who is authorized to spend, what service receives the payload, and who can reconcile the bill. Zero-knowledge proofs can separate the first and third from the second, but only if the session key, usage receipt, replay protection, and recovery path are treated as protocol state. That boundary is portable; the current zkAPI deployment is not yet an ICP component.