{"slug": "introducing-zkapi-private-usage-credits-for-any-api", "title": "Introducing zkAPI: private usage credits for any API", "summary": "The Open Anonymity Project, working with the Ethereum Foundation, launched zkAPI on Ethereum Mainnet, a system that lets users pay for metered APIs using zero-knowledge proofs so providers see requests and the payment layer sees spend without either learning the link between them. Users deposit ETH or USDC into a vault contract once, then authorize bounded usage with Groth16 proofs on the BN254 curve, Poseidon-hashed commitments and nullifiers, and a 32-level Merkle tree, with the server verifying spend proofs off-chain. A short-lived, dollar-capped API key is minted in device memory so prompts go directly to the AI provider, and the server charges the private balance from a signed usage receipt when the key expires.", "body_md": "tl;dr: zkAPI lets you pay for a metered API without being known. Deposit credits into an Ethereum vault once, then authorize bounded usage with zero-knowledge proofs instead of an identity. The provider sees the requests, and the payment layer sees the spend. Neither learns the link between them.\n\nThe Open Anonymity Project built it with the Ethereum Foundation, and it runs on Ethereum Mainnet today.\n\nThe problem\n\nEvery AI API call today carries an identity. Your API key points to an account, the account to a payment method, and every prompt you send joins the record attached to both. The provider can connect years of your usage into a single profile.\n\nPrompts are personal. People ask AI models about their health, their finances, their doubts. Under the current model, using AI means handing a running transcript of your thinking to whoever holds the billing relationship. The alternatives were poor: pay per request onchain, which is slow, expensive, and traceable by anyone, or trust a middleman not to look.\n\nThe idea\n\nzkAPI separates payment from identity. You deposit credits (ETH, USDC, etc.) into a vault contract on Ethereum, one ordinary transaction. From then on, your balance exists as a private note: digital cash that only you can spend and that nobody can trace back to the deposit.\n\nTo authorize spending, software on your machine produces a small zero-knowledge proof that says, in effect, that a funded note covers this spend and nobody has spent it before. One proof can cover a single request or a whole session. The server can check that the statement is true without learning which note, which deposit, or which person. At the payment layer, requests do not link to you, and they do not link to each other.\n\nTwo pieces of cryptography make this safe as well as private. Deposits live as commitments in a Merkle tree, so a proof can show “my note is one of the valid ones” without pointing at any particular one. Every spend publishes a nullifier, a one-way serial number derived from the note's secret. A user who stays within their balance stays unlinkable. A user who tries to spend the same balance twice produces a duplicate nullifier, which exposes the attempt and nothing else.\n\nHow it works\n\nThe payment path (steps 1 to 3) and the conversation path (step 4) share two objects: the short-lived key and its usage receipt.\n\nThe server that handles money never sees content, and the provider that sees content never learns the billing identity behind a key.\n\nYour app talks to a small client running on your own device. Nothing about the app changes. It speaks the same API it always did.\n\nThe client sends the zkAPI server a proof of payment, with no prompt and no identity attached.\n\nThe server checks the proof and mints a fresh API key on the spot, short-lived and capped in dollars. The key exists only in your device's memory.\n\nYour prompts go straight from your device to the AI provider with that key. When the key expires, the server charges your private balance for the metered usage rather than the reserved cap.\n\nThe spending cap works as a reservation. When the key expires, the provider side records the key's total usage in a signed receipt, and the server deducts that amount from your note. Neither side can rewrite the bill afterward, and one authorization covers a whole session of requests rather than one proof per call.\n\nzkAPI also ships a simpler proxy mode, where the zkAPI server relays requests to the provider itself. It is easier to operate, but the relay sees traffic. The runtime-key mode above exists so that no payment intermediary ever does.\n\nzkAPI proves spends with Groth16 on the BN254 curve, hashes commitments and nullifiers with Poseidon, and keeps notes in a Merkle tree 32 levels deep. The server verifies spend proofs off-chain. The vault contract verifies the same kind of proof at deposit, close, and escape, so your exit never depends on the server’s honesty.\n\nIn practice\n\nParty\n\nLearns\n\nNever learns\n\nzkAPI server\n\na valid payment exists, and total dollars per session\n\nwho you are, what you asked, which deposit paid\n\nAI provider\n\nprompts and responses, since it runs the model\n\nwho is paying\n\nEthereum (public)\n\ndeposits, closes, withdrawals\n\nwhat any balance paid for\n\nYour funds stay yours: The vault is a contract on Ethereum rather than a company account: you can close your balance and withdraw onchain, even if every zkAPI server disappears.\n\nYour tools stay the same: The client exposes the standard OpenAI and Ollama APIs on your own machine. Existing apps, editors, and chat clients work by pointing them at localhost.\n\nUse cases\n\nAI inference comes first because prompts are sensitive and the billing trail ties each one to you. The same client and contracts can front any service that charges per use:\n\nUse case\n\nMetered unit\n\nWhat the payment layer hides\n\nAI chat and agents\n\nmodel calls\n\nwhich note paid, and any billing link between sessions\n\nBlockchain RPC\n\nqueries\n\nwhich funding source paid for the queries\n\nImage and video generation\n\njobs\n\nwho paid for which jobs\n\nVPNs and bandwidth\n\ntime and data\n\nwho paid for the connection\n\nMachine-to-machine services\n\nper-task spend\n\nagents pay without an account\n\nzkAPI hides the payment link. A provider still sees what a request contains and network metadata such as your IP address, and it can try to correlate sessions by timing. Network anonymity and content privacy are separate layers: a VPN or Tor handles the network side, and confidential GPU computing is emerging for content.\n\nFor providers, integrating means accepting a proof instead of an API key and settling signed usage receipts instead of maintaining accounts. Pricing, rate limits, and infrastructure stay as they are.\n\nLimitations\n\nzkAPI’s protections have two limitations: the lack of network anonymity, and privacy leakage via prompt contents.\n\nOn the network side, the main issue is that the gateway can potentially correlate request patterns from a user if they send requests to zkAPI under a stable user IP address. Users seeking stronger privacy may route requests through Tor and use a fresh circuit for each session.\n\nOn the content side, individual sessions may be re-linked by the inference provider if the same personal details, writing style, reused conversation history, or project documents are presented. Shared prompt contents can act as fingerprints for anyone who can read the prompts. This is a privacy-utility tradeoff: standalone queries are more private but less useful since past context is missing. One mitigation is to leverage local or TEE models to generate requests on top of shared memory instead of the user manually writing them. See also discussions in the Open Anonymity project post.\n\nBackground and links\n\nzkAPI is the working implementation of ZK API usage credits, a design published on Ethereum Research by Davide Crapis and Vitalik Buterin.\n\nThe Open Anonymity team helped turn that design into the client, the server, and the contracts you can run today.", "url": "https://wpnews.pro/news/introducing-zkapi-private-usage-credits-for-any-api", "canonical_source": "https://blog.ethereum.org/en/2026/10/01/introducing-zkapi", "published_at": "2026-10-01 00:00:00+00:00", "updated_at": "2026-10-16 18:52:41.665752+00:00", "lang": "en", "topics": ["ai-infrastructure", "artificial-intelligence", "ai-policy", "ai-safety"], "entities": ["zkAPI", "Open Anonymity Project", "Ethereum Foundation", "Ethereum Mainnet", "Groth16", "BN254", "Poseidon", "USDC"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/introducing-zkapi-private-usage-credits-for-any-api", "markdown": "https://wpnews.pro/news/introducing-zkapi-private-usage-credits-for-any-api.md", "text": "https://wpnews.pro/news/introducing-zkapi-private-usage-credits-for-any-api.txt", "jsonld": "https://wpnews.pro/news/introducing-zkapi-private-usage-credits-for-any-api.jsonld"}}