zkAPI uses Ethereum deposits and zero-knowledge proofs to separate payment credentials from AI API activity. Reports describe it as live on Ethereum mainnet but experimental; providers can still read prompts, and network patterns may expose users.
A developer calling an AI model still sends the prompt to its provider. zkAPI aims to obscure the link between payment credentials and API usage, not to hide conversations from the provider. That boundary matters to developers and users weighing whether blockchain-based payments can reduce the personal data tied to routine model calls.
Privacy boundary
Independent reports say zkAPI was introduced on October 1, 2026, and launched on Ethereum mainnet. Project materials associate its development with the Open Anonymity Project and the Ethereum Foundation. Available reporting does not include independent confirmation from the Foundation. The project is described as experimental.
zkAPI descriptions say users can deposit ETH, USDC, or DAI into a Vault and prove they have sufficient payment capacity without revealing the specific funding record to the API provider.
That is a narrower claim than anonymous AI. A model provider still processes the prompt and response. IP addresses and request timing may expose information about a user; repeated usage patterns can do the same. Identifying details in a prompt may also reveal who sent it. zkAPI does not provide end-to-end encrypted inference or network anonymity.
Payment privacy also leaves open what obligations apply to a crypto product or token. A proof can verify a payment condition, but it does not determine legal status. That distinction matters in light of recent SEC guidance on how crypto activity may be treated under securities law.
How payment proofs work
Users deposit ETH or USDC into a Vault smart contract. DAI and other supported assets are accepted too. The balance is represented by a Private Note, a cryptographic credential controlled by the user and used to prove payment eligibility. Commitments to valid credentials are organized in a Merkle Tree. That lets a user show that a Note belongs to an approved set without identifying the specific Note. An OKX project overview also describes temporary API keys with spending limits and pay-as-you-go access.
zkAPI is described as supporting temporary API keys with an expiration period and a spending limit. Reported integration scenarios include OpenAI-compatible interfaces and Ollama.
When an API call is needed, the client generates a proof that the Note is valid and has sufficient credit under the protocol's conditions. The payment server checks the proof, then can issue a temporary API Key with an expiration period and spending limit. A Nullifier, a unique identifier derived from secret information, helps detect repeated spending of the same credit without exposing the credential itself.
The published implementation uses Groth16 proofs and the BN254 curve. It also relies on Poseidon hashing, while Merkle Trees organize the credentials. These components support verification and double-spend prevention, but they add complexity to account-based billing. Clients must generate proofs, and servers must verify them. The payment flow must also reconcile usage without allowing a balance to be spent twice.
Settlement and trade-offs
Rather than putting each model request on-chain, zkAPI lets users fund the Vault in advance and authorize API access off-chain. In the Runtime-Key model described in project materials, prompts go directly to the AI provider. The payment server checks eligibility and handles billing. After a session, signed usage records determine the actual charge, so a temporary key's spending limit is a reservation ceiling, not an automatic charge for the full amount.
A separate Proxy mode relays requests through a proxy server. That may simplify integration, but the proxy can see request traffic. The arrangement changes the privacy boundary and the network trust assumptions. Users and developers need to assess the actual deployment path rather than treating every zkAPI setup as equivalent.
Public reporting describes a mainnet launch on October 1, 2026. Project materials refer to client and server implementations, along with smart-contract implementations. The project grew from a ZK API Usage Credits design proposed by Vitalik Buterin and Davide Crapis. Its implementation is described as experimental. A mainnet deployment and public code do not establish broad adoption or the security maturity of a commercial billing system. Available reporting also provides no independent code audit. It contains no usage statistics or confirmed payment volumes.
For AI agents, temporary keys and predefined spending limits could support automated pay-per-use access to models and other services. Privacy does not stop a misconfigured agent from consuming its budget. Abnormal calls can run through it too. Developers still need session budgets and service allowlists. They also need usage monitoring. Proof generation and credential reuse remain implementation challenges, as do quota management and billing disputes.
zkAPI's stated use is specific: weaken the direct connection between an on-chain funding identity and API billing records without putting each call on Ethereum. Deposits and withdrawals remain public blockchain transactions. In the Runtime-Key design, the model provider still sees prompts. IP addresses and request timing can affect how readily activity is linked; recurring request patterns and proxy handling matter too. Proof generation remains an implementation challenge.
