The Ethereum Foundation has launched zkAPI, a payment tool designed to let users pay for artificial intelligence services without exposing their identities or billing details. The tool went live on Ethereum's main network on October 1, according to the Foundation's announcement. It builds on a February 11 proposal by Vitalik Buterin and Davide Crapis. The roughly eight months between that research post and the mainnet launch turn a written proposal into working software that handles real ETH deposits — which is why the withdrawal rules and security assumptions covered below deserve attention.

When a writing application asks an AI model to produce an answer, it sends an API request. A conventional API key connects that request to a customer account, which may also contain billing details. Over time, the provider can associate the customer with a history of questions about work, finances, and other personal matters.

zkAPI separates the check that a request can be paid for from the conversation itself. As the Foundation puts it: “The provider sees the requests, and the payment layer sees spend.”

How an AI Session Gets Paid For

Someone using a writing application to explore a career change, for example, would first fund an Ethereum vault. The current client's documentation describes deposits in ETH, with the software keeping a private record of the balance and the information needed to spend it. This record is called a note. Because the balance remains denominated in ETH, its dollar value can change between sessions, as the billing documentation explains.

To start a session, the software generates a zero-knowledge proof showing that sufficient funds are available without identifying the deposit. A unique spending marker, called a nullifier, prevents the same spending state from being used for a second authorization.

Once the proof passes, the server issues a temporary API key with a spending limit. The writing application then uses it to contact the AI service directly, keeping the conversation outside the payment server.

Suppose a user authorizes up to $1 for a session but consumes only $0.30. The balance is reduced by the measured charge, while the unspent funds remain available under the vault's rules. The figures are illustrative: the spending limit is a maximum rather than an automatic charge.

One deposit can support repeated usage because the payment proofs and accounting operate off-chain. Ethereum transactions are involved only when funding or closing the balance, so each prompt does not require a separate blockchain payment.

What the AI Provider Can Still See

In this direct-to-provider setup, different participants receive different information. The AI service still receives the text needed to answer the user. If a user uploads a CV containing their name and employer, the AI service could identify them despite the private payment. Repeated documents or conversation history could also connect separate sessions.

Requests made with the same temporary key can still be grouped into one session. IP addresses and timing may provide further links between sessions, even when the payment proof conceals the funding deposit. Put together, these caveats mean zkAPI privatizes the payment trail rather than the conversation itself.

The launch post also describes a proxy option that sends requests through the payment server. That relay sees the traffic, giving it more visibility than the direct-to-provider setup.

What to Know Before Funding the Vault

Users can access the system through OA Chat or a local client for compatible applications. The project repository labels the protocol experimental, making its withdrawal rules and security assumptions relevant reading before funding a balance.

Under the current protocol documentation, users can close a balance with the server's approval or use a separate withdrawal route without it. The latter includes a challenge period, set to 24 hours by default. Notes also have expiry dates, after which an unclosed note can be claimed by the treasury. Users therefore need to account for those dates when deciding when to withdraw remaining funds.

The proof system uses initial cryptographic parameters generated by one party. Its security documentation notes that the published files do not establish that the setup's secret material was destroyed. Users therefore have to trust that this sensitive material was handled securely.

The Payment Model Could Extend to Other Services

The February proposal also considered paid blockchain queries and other services charged by usage. A wallet or automated application could buy access using the same payment principle, with spending limited by its available credits. Ethereum supplies the funding and settlement infrastructure, while remote services perform the requested work.

Wider adoption will depend on applications displaying charges and withdrawal deadlines clearly while handling proof generation in the background. Users should be able to assess the cost and privacy of a session without managing the cryptographic machinery themselves. The project's public documentation is where to check over time for any change to the experimental label and the setup assumptions.