The Ethereum Foundation and the Open Anonymity Project launched zkAPI on Ethereum mainnet on October 1, 2026 — a payment protocol that lets users pay for AI model inference and other metered APIs without revealing their identity. The system uses Groth16 zero-knowledge proofs to sever the link bet...
"Don't just do what everyone else would do anyway, just on rails with an octahedron logo instead of a square or circle, or a pentagon logo. Make something fundamentally better, using meaningful technological improvements in ZK privacy-preserving payments and reputation." — Vitalik Buterin, Co-Founder, Ethereum
The Ethereum Foundation and the Open Anonymity Project launched zkAPI on Ethereum mainnet on October 1, 2026 — a payment protocol that lets users pay for AI model inference and other metered APIs without revealing their identity. The system uses Groth16 zero-knowledge proofs to sever the link between a user's deposit and their API consumption, so that the AI provider sees requests but not the payer, and the payment processor sees the spend but not the content.
The launch converts a theoretical proposal — "ZK API Usage Credits: LLMs and Beyond," published on Ethereum Research on February 11, 2026, by Ethereum Foundation dAI lead Davide Crapis and Ethereum co-founder Vitalik Buterin — into production code running against a live vault contract on Ethereum mainnet. It arrives as the AI API market approaches $514.5 billion in revenue globally, according to Mordor Intelligence, and as enterprise spending on large-language-model inference is now split roughly 40% Anthropic, 32% OpenAI, and 21% Google, according to Ramp spending data.
The economic question is straightforward: every one of those API calls today carries a billing identity. The provider can connect years of a user's prompts, completions, and usage patterns into a single behavioral profile. zkAPI attempts to eliminate that linkage at the protocol level.
AI API providers log full prompts and completions by default. According to a 2026 analysis published by DEV Community, providers build behavioral profiles from API call metadata — timestamps, token counts, model selection, session length, and content patterns — even when no personally identifiable information is explicitly submitted. Under GDPR and DPDP frameworks, these logs constitute regulated datasets once they contain PII, which they frequently do given the conversational nature of LLM interactions.
The blast radius of an AI API breach is larger than a traditional data breach, according to Proton's analysis, because the content is rich, contextual, and often contains implicit information the user did not realize they were sharing. Writing style, conversation history, and behavioral patterns serve as fingerprints for re-identification even when direct identifiers are absent.
Scale compounds the problem. Google's Gemini now reaches 900 million monthly active users. OpenAI targets $30 billion in full-year revenue. Anthropic reports a $47 billion revenue run rate. Each API call against these services generates a billing record tied to a known identity, and collectively these records form one of the largest behavioral datasets ever assembled.
zkAPI separates three parties that current API billing conflates:
| Party | What It Sees | What It Cannot See | |---|---|---| | AI Provider | Prompts and responses | Who is paying; funding source | | zkAPI Server | Valid payment proof exists; session-level dollar spend | User identity; prompt content; which deposit funds the payment | | Ethereum (public) | Deposits, closures, withdrawals | Usage content; link between deposit and API calls |
Step 1 — Deposit. A user sends ETH, USDC, or another supported token to the ZkApiVault contract on Ethereum mainnet (address: 0x4386fdbda35d995beb3bf8625118ec5982ec81fe). This is a standard Ethereum transaction. The vault records the balance as a private note.
Step 2 — Prove and Spend. When the user wants to call an AI API, software on their device generates a zero-knowledge proof demonstrating that (a) a funded note exists in the vault, (b) it has not been previously spent, and (c) the requested spend falls within the note's remaining balance. The proof reveals none of these specifics — only that the conditions are satisfied.
Step 3 — Temporary Key. A zkAPI server verifies the proof and issues a temporary API key with a spending cap and an expiration timestamp. The user calls the AI provider with this key.
Step 4 — Withdrawal. The vault is a smart contract, not a company account. Users can close their balance and withdraw on-chain at any time, even if every zkAPI server goes offline.
Two operational modes exist: runtime-key mode, where no payment intermediary sees traffic at all, and proxy mode, which is simpler to deploy but allows the relay to observe traffic.
The system's privacy guarantees rest on specific cryptographic primitives:
The design builds on Rate-Limit Nullifiers (RLN), a construction that binds anonymity to a financial stake. According to Crapis and Buterin's Ethereum Research post, the goal is to "bind anonymity to a financial stake: honest users who stay within protocol limits remain unlinkable, while users who double-spend cryptographically reveal their secret key, enabling slashing."
Proof verification happens off-chain by the zkAPI server for speed and on-chain by the vault contract for settlement. This hybrid approach avoids the gas costs of on-chain verification for every API call while maintaining the settlement guarantees of Ethereum L1.
The system is deployed at two addresses:
| Network | Contract Address |
|---|---|
| Ethereum Mainnet | 0x4386fdbda35d995beb3bf8625118ec5982ec81fe |
| Sepolia Testnet | 0x49fa19f9bdece7a48ebc7749fd69ad40f577590f |
The mainnet vault currently holds USDC credits. The protocol exposes a browser SDK and a local gateway that implements the standard OpenAI and Ollama API interfaces, meaning existing applications, code editors, and chat clients can point to localhost and use zkAPI without code changes.
OA Chat, the Open Anonymity Project's browser-based AI interface, serves as the reference implementation.
zkAPI is designed as a general-purpose metered-API payment layer, not an AI-specific tool. The Ethereum Foundation blog post lists the following supported service types:
| Service Type | Metered Unit | |---|---| | AI chat and agents | Model calls | | Blockchain RPC | Queries | | Image/video generation | Jobs | | VPNs and bandwidth | Time and data | | Machine-to-machine services | Per-task spend |
The machine-to-machine category is notable. As AI agents increasingly handle autonomous micro-payments, API fees, and data purchases from persistent addresses, transaction-pattern analysis can re-identify users at machine scale even without real-name data. zkAPI addresses this by making individual transactions unlinkable.
The Ethereum Foundation blog post explicitly identifies two limitations:
1. Network anonymity gap. Requests originating from a stable IP address risk correlation. The protocol recommends Tor for users who require stronger network-level privacy, but does not enforce it. Without Tor, an observer with access to both the API provider's server logs and network traffic could potentially link requests to IP addresses.
2. Content privacy. Personal details, writing style, and conversation history embedded in prompts act as fingerprints for session re-linking. zkAPI anonymizes the payment layer, not the content layer. A user who discloses identifying information in their prompts undermines the protocol's privacy guarantees regardless of the cryptographic protections.
A third limitation is implicit: the system currently runs on Ethereum L1, where deposit and withdrawal transactions carry gas costs. At current Ethereum gas prices, small-value deposits may face disproportionate transaction fees. The Sepolia testnet deployment suggests L2 expansion may follow, but no timeline has been announced.
zkAPI enters a market where zero-knowledge proof technology has matured into production-ready infrastructure. According to CoinGape's 2026 ZK project survey, the sector includes:
zkAPI's differentiation is narrow but specific: it does not attempt to build a privacy chain or a mixnet. It solves one problem — anonymous metered payments — and relies on existing infrastructure (Ethereum L1, Tor) for everything else. This modularity could accelerate adoption among existing API providers who do not want to migrate to a new chain.
The economic value question, consistent with the webthreepedia framework, is where the fee revenue accrues. In the current AI API billing model, providers capture 100% of the billing relationship and its associated data. zkAPI introduces an intermediary layer — the vault contract and the zkAPI server — that strips the billing identity from the service relationship.
This creates a new value distribution:
The open question is whether AI providers will voluntarily integrate with a system that reduces their data collection capability. The current implementation works by proxying through an intermediary, which means providers do not need to opt in — but they also do not need to cooperate. Provider-side blocking of zkAPI-originated keys remains technically possible.
0x4386...81fe holds USDC and ETH, and users can withdraw at any time regardless of server availabilityzkAPI represents Ethereum's bid to position itself as the settlement layer for private AI payments. The protocol does not promise total anonymity — its own documentation is explicit about the gaps. What it does offer is a cryptographic separation between who pays and what gets asked, deployed as a smart contract that functions independently of any centralized operator.
The practical question is adoption. The AI API market generates hundreds of billions in revenue annually, and the billing identity is a core asset for providers building recommendation engines, safety systems, and usage analytics. Whether a meaningful number of users will route payments through an Ethereum vault to sever that link — and whether providers will tolerate the loss of data — remains to be observed. The infrastructure, however, is now live on mainnet.