Ethereum Foundation puts zkAPI payment system on mainnet

The Ethereum Foundation and Open Anonymity Project launched zkAPI on Ethereum mainnet on October 1, a system that lets users pay for metered AI and other APIs without tying payment to their identity. The Ethereum Foundation’s announcement says the server that authorizes payment does not see prompts, while the AI provider receives requests without learning which deposit funds them.

Users deposit funds into an Ethereum vault contract. The client turns the balance into a private note and generates a zero-knowledge proof to authorize spending. The proof demonstrates that a note is funded and unspent without identifying the note or its deposit. The system implements “ZK API Usage Credits,” a design by Ethereum Foundation dAI lead Davide Crapis and Ethereum co-founder Vitalik Buterin, according to The Block’s report.

How does zkAPI separate payment from an AI request?

The client sends a payment proof to the zkAPI server without sending the prompt. After verifying it, the server issues a fresh, short-lived API key with a spending cap. The client sends prompts directly to the AI provider with that key. When it expires, a signed usage receipt records the session’s metered cost and the server deducts that amount from the private balance.

The cap reserves funds; it is not the final charge. A single authorization can cover a session rather than requiring a proof for each API call. The provider sees the request and usage tied to the temporary key. The payment server sees the spend, but the Foundation says neither side learns the link between the user’s deposit and the request.

zkAPI’s payment proofs use Groth16 over the BN254 curve. Deposits are represented as commitments in a 32-level Merkle tree. Each spend publishes a nullifier, a one-way value derived from the note’s secret. The server checks proofs off-chain; the vault contract checks proofs for deposits, balance closures and escape withdrawals. Reusing a note produces a duplicate nullifier, exposing the attempted double spend.

What can still identify or expose a user?

zkAPI separates the billing trail from prompts, but it does not provide network anonymity or hide request contents from the model provider. The provider receives prompts and responses. A stable IP address or request timing may let the gateway correlate sessions; repeated personal details, writing style or reused conversation history may let the provider link prompts to a person.

The Foundation describes a runtime-key mode in which requests go straight from the user’s device to the provider, avoiding a payment intermediary on that path. It also offers a proxy mode, where the zkAPI server relays requests and can see traffic. These modes have different exposure: the proxy sees requests in transit, while the direct path still leaves the provider able to read prompt content.

What does the mainnet launch make available?

The Foundation says the system is live on Ethereum mainnet and its vault holds USDC credits. The local client exposes standard OpenAI and Ollama APIs, allowing compatible applications to connect through localhost. The design also targets metered services such as blockchain RPC, image generation, VPN bandwidth and machine-to-machine API calls.

Provider adoption requires accepting payment proofs and settling signed usage receipts instead of using ordinary accounts and API keys. The Foundation says pricing, rate limits and infrastructure can otherwise stay as they are. Its announcement describes zkAPI as a working implementation; the project’s GitHub repository labels the protocol experimental.

Sources and documents

• Ethereum Foundation’s announcement — blog.ethereum.org
• The Block’s report — theblock.co