Written by Ralph Sun
The Ethereum Foundation’s October 1 launch of zkAPI is a narrow protocol experiment with a potentially useful split: paying for a metered API without directly tying the payment identity to the request identity. Built by the Open Anonymity Project with the Ethereum Foundation, zkAPI is described as live on Ethereum mainnet. Its purpose is not to place prompts on-chain or to make all API traffic anonymous. It is to create a private-note credit path for authorization and settlement while leaving the actual content request on a separate path.
The documented flow has four parts. A user deposits credits into an Ethereum vault. A local client proves that it controls a funded, unspent private note. A zkAPI server issues a short-lived, dollar-capped API key. When that key expires, a provider-side signed usage receipt is used to deduct the metered amount from the private balance. In this design, a proof and a nullifier establish the right to spend without publicly disclosing which deposit funded a particular request.
The project says the active construction uses Groth16 over BN254, Poseidon commitments and nullifiers, and a 32-level Merkle tree. The official repository further describes note-bound Baby-JubJub commitments and Schnorr signatures. Those primitives are relevant because they define the system’s payment-authorization proof, not because they magically remove all identifying signals from use of an API. The protocol is expressly labelled experimental.
Current official documentation describes funding a private note with native ETH, then receiving short-lived OpenRouter keys. It says prompts and responses remain between the application and OpenRouter, while the payment server handles authorization and settlement. A remaining ETH balance can be withdrawn by closing the note. The source set uses broader “credits” language in one place, but the currently documented native-ETH flow is the verified configuration. It would be premature to state that USDC funding is presently available.
The on-chain portion is real but limited evidence. The vault address cited by the project was successfully created in Ethereum block 26,091,339 on September 30; the deployment record corroborates that a contract was created at the named address inside the required news window. It does not show user count, provider count, API volume, successful withdrawals, privacy outcomes or surrounding-service resilience. Contract creation is a deployment fact, not a usage metric.
The privacy boundaries deserve as much attention as the cryptography. The Foundation says zkAPI does not provide network anonymity: a gateway may correlate activity from a stable IP address, and users seeking stronger network privacy may use Tor. Providers can also relink sessions through prompt content, writing style, reused context or uploaded project documents. Separating payment identity from request identity is useful, but it is only one layer of a privacy model.
The implementation’s own test posture reinforces that caution. Its documented full-lifecycle acceptance test uses mocked provider and oracle components, even though the protocol services, wallet proofs and contracts are real. That is not an independent production security audit and does not demonstrate that every provider integration behaves as intended under live load or adversarial conditions.
zkAPI is therefore best understood as a new payment-authorization architecture for metered services: Ethereum settles deposits and exits, while local proofs authorize credits without exposing the funding note. The follow-up questions are practical: Which providers support it, how reliably can users exit, how do gateways log activity, and can the system withstand correlation and tampering attempts? The launch answers none of those at scale. It establishes an experimental mainnet implementation, not universal API privacy or a proven commercial standard.
