To use the AI service, one usually needs to register an account first, bind a payment method, and obtain a API key. This key is not only used for fee deduction but also links each call to the same identity. On October 1st, the Ethereum Foundation introduced zkAPI: Users deposit a certain amount onto an Ethereum contract first, and then use zero-knowledge proofs to exchange for short-term usage credentials with a specified amount limit. This allows the billing party to verify that there is funds available to cover the cost of the call, without having to know who deposited the money. The foundation stated that Open Anonymity Project has collaborated with them to complete the client, server, and contract components, and the project is already running on the Ethereum mainnet. While this is a viable implementation, it does not mean that mainstream AI service providers have universally adopted it yet.
The issue raised by zkAPI is very specific. Traditional API keys act as a stable index, which may allow service providers to group years of prompts, consumption limits, and payment accounts into the same profile. For those researching health, financial, or business secrets, the association between bills and requests is inherently sensitive. Completely switching to on-chain payments for every transaction could be slow, expensive, and publicly traceable. zkAPI attempts to separate a single on-chain deposit from multiple offline transactions; the key is not to “pay using blockchain AI”, but rather to prevent the payment trail and the content trail from naturally merging.
One deposit, resulting in multiple short-term calls with a limit on each usage.
According to the foundation's explanation, after users deposit their assets into the Ethereum vault contract, they will receive a private ticket. The client generates a proof for a particular transaction or session, and the server only verifies that there is indeed an available quota for the ticket and that it has not been spent repeatedly; there is no requirement to see the identity of the corresponding depositor. Once the proof is approved, the server creates a temporary key with a maximum amount limit, which is retained in the user's device memory. The application uses this key to send a prompt to the AI service provider, and after the billing is completed, the actual consumption is deducted from the private balance based on the usage receipt.
There are two important anti-cheat mechanisms in this system. The deposit commitment is stored in the Merkle tree, which serves to prove that a certain ticket belongs to a valid set, without specifying which particular deposit it is; moreover, each transaction generates an irreversible empty value marker to prevent the reuse of the same amount. Technical details do not need to be memorized by ordinary readers, but it is important to understand that they serve two purposes: to make it difficult for fraudulent activities such as overdue payments and double-spending to succeed, while also trying not to provide verifiers with any stable clues about the identity of the users involved.
The foundation provides two modes of operation. In the more stringent mode, the user's local client communicates directly with the model provider; the payment intermediary sees the valid amount and total consumption, without seeing the prompts. Naturally, the model provider still sees the prompts and responses they need to process, but they do not have to be informed of the payer's identity by the payment layer. The simpler proxy mode involves requests being forwarded by a zkAPI server, which is easier to deploy, but the relay will see the traffic. Mixing the two modes and claiming that “no participant sees the content” can mislead users about the boundaries of privacy.
There are also practical limitations to anonymity. If users include their names in the prompts or repeatedly submit identifiable project files, model service providers may still be able to identify or associate those sessions from the content. The entry and exit of funds on the blockchain are still public, and the network location and device security of users are not automatically resolved by zero-knowledge proofs. What the foundation is discussing is a reduction in the association between payment identities and call records, not a promise that tracking will be absolutely impossible under any circumstances. The more privacy tools emphasize cryptographic guarantees, the more reports need to clearly explain what they do not cover.
Moving from technical demonstration to service, the only hurdle left is operations.
The project has announced the mainnet treasury and implementation code, stating that the client can provide a local gateway for applications that are compatible with the OpenAI or Ollama interfaces. This means developers have the materials available for testing, review, and development, but it cannot be inferred that all business models will accept this type of settlement. To move to large-scale production, issues such as how service providers will recognize usage receipts, when settlements will occur, how to block abusive requests, how customer support will handle them, and the security audits of contracts and clients still need to be resolved. Anonymous payments weaken the identification of regular accounts, and anti-fraud rules also need to be redesigned.
Placing user assets in contracts rather than on an intermediary account is a core commitment of the scheme. The foundation claims that even if the zkAPI server disappears, users can still close their balances and exit through the contracts. However, the fact that "contracts allow for exit" does not mean that ordinary users can retrieve their funds without obstacles in cases of network congestion or loss of wallets; private key management and on-chain transaction fees remain barriers to use. These factors mean that it may initially attract developers with high privacy requirements, and it is not certain that it will immediately replace all traditional API accounts.
The truly interesting aspect of this project is that it redefines payment authentication from “who are you” to “do you have a quota for this usage?” If service providers are willing to integrate in the future, pay-as-you-go services outside of the AI interface may also adopt a similar approach. However, for now, the confirmed milestones are the implementation of the mainnet, public design, and trial pathways, which do not yet constitute a full industry standard. zkAPI provides an engineering solution between privacy and billing; whether it is reliable and user-friendly will still need to be tested through actual integration, auditing, and long-term operation.
Source: Ethereum Foundation, “Introducing zkAPI : private usage credits for any API”, October 1, 2026, https:// blog.ethereum.org / en /2026/10/01/ introducing-zkapi
