An Ethereum Foundation blog post on 1 October introduced zkAPI as a way to separate payment authorisation from billing identity for metered APIs. The authors also distinguished that payment privacy from the information an API provider can still observe.
The announced design has a specific privacy boundary
The post says the Open Anonymity Project built zkAPI with the Ethereum Foundation and that the implementation runs on Ethereum Mainnet. It describes vault-based credits, zero-knowledge spending proofs and short-lived API keys with bounded usage. These are claims from the project’s technical announcement. Ethereum Foundation Blog — zkAPI usage-credit announcement
The authors explicitly identify limitations: a provider still sees request contents and network metadata, including an IP address, and may correlate sessions. The simpler proxy mode also lets the relay observe traffic, unlike the described direct runtime-key route. Ethereum Foundation Blog — zkAPI usage-credit announcement
Avoid collapsing several privacy claims into one
WFN analysis: privacy reporting needs to identify the observer. Hiding a funding link from one participant does not establish that every participant is unable to associate requests, or that sensitive content is concealed from the service processing it.
The deployment claim needs equal care. This article reports what the developers announced; it does not present an independent audit, a measurement of user adoption or proof that every service marketed under the name follows the same implementation.
For a payments or brokerage technology desk, the practical question is which information each component handles. Architecture, network behaviour and the content of requests belong in separate parts of that assessment. A broad anonymity label would obscure the distinction that makes the source useful.
Review the route actually used
Check the documented mode, deployed contract identity, operational permissions and applicable service terms before drawing conclusions about a particular integration. Compare the implementation with the announcement rather than relying only on a project name.
Any stronger privacy claim should specify its threat model and supporting evaluation. The verified event is publication of the project’s explanation, including its limitations; this article supplies no adoption forecast or investment valuation.