zkAPI addresses a specific problem with metered artificial intelligence: paying for a service without automatically attaching every request to a billing identity. Its use of zero-knowledge proofs does not, by itself, make the content sent to a model anonymous.
There is also an important software-status distinction, checked on October 26, 2026. The Ethereum Foundation’s October 1 announcement describes a mainnet service, while the current development branch warns about components and deployment configurations that are not production-ready.
zkAPI separates questions that often get bundled together
The Ethereum Foundation announcement describes separating spending authorization from the identity behind a deposit. The inference provider still receives the request it needs to process: payment privacy is not the same property as prompt confidentiality.
That changes what a user should ask. Rather than accepting a general claim that a chat is private, identify who receives the content, who handles the money, and who might reconnect those two records through other information.
An application can remove one link while leaving another untouched. If a request contains a person’s name, employer and internal document, a less identifiable payment method cannot remove those details from the text the provider sees.
A research proposal is not a release specification
ZK API Usage Credits by Davide Crapis and Vitalik Buterin explores combining payment, privacy and abuse resistance. It provides research context, not a specification that can automatically be applied to every later software revision.
This distinction prevents a common evaluation error: treating a theoretical diagram, an interactive demonstration and an active contract as interchangeable evidence. Each establishes something different and leaves different questions unanswered.
Research explains the objective. Code shows how a particular version attempts to meet it. A verified deployment identifies the system a user can actually interact with. A meaningful security assessment needs an explicit connection between all three layers.
The version you use is the decisive detail
The official repository, checked on October 26, calls the protocol experimental and warns that its privacy-enabled client development branch is not a production release. It also identifies undeployed configurations for the current revision and a separate release line for earlier notes.
Those warnings do not establish that the original announcement was false or that every earlier service has stopped. They do establish that downloading the main branch is not automatically equivalent to using the service described at the beginning of the month.
Before considering real funds, identify the release, network, contract address and corresponding documentation. If one of those references is missing, stopping is appropriate. It is not a reason to bypass deployment checks or improvise a different configuration.
What to evaluate before trusting a privacy claim
| Question | Correct interpretation | Useful check |
|---|---|---|
| Are payments separated from requests? | That is the protocol’s objective | Inspect the actual version |
| Can the model read the prompt? | Payment privacy does not prevent this | Minimise transmitted data |
| Is the main branch production-ready? | Do not assume it is | Read release warnings |
| Is a deposit risk-free? | No | Assess contracts, clients and exit procedures |
Our discussion of wallet RPC privacy and security provides a useful comparison. Information can be protected at one layer and remain observable to another service involved in the same activity.
A realistic example without an anonymity promise
Consider an assistant classifying public product descriptions within a limited budget. Separating the payment source from individual tasks could be valuable if the chosen service and software release genuinely support that path.
Now consider an assistant handling confidential contracts. The main concern may be the material being transmitted, rather than the billing record. That case should be compared with local processing, suitable data agreements and document minimisation, not just an alternative way to pay.
This is an evaluation scenario, not an integration test performed by our newsroom. We have not deposited money, tested withdrawals or measured the system’s resistance to linking sessions.
Questions to resolve before a trial
Start by defining the boundary: which party should be prevented from connecting payment and usage? Then identify the information included in each request and the data retained by the local client.
Operational questions follow. How is local state protected? What happens if the device is lost? Which documented procedure recovers a remaining balance for the selected version? A general explanation of cryptography cannot substitute for these answers.
Spending limits and failure handling also matter. An application should not silently switch to a less private route because the preferred method is unavailable. Such a fallback might change the user’s exposure at precisely the moment the interface appears to be working normally.
Why this is infrastructure, not an investment thesis
zkAPI is interesting as an attempt to change the relationship between service access and economic identity. Discussing that possibility does not require a prediction about Ethereum’s price or a claim that deposits generate returns.
The relevant standard is the same one described in our coverage of crypto privacy and legitimate use: define the risk, verify the limits and choose proportionate safeguards.
For now, the most important caution is not to confuse a promising design direction with a guarantee established for every implementation. A useful trial begins with version evidence and a bounded task, not with a broad assurance that everything has become anonymous.