Ethereum Launches zkAPI to Hide Who Pays for AI

zkAPI separates Ethereum funding from AI requests

The active ethereum/zkapi repository describes a private prepaid client with a browser SDK and a local API. Users can access zkAPI through OA Chat’s Ethereum-wallet option or connect compatible software through the local client. The repository labels the protocol experimental.

Its funding documentation deserves attention. The Foundation’s announcement discusses ETH, USDC and other credits and links a USDC-holding vault. The current repository and protocol documentation specify native ETH only for the active SDK and vault.

Those are different descriptions, not confirmation that every client accepts every asset. A user or integrator needs the denomination and contract address of the chosen deployment rather than assuming a USDC transfer will fund the current ETH implementation.

The architecture documentation describes a browser-generated proof sent to the billing service without a prompt. Once verified, the service issues a short-lived provider key with a spending limit. The client sends inference calls directly to OpenRouter using that key.

After the key is retired, usage is settled and the client receives a signed update to its private balance. A lease can cover multiple calls. The client checks the charge and updated state before saving it, while only actual usage reduces the available credit.

The protocol uses a nullifier, effectively a unique marker for a spending state, to prevent the same balance being spent twice. Funding and final withdrawal involve Ethereum transactions; each inference request does not require a separate on-chain payment.

That addresses a different layer from charging for APIs through x402. Metering explains what a service bills. Payment unlinkability addresses whether the bill creates a persistent identity trail across usage.

zkAPI’s 60-second key window limits request privacy

The local client’s instructions identify a concrete qualification: its default reuses a provider key for a fixed window of up to 60 seconds. Compatible requests from different chats and local clients can share that key and its spending cap.

The provider can link those requests. A fresh credential therefore does not necessarily mean a fresh credential for every prompt, and an unlinkable funding proof does not make all calls within a session unlinkable from one another.

The client offers a fresh-key setting that disables reuse, with settlement starting after each response. Fresh access may wait for the preceding key’s settlement, illustrating the practical exchange between fewer settlement pauses and stronger separation of requests.

Separate privacy documentation says direct HTTPS is the default, exposing the source IP to destination services. Optional Tor routing can reduce that network exposure, but requires its own configuration. Client applications can also retain transcripts already supplied to them.

The Foundation separately acknowledges that repeated personal details, writing style and reused conversation history can connect sessions. A provider still sees content needed to run the model. Removing the billing identifier therefore reduces one profiling channel without guaranteeing that a person cannot be recognized.

The distinction also separates zkAPI from Ethereum’s draft private-token standard. Hiding token balances and transfer amounts is a different problem from shielding the connection between prepaid credits and off-chain AI activity.

Ethereum’s experimental vault adds withdrawal conditions

Unused funds can leave through a mutual close with server clearance or an escape withdrawal without it, according to the protocol documentation. The escape route has a configurable challenge period, defaulting to 24 hours, during which already-used spending states can be challenged.

It should not be described as an unconditional instant withdrawal. The active protocol also defines note expiry and requires operators to run a challenge service, making operational configuration part of how settlement works.

The repository’s note-binding review says balances are bound to the particular funded note. It also states that the checked-in Groth16 setup is single-party and the cryptographic construction is not post-quantum. Matching circuits, proof keys and deployed verifiers are required.

The integration guide calls for independent review of design and setup assumptions before production use. Mainnet availability establishes deployment, not an independent audit, adoption level or assurance that every operator has configured the system correctly.

The guide also requires a client’s network, vault address, proof assets and signing keys to match independently trusted deployment values. The vault’s verifier and signing keys are immutable. Copying a configuration file or seeing a matching circuit label alone does not establish that a client is connected to the intended deployment.

Ethereum’s wider institutional privacy work focuses on confidential financial infrastructure. zkAPI applies privacy to a consumer and developer billing relationship, where the useful test is what information each participant actually receives.

Source: Alternative.me. October 2’s Bitcoin-focused reading was 72, or Greed. It is broader market context, not a measure of zkAPI adoption.

As of 16:08 UTC on October 2, the launch materials did not disclose active-user counts or aggregate payment volume. The next evidence to watch is deployment-specific funding guidance, independent review and measured use, alongside whether providers preserve the separation promised by the payment design.