The Ethereum Foundation and the Open Anonymity Project have brought a mainnet system online that lets people pay for metered APIs without tying those calls to a durable billing identity.
Announced on October 1, 2026, by Vittorio Rivabella of the Foundation’s dAI team, the design—called zkAPI—is already running on Ethereum and implements an earlier research proposal from Davide Crapis and Vitalik Buterin.
Ordinary API access today binds every request to an account.
An API key maps to a user, that user maps to a payment method, and the provider can assemble years of prompts into a single profile.
Because people routinely ask models about health, money, and private doubts, that arrangement hands a long transcript of thought to whoever holds the billing relationship.
Paying per call directly on-chain avoids the middleman but is slow, costly, and publicly traceable.
Trusting an intermediary not to inspect traffic is the other common compromise.
zkAPI splits the payment relationship from the content of the request.
A user deposits ETH, USDC, or similar assets into a vault contract in a single ordinary transaction.
From that point the balance exists as a private note—effectively digital cash that only the holder can spend and that cannot be traced back to the original deposit.
When spending is needed, software on the user’s own device produces a compact zero-knowledge proof asserting that a funded note covers a bounded amount of usage and has not already been spent.
One proof can authorize a single call or an entire session.
The server can confirm the statement is true without learning which note, which deposit, or which person stands behind it.
At the payment layer, successive requests neither link to the user nor to one another.Two cryptographic mechanisms support the claim.
Deposits are stored as commitments inside a Merkle tree, so a proof can demonstrate that a note belongs among the valid set without identifying it.
Each spend also publishes a nullifier, a one-way serial number derived from the note’s secret.
Staying inside the balance keeps activity unlinkable; attempting to spend the same funds twice produces a duplicate nullifier that reveals only the double-spend attempt.
In operation, a small client on the user’s machine speaks the familiar API.
It forwards a payment proof—containing neither prompt nor identity—to the zkAPI server.
The server checks the proof and issues a short-lived key capped in dollars, which lives only in local memory.
Prompts then travel directly from the device to the provider under that key.
When the key expires, a signed usage receipt records actual consumption, and the server deducts that amount from the private note rather than the full reserved cap.
Neither party can alter the bill afterward.
A simpler proxy mode exists in which the server relays traffic, but the preferred path keeps content away from the payment intermediary entirely.
Proofs use Groth16 over the BN254 curve, with Poseidon hashes for commitments and nullifiers, and notes held in a 32-level Merkle tree.
Spend proofs are verified off-chain by the server; the vault contract itself checks equivalent proofs at deposit, close, and withdrawal, so users can exit even if every server vanishes.
Funds therefore remain under the user’s control on Ethereum rather than in a company account.
The division of knowledge is explicit.
The zkAPI server learns that a valid payment exists and the dollar total for a session, but not the user’s identity, the content of requests, or which deposit funded them.
The AI provider sees prompts and responses because it must run the model, yet never learns who is paying.
The public Ethereum chain records deposits, closures, and withdrawals, but not what any balance was spent on.
The same client and contracts can front other metered services—blockchain RPC queries, image or video jobs, VPN bandwidth, or machine-to-machine tasks—hiding the funding link in each case.
Existing applications need little change: the local client exposes standard OpenAI– and Ollama-compatible endpoints, so editors and chat tools can simply point at localhost.
A browser chat interface is also available.
The protections stop at the payment link.
Providers still observe request contents and network metadata such as IP addresses, and they can attempt to correlate sessions by timing or by recurring personal details, writing style, or conversation history inside prompts.
Network anonymity requires a separate layer such as Tor with a fresh circuit per session; content privacy is a further, still-emerging concern addressed by techniques like confidential computing. The protocol is described as being somewhat experimental.