On October 1, 2026, the Ethereum Foundation introduced zkAPI as a way to separate prepaid API usage from the identity attached to its funding. This does not make the content of an API request private from the provider processing it. Before funding a service, also identify its exact deployment: the announcement, current protocol documentation and a development branch do not necessarily describe interchangeable wallets or supported assets.
What was introduced
The Foundation’s announcement describes work by Open Anonymity in collaboration with the Foundation and reports an Ethereum mainnet deployment. The intended use is metered access: a client proves it has funded credit without attaching the funding identity to each request. That is a particular payment-privacy claim, not a statement that all AI usage or all Ethereum activity becomes private.
A practical example is a person who wants a usage-based API bill without tying every session to the same conventional billing account. The question they should ask is which link the system reduces, and which information remains visible. Replacing a payment credential does not rewrite the document or personal details they place in a prompt.
Follow the data, not the word “private”
| Part of the interaction | What needs separate attention | Question before use |
|---|---|---|
| Funding and withdrawal | Public on-chain activity | Which exact vault and asset does this version use? |
| Authorization of credit | Proof and deployment compatibility | Do client and verifier belong to the same protocol version? |
| Request processing | Content seen by the upstream provider | Am I sending information I intend that provider to receive? |
| Network connection | Observable network and timing metadata | What does the documented privacy model leave outside the proof? |
| Local wallet state | Secrets and recovery information held locally | What does this particular client require for continued access? |
The current introduction makes the boundaries explicit: public deposits and withdrawals remain observable, network and timing metadata are outside the proof, and the upstream service sees prompts. Consequently, a user should not treat payment unlinkability as a confidentiality policy for the content. This article does not claim that any provider deletes prompts, stops logging or meets a particular retention standard.
Read “live deployment” and “development branch” separately
The project repository, checked on October 27, calls the protocol experimental and describes a privacy-enabled client development branch that is not a production release. That branch warning should not be silently converted into a claim that the mainnet deployment reported on October 1 never existed. The useful conclusion is to match the actual client, documentation and deployment instead of treating every current file as a ready replacement.
The announcement mentions broader funding examples, while the current protocol documentation specifies native ETH for its SDK and vault. A reader must resolve which version and deployment they are using before sending an asset. Do not infer that a USDC balance, a legacy wallet bundle and a current ETH-based client are interchangeable because their pages share the zkAPI name.
The same compatibility question applies to proof artifacts. The documentation says deployment keys and circuit compatibility must match; hashes identify artifacts, while its stated setup assumptions require separate consideration. It also states that the checked-in setup has not had a multiparty ceremony. This is not an independent audit opinion or a prediction of a loss, and a matching hash should not be described as proof of setup security.
A reservation is not an instruction to pay every request on-chain
The protocol documentation distinguishes authorization and off-chain usage settlement from the eventual on-chain close. That is why an API request and a new public funding transaction are not interchangeable billing records. For a user comparing two services, ask how a spending bound, measured usage and remaining balance are represented in the specific version, rather than assuming the advertised cap is always the final charge.
There is no universal current price, withdrawal deadline or list of supported models asserted here. Nor does this report test a withdrawal or recommend putting production funds into an experimental client. The news value is the deployed payment model and its boundaries, not a promise that a privacy label removes operational decisions.
A short check before choosing a route
- Start from the repository and documentation linked by the project announcement, avoiding a similarly named service found by name alone.
- Identify the client release, chain, vault, supported funding asset and protocol version before any transfer.
- Read which parties receive request content and which metadata the proof does not cover.
- Check the documented spending and withdrawal model for that deployment without assuming a different version’s wallet is compatible.
If you need a different asset first, compare supported coins and networks with the requirements you have actually verified. A simple swap and its exchange instructions are a separate transaction flow. KOT.CASH is not described here as a zkAPI partner or integration, and acquiring an asset does not establish compatibility with an API vault.
FAQ
Does Ethereum zkAPI hide the text I send to an API?
The provider processing the request still receives its content. Payment privacy and the provider’s handling of prompts are separate questions.
Can I fund any Ethereum zk API version with the same token?
Check the particular SDK, vault and protocol version. The current protocol documentation specifies native ETH, so a broader launch example does not establish compatibility.
Does an Ethereum zk API repository mean every current branch is production-ready?
No: the repository explicitly distinguishes an experimental development branch from production release status. Match the client and deployment rather than assuming every checked-in artifact is ready for use.