Ethereum Foundation ships zkAPI: pay-for-API ZK proofs land on mainnet

The Ethereum Foundation's dAI team and the Open Anonymity Project shipped zkAPI on Ethereum mainnet on October 1, 2026, in a joint release announced by dAI engineer Vittorio Rivabella and backed by a reference implementation at github.com/ethereum/zkapi. The system lets a client deposit ETH or USDC into a vault contract, then pay for API calls — the pitch is AI inference, but any metered HTTP endpoint fits — using zero-knowledge proofs that unlink each request from the funding deposit. The project ships as experimental: the privacy guarantee holds at the payment layer, not the transport layer.

What happened

zkAPI publishes three pieces at once:

• A vault contract on Ethereum mainnet that stores user deposits as private "notes." A note is a Merkle-tree commitment holding a balance; the owner can prove ownership and spend without revealing which note is theirs.
• A client (zkapi-clientd) running locally on the user's machine. It exposes the OpenAI and Ollama APIs, so any existing tool that targets those SDKs can be pointed at the local client without code changes.
• A gateway operator that validates proofs and issues short-lived API keys with per-session spending caps, which the client then uses against the upstream model provider.

The underlying design — a payment-splitting scheme with nullifier-based double-spend protection — was co-authored by Ethereum Foundation dAI lead Davide Crapis, Stanford PhD candidate Ken Liu of Open Anonymity, and Vitalik Buterin. The GitHub repo shows 199 commits on main and uses Groth16 proofs over the BN254 curve.

Mechanism — note commitments, nullifiers, temporary keys

The flow in a single API call:

1. Deposit. User funds the vault with ETH or USDC. The deposit becomes a note in a Merkle tree. The on-chain tx reveals only the aggregate deposit, not which future payments it will back.
2. Prove. The client generates a Groth16 proof that it owns a note worth at least the session cap, and produces a nullifier — a one-shot serial number derived from the note secret.
3. Issue key. The gateway verifies the proof, checks the nullifier against the seen set, and issues an API key capped at the proven amount.
4. Spend. The client sends prompts to the model provider using that key, as usual. The provider sees traffic but not the funder.
5. Settle. Spent amounts debit the note; a change note is created. Double-spend attempts produce a duplicate nullifier and are rejected without revealing the funding deposit.

The practical consequence: the payment relation — this wallet funded this API call — is cryptographically broken. Billing stays correct and the gateway cannot overcharge without producing a verifiable receipt.

Numbers

- Launch date         : 2026-10-01
- Network             : Ethereum mainnet
- Status              : experimental
- Proof system        : Groth16 over BN254
- Supported deposits  : ETH, USDC
- Client API surface  : OpenAI + Ollama compatible
- Named authors       : Crapis (EF), Buterin (EF), Liu (Open Anonymity)
- Repo                : github.com/ethereum/zkapi (199 commits on main)
- Open issues / PRs   : 1 / 2

Limits and caveats

The team flags the privacy ceiling itself. zkAPI unlinks the payment; it does not anonymize network traffic or content:

• No network-level anonymity. A gateway operator with stable IP metadata can correlate sessions that share an IP, a VPN exit, or a Tor circuit. A privacy-serious user needs transport anonymization on top.
• Prompt-level linkage. Content, writing style, personal details and conversation state can re-link sessions regardless of the payment proof. "Pay anonymously" is not "chat anonymously."
• Experimental cryptography. The Groth16 circuits and vault contracts ship as a research release. Production use at scale is not the Day-1 pitch.

What to watch

1. Vault contract on Etherscan. The deployment address will appear in the repo's protocol/contracts/ directory; the deposit mix depth is the practical anonymity-set number — small sets collapse the privacy guarantee regardless of proof correctness.
2. Gateway diversity. One gateway is one trust anchor. Multiple independent gateways serving the same vault spread that trust; a single operator can throttle, de-prioritize or deny clients it can fingerprint.
3. Audits. A research release at a crypto-primitive layer this deep needs third-party review before builder adoption. Watch the repo's audits/ directory and the EF blog for a formal audit announcement.
4. Upstream provider stance. OpenAI and the Ollama ecosystem have no commitment here. If a model provider decides to block gateway IPs or require stronger KYC on API-key issuance, zkAPI's economic model routes around a key the provider can see — but not around a provider that refuses to serve a key it can see.

Context — the privacy stack is thickening

zkAPI lands alongside a cluster of Ethereum-aligned privacy work shipping to mainnet this year: Railgun's continued throughput work, Umbra v3, and the broader Privacy Pools / PlasmaFree iteration that the EF has been funding since 2024. The common thread is the same split zkAPI makes explicit — unlink the money from the usage, without touching the asset itself. For builders, the useful question is which of these systems sees adoption from upstream service providers; the primitive is only as good as the operator mesh behind it.

Sources

• Repository: github.com/ethereum/zkapi
• The Block: Ethereum Foundation launches zkAPI to let users pay for AI models without revealing identity