zkAPI Is Turning API Access Into Private Usage Credits

Most privacy tools begin with the content: encrypt the message, hide the sender, obscure the network route. zkAPI starts with something easier to overlook — the bill.

On October 1, 2026, the Ethereum Foundation and the Open Anonymity Project launched zkAPI on Ethereum mainnet. The system lets a user fund API usage in advance and later prove that a session can be paid for without presenting a persistent billing identity or exposing which onchain deposit funded the request.

AI inference is the first visible use case. There is already a browser-based implementation through OA Chat, as well as a local OpenAI-compatible client. But treating zkAPI simply as a private AI chatbot feature misses the more interesting part.

The primitive being tested is accountless, privacy-preserving metered access. Instead of an API key permanently tying requests, billing and identity together, payment becomes a separate layer that can answer a narrower question: is this usage authorized and funded?

API keys quietly do too many jobs

A conventional API account usually bundles several functions together. The provider needs to know which customer is making a request, whether the account is allowed to make it, how much the request costs, how much the customer has already spent and where the bill should go.

That is operationally convenient, but it also creates a durable relationship between usage and identity. A long-lived key can become a history of what models someone queried, what data they requested, what tools they used and when they used them.

Putting every payment directly onchain does not solve the problem particularly well. A transaction for every model call or RPC request would create a different kind of visible history while introducing latency and transaction costs into something APIs normally meter continuously.

What zkAPI actually does

The system separates the funding event from the later service session.

• 1 Fund a private balance A user deposits funds into an Ethereum vault. The current public documentation describes native ETH settlement.
• 2 Hold a private note The client maintains the spending state privately rather than exposing a conventional customer balance to every service request.
• 3 Prove authorization A zero-knowledge proof demonstrates that a valid funded note can cover a bounded amount of usage without identifying the underlying deposit.
• 4 Settle actual usage A short-lived service key handles the session, and the private balance is charged for metered usage rather than requiring an onchain transaction for every request.

The Ethereum Foundation describes deposits as commitments inside a Merkle tree and spending attempts as carrying nullifiers: one-way values that prevent the same private state from being spent twice. The current implementation uses Groth16 proofs over BN254, Poseidon-based commitments and a 32-level Merkle tree.

The cryptography matters, but the architectural division is simpler than the implementation: the payment side should know that valid money exists, while the service provider should not need the funding identity behind a temporary key.

Why now?

The idea itself did not appear in October. Davide Crapis and Vitalik Buterin published the underlying “ZK API Usage Credits” proposal on Ethereum Research in February 2026. At the time, it was framed around a problem that extends beyond LLMs: how can someone deposit once and consume a high-frequency digital service many times without either maintaining a Web2 identity or generating an onchain payment trail for every request?

What changed is that the proposal has become runnable infrastructure.

There is now a mainnet implementation, a public repository containing the client, browser SDK, server components and contracts, a local client that exposes an OpenAI-compatible interface, and a user-facing implementation inside OA Chat. Existing software can in principle talk to the local client instead of redesigning its interface around a crypto wallet.

That moves zkAPI into a more interesting category. It is still experimental, but it can now be evaluated as software rather than only as a research construction.

What is actually new here?

Private payments are not new. Zero-knowledge proofs are not new. Prepaid API credits are certainly not new.

The useful combination is that zkAPI attempts to preserve the economics of a metered API while removing the need for the billing identity to travel with every request.

This distinction becomes more interesting once the customer is software rather than a human.

An autonomous agent may consume model inference, RPC calls, search, databases, storage and specialized APIs from multiple providers. Requiring a conventional account, permanent credential and billing profile for every service creates an identity layer around machine activity that may not always be necessary.

A private usage-credit primitive suggests another model: software acquires bounded purchasing capacity and proves the right to consume a service when needed.

That does not automatically create a machine-payments standard. But it is a direction worth watching.

Signals to watch

Who should pay attention?

Privacy-focused applications have the most immediate reason. Private messaging or private inference is weaker when payment and account infrastructure rebuild the identity trail somewhere else.

AI-agent developers should watch the model for a different reason. Agents increasingly need controlled access to paid external services. A portable, bounded spending right could eventually be easier to reason about than giving autonomous software a collection of permanent customer accounts and API credentials.

RPC, data and infrastructure providers may be the more revealing test. These businesses already sell high-frequency metered access, sometimes to software that has little inherent need for a human-style profile.

And crypto payment builders should notice the inversion: the blockchain is not being proposed as the execution environment for every API interaction. It is being used as the settlement and withdrawal layer underneath a faster private credit system.

What would make this a real category?

1. An independent service adopts it. A third-party RPC, inference or data provider would be more meaningful than another frontend connected to the existing stack.
2. Multiple providers become interchangeable. Private usage credits become much more powerful if users or agents can move across services without recreating persistent billing identities.
3. Privacy expands beyond the payment layer. Network routing, confidential inference and protection against behavioral fingerprinting need to complement the payment mechanism.
4. The cryptographic implementation matures. External review and stronger deployment assumptions would make the system easier to treat as infrastructure rather than an experiment.
5. Developers use it for something unexpected. The best signal that a primitive is real is often that someone finds a useful application its original designers were not optimizing for.