The Ethereum Foundation and the Open Anonymity Project have launched zkAPI on Ethereum mainnet, providing a working payment layer that lets software prove it has prepaid funds for metered API use without identifying the deposit that funded a request.
The implementation is initially aimed at AI inference. A user deposits ETH into an onchain vault, while a local client holds a private note representing the balance. The client can then generate a zero-knowledge proof that the note is valid and can cover a bounded session. The payment server verifies the proof and issues a short-lived API key without receiving the user’s prompt or billing identity.
For payments teams, zkAPI is better understood as prepaid authorization and net settlement than as an onchain payment for every API call. Ethereum records deposits and withdrawals, but usage authorization and balance updates occur offchain. That design avoids requiring a blockchain transaction for each request while trying to break the usual link among an API account, its payment method and its complete usage history.
The mainnet deployment uses native ETH
Public deployment evidence supports the mainnet claim. The project’s production manifest identifies Ethereum chain ID 1 and the ZkApiVault contract at 0x4386FDbdA35D995beB3BF8625118Ec5982ec81fe. An Ethereum RPC check found deployed bytecode at that address and a successful contract-creation transaction in block 26,091,339 on Sept. 30. The project’s public health endpoint was also responding on Oct. 2 with protocol version 2 and the same contract address.
The active configuration uses native ETH, denominated internally in whole gwei. A finalized ETH/USD oracle price converts the provider’s dollar-denominated usage into an ETH charge. The quote is attached to the authorization, so an accepted session is not repriced during settlement.
This production boundary is narrower than the general protocol description. The Ethereum Foundation’s announcement describes a design that can support assets such as ETH or USDC, but the reviewed mainnet manifest specifies native ETH and a null token address. The project’s current SDK documentation also says token manifests are unsupported. Payment providers should therefore treat multi-asset support as a protocol direction, not a feature verified in the live deployment.
One proof can authorize a metered session
When a client requests access, it sends a payment proof without the prompt. The server checks that a funded private note is part of the active commitment tree, that the authorized spend is within the balance and that its nullifier has not already been used. A nullifier prevents the same private state from authorizing conflicting spends without revealing which public deposit created it.
The live configuration provisions five-minute leases through Open Anonymity infrastructure for OpenRouter access. The short-lived key is capped, but that cap is a reservation rather than a fixed charge. After the provider measures usage, a signed settlement updates the user’s private balance for the amount consumed. Prompts and responses travel between the client and the inference provider rather than through the zkAPI payment server.
The project also supplies a browser SDK, a local OpenAI-compatible client and operator services for verification, indexing and challenges. Open Anonymity has integrated the Ethereum payment option into OA Chat, giving the implementation a user-facing path rather than leaving it as a specification alone.
Payment privacy is not request anonymity
The privacy boundary remains important. zkAPI is designed to conceal the relationship between a deposit and an API authorization from the payment server, and to keep the billing identity behind a temporary key from the API provider. It does not conceal the request itself from the provider that processes it.
IP addresses, timing, writing style, repeated personal details and reused conversation context can still link sessions. The Ethereum Foundation and Open Anonymity both disclose these limits. Network privacy requires a separate transport such as Tor or another proxy, while content-level correlation may remain possible even when the payment path is unlinkable.
Onchain activity is also public. Observers can see vault deposits and withdrawals, although the zero-knowledge design is intended to prevent them from determining which private API sessions those funds paid for.
The launch remains experimental
The public repository labels the protocol experimental. Its production manifest says the circuit, Rust implementation and Solidity integration have not been production-audited, and the checked-in Groth16 proving keys come from a single-party setup rather than a multiparty ceremony. Artifact hashes identify the selected setup but do not prove that setup secrets were destroyed.
The operational model introduces additional dependencies. Users rely on a correct vault, proof system, indexer, price feed and signed offchain accounting. The deployment uses a 24-hour challenge period for disputed escape states, making continuous challenge-service operation relevant while funds are held in the vault. ETH price changes also mean the dollar value of a prepaid balance fluctuates.
No transaction volume, user count or merchant adoption was disclosed, and this review did not execute a funded inference-and-withdrawal cycle. The evidence establishes deployed code, a responding mainnet service, released clients and a live application integration—not production scale or independently audited security.
Even with those qualifications, zkAPI is a material payments experiment. It shows how a provider could authorize metered digital services without maintaining a conventional customer billing account and without settling every unit of usage onchain. The next tests are operational: independent security review, broader asset support, reliable recovery and challenge handling, and evidence that the privacy model remains usable under real payment volumes.