Ethereum Foundation's zkAPI Wants to Pay for APIs Without Showing Your ID. Here Is What the Contract Actually Does.

Last Tuesday, a developer in Berlin sent her first prompt to an AI model without attaching a name, an email, or a credit card. She deposited USDC into a smart contract on Ethereum. The contract did not ask who she was. It only asked if she had enough money. Then it let her talk to the model.

That was zkAPI, and it went live on Ethereum mainnet on October 1.

Key Metrics at a Glance

What zkAPI Actually Does

zkAPI is a system that separates payment from identity when using metered APIs. The idea is straightforward: you deposit credits into a vault contract once, then you prove you have a funded "note" without revealing which note, which deposit, or who you are.

The Foundation's dAI Team, working with the Open Anonymity Project, built three components:

1. A vault contract on Ethereum that holds deposits and verifies proofs at deposit, close, and escape.
2. A local client that runs on your device and generates zero-knowledge proofs.
3. A server that checks proofs and mints short-lived API keys.

The server never sees your identity. The provider never sees your payment. Ethereum sees the deposit and the withdrawal, but not what the deposit paid for.

The Cryptographic Stack

zkAPI uses well-understood primitives:

• Groth16 proofs on the BN254 curve for efficient verification.
• Poseidon hashes for commitments and nullifiers.
• A 32-level Merkle tree to track valid notes.
• Nullifiers: one-way serial numbers derived from each note's secret. Spend a note once, and the nullifier is published. Try to spend it twice, and the duplicate nullifier exposes the fraud without revealing the note.

The vault contract verifies the same kind of proof at deposit, close, and escape. That means your exit never depends on the server's honesty. If the zkAPI server disappears, you can still withdraw.

The Privacy Model: Who Learns What

This is a deliberate separation. The provider runs the model, so it sees the content. The payment layer handles the money, so it sees the spend. Neither can link the two.

The Technical Translation: How a Session Works

The payment path and the conversation path share two objects: a short-lived key and a usage receipt.

1. Deposit: One ordinary Ethereum transaction puts credits into the vault. The deposit becomes a commitment in a Merkle tree.
2. Prove: Your local client generates a Groth16 proof showing your note is in the tree and has not been spent. No identity, no prompt, nothing attached.
3. Key mint: The server checks the proof and mints a fresh API key, short-lived and dollar-capped. The key exists only in your device's memory.
4. Prompt: Your requests go straight from your device to the AI provider with that key. When the key expires, the provider sends a signed usage receipt, and the server deducts the actual spend from your note.

The spending cap acts as a reservation. One authorization covers a whole session. Neither side can rewrite the bill afterward.

Two Modes, Different Tradeoffs

The runtime-key mode exists so that no payment intermediary ever handles your prompts. The proxy mode is easier for providers to integrate.

Use Cases Beyond AI

The same client and contracts can front any metered service:

For providers, integration means accepting a proof instead of an API key and settling signed receipts instead of maintaining accounts. Pricing, rate limits, and infrastructure stay as they are.

The Limitations Nobody Is Hiding

The Ethereum Foundation blog is clear about two gaps:

Network anonymity: The gateway can correlate request patterns if you use a stable IP address. zkAPI hides the payment link, not the network link. Users seeking stronger privacy should route through Tor and use fresh circuits per session.

Content leakage: The provider sees your prompts. If you reuse personal details, writing style, or conversation history across sessions, the provider can fingerprint you. Standalone queries are more private but less useful. One mitigation is using local or TEE models to generate requests from shared memory.

These are real limits. The project acknowledges them instead of pretending they do not exist.

The Accountability Layer: What the Contract Shows

The vault contract at 0x4386fdbda35d995beb3bf8625118ec5982ec81fe is the anchor. Anyone can verify:

• Deposits are public commitments in a Merkle tree.
• Spends publish nullifiers that prevent double-spending.
• Withdrawals are possible without the server's cooperation.
• The contract verifies Groth16 proofs at every state transition.

This is not a trust-me setup. It is a verify-the-code setup. The Foundation published the contracts, the client, and the server code on GitHub.

Competitive Landscape: zkAPI vs. Alternatives

zkAPI is not the only privacy-preserving payment system. It is the first one built specifically for metered API access and running on Ethereum mainnet today.

Strategic Implications

zkAPI matters for three reasons beyond the technical stack:

1. It expands Ethereum's utility from financial settlement to access control. A vault contract that holds API credits is not that different from one that holds collateral. The infrastructure is the same.

2. It gives users actual privacy without requiring provider cooperation. The provider does not need to redesign its billing system. The user brings their own privacy.

3. It creates a pattern that other services can copy. If zkAPI works for AI APIs, the same architecture works for RPC endpoints, bandwidth metering, and machine-to-machine payments.

The question is whether users will adopt it. Privacy tools that require a local client and one upfront deposit have historically struggled with mainstream adoption. The Foundation is betting that AI API privacy is a large enough pain point to change that.

TL;DR

• What: The Ethereum Foundation's dAI Team launched zkAPI, a system for private metered API payments using zero-knowledge proofs on Ethereum mainnet.
• How: Users deposit credits into a vault contract, then generate Groth16 proofs to authorize spending without revealing identity, deposit, or usage patterns.
• Impact: AI providers see prompts but not who paid; the payment layer sees spend but not what was requested; Ethereum sees deposits but not what they funded.
• Limits: Network IP correlation and prompt content fingerprinting are still risks; Tor and TEE mitigations are recommended for users needing stronger anonymity.
• Watch: Whether providers integrate runtime-key mode, whether the vault sees meaningful TVL, and whether the Open Anonymity Project expands to other API categories.

Sources

• Ethereum Foundation Blog — Introducing zkAPI
• zkAPI GitHub Repository
• ZkApiVault on Ethereum Mainnet
• Sepolia Test Deployment
• Ethereum Research — ZK API Usage Credits
• OA Chat — Private AI Chat Demo

Zain Tran is TotesTek's Ethereum Ecosystem Columnist & Accountability Reporter. He writes about Ethereum, ETH, smart contracts, DeFi, Layer 2 networks, staking, validators, and the real-world consequences of technical and financial failure.