zkAPI launches on Ethereum: pay for AI APIs without an identity

The Ethereum Foundation and the Open Anonymity Project launched zkAPI on October 1: a protocol for paying metered AI APIs with zero-knowledge proofs instead of an account, live on Ethereum mainnet today. It attacks the one identity every API call still carries — the billing relationship.

Key facts

• zkAPI went live on Ethereum mainnet on October 1, with the ZkApiVault contract holding USDC credits at 0x4386...81fe — a "runs today" claim that is checkable on-chain, not just asserted.
• Spend is authorized by Groth16 proofs on the BN254 curve, with Poseidon-hashed nullifiers in a 32-level Merkle tree, per the Ethereum Foundation's launch post by Vittorio Rivabella of the dAI team.
• The server mints a short-lived, dollar-capped API key that exists only in your device's memory; the provider sees prompts but never the billing identity, and the zkAPI server sees spend but never content.
• The design was published on Ethereum Research by Davide Crapis and Vitalik Buterin and implemented by the Open Anonymity Project with the EF's dAI team; the client, server, and contracts are in a public GitHub repo.
• The launch post itself concedes two limits: no network anonymity by default, and content-based re-linking — a provider can correlate sessions through writing style, reused conversation history, or a stable IP address.

What happened

Every AI API call today carries a billing identity. Your API key points to an account, the account to a payment method, and every prompt joins the transcript attached to both. The Ethereum Foundation's launch post states the problem in those terms and ships the counter-design: zkAPI, built by the Open Anonymity Project, running on Ethereum mainnet.

The mechanics, in three moves. First, you deposit credits — ETH, USDC, or another asset — into a vault contract in one ordinary transaction. From then on your balance exists as a private note that nobody can trace back to the deposit. Second, software on your machine produces a zero-knowledge proof that a funded, unspent note covers the spend, without revealing which note. Each spend publishes a nullifier, a one-way serial number that prevents double-spending while exposing nothing else. Third, the zkAPI server verifies the proof and mints a fresh API key on the spot — short-lived and capped in dollars, existing only in your device's memory. Your prompts travel directly from your device to the AI provider with that key; when it expires, a signed usage receipt settles the metered amount against your private balance.

The vault contract is live on mainnet, holding USDC credits, with a Sepolia deployment for testing and a working browser client at OA Chat. The local gateway exposes the standard OpenAI and Ollama APIs on localhost, so existing apps, editors, and chat clients work by pointing them at localhost. We verified the Etherscan address, the GitHub repo under the ethereum organization, and the OA Chat deployment are all live as of this writing.

One structural detail matters and is easy to miss. zkAPI ships two modes. The runtime-key mode described above keeps every intermediary blind to content. The simpler proxy mode relays your traffic through the zkAPI server itself — easier to operate, but the relay sees traffic. Anyone evaluating the protocol needs to know which mode a given deployment actually runs.

Why it matters

The identity problem zkAPI attacks is the payment layer's, and it is worth being precise about what layer that is. A provider can already promise not to train on your prompts or store them — the policy-based privacy most major APIs now offer. TEE hosting goes further and encrypts prompts in use, so the operator cannot read them even if it wants to. zkAPI leaves prompt content with the provider, exactly as today, and removes the other half of the link: who is paying. The provider can still read what you asked; it just cannot connect the question to your account, your card, or your three-year history with the vendor.

The launch post is candid that this is a partial shield, not a cloak. Without a VPN or Tor, the gateway can correlate request patterns from a stable IP address. And on the content side, sessions can be re-linked by the inference provider through writing style, reused conversation history, or project documents that act as fingerprints. The post's own suggested mitigation for that leakage is notable: route generation through local or TEE-hosted models so the shared memory layer never leaves your control. Payment-layer privacy and execution-layer privacy are complementary rails here, not competing ones — zkAPI removes the billing identity while confidential computing removes the content exposure. Our TEE inference explainer maps who offers that execution-side guarantee today, and NEAR AI Cloud's attested TEE serving is the current reference implementation of it.

There is also an agent angle hiding in the use-case table: machine-to-machine services, where agents pay per task without an account. Agentic workloads multiply API calls faster than humans approve accounts, and each account is a standing identity an agent carries into every request. A capped, short-lived key minted per session is a different trust shape for autonomous spend.

Background

zkAPI is the working implementation of ZK API usage credits, a design Davide Crapis and Vitalik Buterin published on Ethereum Research. The Open Anonymity Project turned that design into the client, the server, and the contracts now deployed. That lineage matters for how much weight the claims can carry: the design predates the hype cycle, and the cryptographic primitives — Groth16, Poseidon hashing, Merkle-tree commitments, nullifiers — are the same machinery proven at scale by privacy-focused payment systems over the past several years.

But a design being sound in principle is not the same as this implementation being audited. Our sources contain no independent security audit of the zkAPI contracts or client, and the unlinkability guarantee is the protocol's own description of its math. Treat "unlinkable" as the design claim it is — checkable in principle by anyone who reads the circuits, but not yet certified by anyone we could name.

The deeper context is where private inference is heading. The field has spent 2026 converting privacy from a policy promise into a mechanism: zero-data-retention tiers became product lines at the major labs, attested TEE serving moved from confidential-computing specialists to consumer-grade APIs, and private inference became a category builders evaluate rather than a clause in a privacy policy. zkAPI extends that shift to a layer nobody had productized: the bill. If prompts are personal — and the launch post argues people ask models about health, finances, and doubts — then the account that ties years of those questions to one identity is itself the sensitive artifact.

The system also has an exit guarantee that distinguishes it from trusting any privacy startup. The vault is a contract on Ethereum rather than a company account, so you can close your balance and withdraw onchain even if every zkAPI server disappears. Your exit never depends on the operator's honesty or solvency. That is a structural property worth having in a market where inference providers appear, pivot, and fold quarterly.

What's next

The near-term signals to watch are practical. First, whether a named security firm audits the vault contracts and the zk circuits — the launch materials name none, and an unaudited payment protocol holding user deposits is a different risk object than an audited one. Second, whether any mainstream inference provider starts accepting zk proofs natively, which the launch post describes as a small integration: accept a proof instead of an API key and settle signed receipts instead of maintaining accounts. Third, watch the proxy-mode/runtime-key split in real deployments — OA Chat and similar frontends should state clearly which mode they run, because the privacy guarantees differ fundamentally. And the content-fingerprint problem the authors flag as unsolved is exactly the gap local models and TEE hosting fill; the interesting products of the next quarter will be the ones that compose all three layers rather than selling any single one.

An AI API you pay for without an identity is now something you can run today. Whether that remains a research demo or becomes infrastructure depends on audits, providers, and whether the re-linking caveats stay as honest as the launch post's.