Ethereum’s zkAPI hides who pays for AI. The model still sees the prompt

The Ethereum Foundation and Open Anonymity Project launched zkAPI on Ethereum mainnet on October 1. A user can deposit credits and prove a later AI API request is paid for without giving the payment server an identity or the model provider the funding address. The provider still receives the prompt. That separation is useful, but it is a narrower privacy claim than an anonymous conversation with a model.

TheEthereum Foundation’s technical announcement is unusually explicit about the boundary. The proof hides which note pays for usage, while the provider operates the model and sees the request. It also names network metadata and prompt content as remaining sources of correlation. That matters because the phrase private AI payments can easily be heard as private AI use.

The project is live, according to the Foundation, with a public GitHub repository, a mainnet vault holding USDC credits and a demonstration chat interface linked from its announcement. Live deployment establishes that there is code and a contract to inspect. It does not establish user adoption, a security audit’s scope, anonymity in every client configuration or protection against a provider that recognizes a user’s writing and documents.

JUST IN: Ethereum Foundation and Open Anonymity launch zkAPI for private AI

The system lets users deposit ETH, prove payment with a zero-knowledge proof and receive a fixed amount of private AI inference without linking their identity or personal data. pic.twitter.com/nPLLmmbhrq

— crypto.news (@cryptodotnews) October 2, 2026

One deposit replaces a trail of API invoices

Most commercial AI APIs connect a key to an account and a payment method. The provider can associate requests with a billing identity, even if a user never signs the prompt with a name. zkAPI introduces a funded vault and a private note. A user deposits supported assets such as USDC into a contract; software on the user’s machine later produces a zero-knowledge proof that a valid funded note can pay for bounded usage without disclosing which note it is.

The payment server verifies the proof and issues a short-lived, dollar-capped API key. In the direct runtime-key mode described by the Foundation, prompts go from the user’s device to the AI provider with that key. After the session, a signed receipt records metered usage, and the private balance is charged for the amount used rather than simply the reserved cap. One proof can cover a session of multiple requests.

This avoids putting every model request on Ethereum. The chain sees vault deposits, closures and withdrawals, while the server verifies spend proofs offchain. The model provider sees the text and API traffic. The payment server sees evidence that the session is funded and the total charge, but in the direct mode does not receive the prompt. These are claims about the described architecture, not proof that a particular deployment’s logs or network configuration can never correlate users.

There is a simpler proxy mode. In it the zkAPI server relays the user’s request to the model provider. That server can see traffic, according to the Foundation. A person deciding between modes should ask which party they trust with content and which one only needs to validate a payment proof. A local interface that looks identical could route requests differently under the hood.

The note proves value without naming its depositor

The cryptographic construction uses commitments in a Merkle tree. A proof says the user’s note is among the valid funded notes without identifying its leaf. A nullifier, derived from a note secret, prevents the same balance from being spent twice. The Foundation names Groth16 proofs on BN254 and Poseidon hashes, with a 32-level tree. These details matter to implementers, but the financial principle is simpler: verify membership and remaining authority to spend without publishing the account that supplied the credit.

The user does not get free usage by hiding an identity. The server must check the spend proof and reserve a cap before it issues the temporary key. The provider meters use. The receipt settles the actual amount after the key expires. If a $10 cap is reserved and $3 of service is consumed, the system is meant to charge $3, not $10. That example illustrates the reservation logic, not a published price or guaranteed minimum. The remaining balance stays in the private note subject to the implementation’s rules.

The nullifier addresses a specific failure: an attempt to spend one note twice. It does not prove the AI model answered accurately, preserve the confidentiality of the prompt, or prevent the provider from recording requests. A zero-knowledge proof is a statement about the validity of a transaction under a defined circuit. Its guarantees do not expand automatically to other data that move alongside the transaction.

The contract’s exit path matters too. The Foundation says a user can close the vault balance and withdraw onchain even if zkAPI servers disappear. This avoids making the payment server the sole route to reclaim funds. It does not make exits invisible: Ethereum records the relevant transactions. The user’s ability to exit depends on the contract and possession of the necessary secret, and a prudent user should inspect deployment addresses, permissions and any independent review before assigning large value to the mechanism.

The provider can recognize what the proof cannot reveal

The payment proof can conceal a funding source while the request body contains a person’s name, employer, medical history or proprietary code. A model provider that reads the prompt can link it to prior sessions using repeated phrases, uploaded files, conversation history or highly distinctive facts. No wallet link is needed. A prompt about an unpublished product with the same internal project name across three sessions is its own identifier.

Network metadata supplies another path. In runtime-key mode, the provider may see the IP address from which the device connects. In proxy mode, the intermediary can see traffic and potentially its originating network information. The Foundation explicitly says a stable IP and correlated timing can weaken privacy, and suggests network anonymity tools for users seeking stronger protection. A VPN or Tor can alter the network path, but neither removes a name typed into the prompt.

There is a three-layer privacy test. Payment privacy asks whether a bill can be tied to a funding note or person. Network privacy asks whether the service can identify a connection by IP, timing or device characteristics. Content privacy asks whether anyone operating the model can read the prompt. zkAPI is designed chiefly for the first layer. It can reduce an account-level link between the model provider’s usage log and the user’s payment source. It does not deliver the other two by itself.

This is not a defect hidden in the fine print. The project’s own announcement says the provider sees the requests. The honest description is stronger than an expansive anonymity slogan because it tells users where to focus additional precautions. A person who uses the service to ask generic questions may gain substantial payment unlinkability. A person who pastes a signed contract and a full name has disclosed identity in the content regardless of the payment route.

The anonymity set can be small even with sound proofs

Zero knowledge can hide which of several notes paid, but the practical crowd matters. If only one user funds a vault in a narrow time window with an unusual deposit amount, and an equally distinctive withdrawal follows a session, an observer can form a plausible correlation from public timing and amounts. The proof may remain cryptographically valid and unbroken. Inference from external information is a separate attack.

The 32-level tree is a capacity parameter in the design, not evidence that billions of distinct users are mixing their credits today. A newly live service may have a small set of funded notes. To evaluate anonymity in practice, one would want dated counts of deposits, distinct active notes and withdrawal patterns, with privacy-conscious aggregation. A repository or theoretical tree size does not provide those numbers.

Suppose ten notes are eligible for a session and public facts rule out nine of them. The mathematical proof can still hide its witness perfectly, while the surrounding information points to the tenth. This toy example explains why the size and diversity of the plausible set matter more than the raw number of transactions in the vault. Amount standardization, delayed activity and regular usage may help, but user behavior and service design determine what is available to correlate.

There is a second kind of set at the AI provider: the group of requests sharing a short-lived key. The key can link requests within its capped session even if it cannot identify the deposit. That is inherent in metering a session. If the client repeatedly sends the same documents in later sessions, the provider may link them across keys too. Hiding the billing account is valuable, but it does not force the provider to forget what it has read.

Draw the records for a single session without assuming anyone cheats. Ethereum records the deposit transaction and its funding address. The user device retains the note secret and sends a proof to the payment server. The server records the proof’s validity, a nullifier and an issuance event for a capped key. The model provider records that key, the requests and the usage it billed. The signed receipt ties the key to a metered total. At close, the contract can record an exit. Each party has a partial ledger.

The intended privacy property is that no single honest party’s ledger directly joins the funding address to the provider’s prompts. A coalition, data leak or outside observer with timestamps can have more information. If a user deposits an unusual amount and immediately sends a single unusual request, correlating events might become easier. If a provider receives a document that identifies the user, it can know who asked despite never seeing the vault address. This is a composition problem, not a failed zero-knowledge proof.

The ledger exercise also exposes the importance of key lifetimes. A session credential deliberately groups all requests it authorizes so a provider can meter them. A $50 cap may allow many prompts under one key. Lower caps and shorter sessions can reduce how much content is linked within one credential, but they require more frequent proofs and may add latency or expense. There is no universally private setting; the user and provider choose between convenience, cost and linkability.

A public threat model should name exactly which records are retained and for how long. It should say whether the server logs source IP addresses during proof submission, whether it stores nullifiers indefinitely, and whether the provider can associate receipt identifiers with request content after settlement. Deleting a billing name from a database is helpful. It is insufficient if a persistent device identifier quietly recreates the same profile.

A signed usage receipt moves trust into metering

The provider or server needs a way to charge for the work actually performed. The design uses a signed receipt associated with the short-lived key and its usage. This shifts a central commercial question to the accuracy of metering. If a provider overcounts tokens, requests or time, a valid payment proof cannot correct the underlying bill. The signature makes an asserted total hard to rewrite later; it does not establish that the asserted usage was fair under the provider’s rate card.

A customer should ask what unit is charged, who signs the receipt, how unused reservation is released, and what happens when a request fails halfway through. These are ordinary billing questions in unusual cryptographic clothing. A cap limits the size of an unexpected charge in one session, but many small sessions can still accrue substantial cost. Rate limits and invoices may need a privacy-preserving dispute process.

The tradeoff is operational. Traditional API accounts simplify customer support, refunds and abuse investigation because a provider can identify the buyer. zkAPI removes a persistent billing identity from the intended payment path. Providers may still need abuse controls, sanctions screening where applicable and usage enforcement. The Foundation says pricing and rate limits can remain, but actual integrations will show how services balance accountless payments with their obligations and fraud controls.

One practical test is a deliberately interrupted session. The client gets a capped key, makes several requests, loses network access and later reconnects. Does the receipt reflect only delivered usage? Can a user audit the metered amount locally without sending the prompt to the payment server? If the server disappears, can the user retrieve unused balance through the contract as advertised? These tests move beyond whether a proof verifies to whether the product preserves the promised separation under failure.

The onchain contract is an escape hatch, not a privacy shield

The vault contract can verify proofs for deposit, close and escape operations, according to the Foundation. An onchain exit route matters because a provider shutdown should not strand user funds in an operator database. The contract replaces some institutional trust with smart-contract risk. A bug in proof verification, accounting or withdrawal logic could affect funds despite a sound privacy concept. A live address is evidence of deployment, not an audit certificate.

Public deposits and withdrawals also have a privacy cost. Someone who knows a user’s funding address can observe that it interacted with the vault. They may not see which API session it paid for, but they can see participation and amounts. If the same user quickly withdraws an unusual amount to an address already associated with them, some of the surrounding anonymity may shrink. The private note breaks a deterministic billing link; it does not erase the public funding transaction.

The project has roots in an Ethereum Research design for zero -knowledge API credits, which the Foundation identifies as work by Davide Crapis and Vitalik Buterin. A research proposal and a production system answer different questions. The former sets out a construction; the latter must handle key storage, front-end behavior, outages, receipt disputes, upgrades and real adversaries. The October 1 release moves the idea into a testable deployment, and that is the relevant fresh hook.

Ethereum’s wider privacy efforts are not the same product. Crypto.news’ coverage of a proposed native privacy design concerns a draft protocol change, while zkAPI is an application running now. The recent zk.money wallet launch concerns private transfers in another environment. Neither should be cited as evidence that an AI prompt sent through zkAPI is concealed from its model provider.

Privacy claims should survive a reproducible test

An independent reviewer could create two funded notes from unrelated addresses, issue short sessions with the same model provider and inspect every packet and log visible to the client, payment server and provider. The reviewer should test the direct and proxy modes separately. If the direct-mode payment server receives a prompt, that contradicts the described separation. If the provider receives a deposit address or a durable billing account identifier, the intended unlinkability has failed at the integration layer even if the proof circuit is sound.

The harder test is statistical. Run many sessions with varied amounts and timing, then ask whether a party with only public chain data and server logs can correlate funding and use better than chance. The benchmark depends on the actual anonymity set and what auxiliary data the adversary has. A successful small laboratory demonstration does not establish privacy under a tiny production user base, but it creates a method for measuring whether deployments improve over time.

The content test is straightforward and sobering. Submit the same distinctive document under two fresh session keys. If a provider can recognize it in both, the payment unlinkability has not given the user conversation unlinkability. A claim about payment should be evaluated by the first two tests; a claim about anonymous AI usage must also survive the third. Publishing the mode, threat model and results would let users choose the right tool for their actual concern.

The strongest case is unlinking billing from useful content

There are many legitimate reasons to ask an AI provider a sensitive question without building a permanent account-linked usage dossier. A journalist testing a public document, a researcher exploring a controversial hypothesis or a developer using an API inside an agent may want the provider to see the current request while severing the durable billing relationship. zkAPI’s design addresses that narrower need. It also lets a machine pay for metered services without managing a long-lived personal account for each request.

The case against overclaiming is equally strong. Providers still see prompts, and some prompts necessarily reveal identity. An enterprise with strict confidentiality requirements may need contractual controls, local models or confidential computing as well as payment unlinkability. Some users may prefer an ordinary account with established support and refunds over a cryptographic payment layer whose dispute mechanisms are still immature. The choice depends on the actual threat model.

The Ethereum privacy roadmap discussed by crypto.news frames privacy as a wider objective. A roadmap does not confer its future protections on this application today. An AI user must judge the live client and provider path that actually handles a prompt.

Crypto.news explained the narrower mechanics of zero-knowledge proofs in a separate primer. A proof reveals a defined fact without revealing a witness; it is not a general-purpose invisibility cloak. Its interview on privacy-focused Ethereum infrastructure underscores how different products protect different data. The useful question for zkAPI is which party sees which record at each step, not whether the project qualifies for the broad word private.

The best contrary evidence to a skeptical reading would be measured use without a persistent identity link, clear mode labels, independent security review and a published threat model covering IP, browser telemetry and receipts. The best contrary evidence to an expansive marketing claim is already in the Foundation post: the provider sees the prompt. Both observations can be true at once.

The Foundation lists machine-to-machine API payments as a possible application. An autonomous agent may send hundreds of calls using one funded note or many short sessions. If its tasks carry customer records, the model provider can learn about those customers even while the agent’s payment source remains private. The privacy benefit belongs to the billing link; it should not be passed through to every subject named in a request.

An agent also needs budget controls. A cap per key limits one session, but a loop can obtain repeated keys until the note is drained unless the client enforces a broader spending policy. The operator should define a daily or task-level limit, alerting and a pause control separate from the cryptographic proof. The proof verifies authorized credit, not whether the agent’s call was necessary or economical.

When several agents share one pool of credits, internal accounting can become the hidden billing system. The operator may need to allocate charges to teams or customers without exporting their identities to the API provider. That can be done with a local ledger, but it creates another sensitive dataset to safeguard. The move from account billing to note billing does not abolish reconciliation; it relocates it.

Finally, an agent can reveal itself through behavior. Repeated calls at the same schedule, the same tool headers and the same task-specific phrases may make separate short-lived keys easy to cluster. Hiding an onchain funding note is useful against payment surveillance. It is not a defense against a behavioral fingerprint that the agent sends with every request.

JUST IN: Vitalik Buterin envisions Ethereum becoming a “cryptographic world computer” by 2030

His vision shifts more computation offchain, with cryptographic proofs allowing the network to verify results without every computer repeating the same work, while also improving… pic.twitter.com/aCMpSto8H5

— crypto.news (@cryptodotnews) September 28, 2026

A deployment still needs a threat-model audit

As of October 2, the Foundation says the code, server, client and vault are live. The post links a mainnet contract and repository. It does not publish in the announcement a definitive user count, audited total value, all third-party integrations or a guarantee that every client configuration uses direct runtime-key mode. This feature does not claim a breach or misbehavior by a named provider. It identifies the information each party is intended to receive and the additional leaks the project’s authors acknowledge.

An outside assessment should inspect client defaults and outbound connections. Does the browser demonstration send telemetry to unrelated domains? Does the local client retain keys or prompt logs? Can the payment server join issuance timestamps with network addresses? Are receipts linkable across sessions? How are circuit and contract updates governed? A proof can be mathematically sound while a user interface accidentally gives away the identity it was meant to separate.

The same assessment should test an AI provider’s view. It will see the content it processes and a session credential. It may collect device or network metadata depending on the request path. A provider’s data-retention policy and any contractual terms remain central. The payment layer can reduce one source of identifying information without constraining all the others.

zkAPI makes a real advance if it reliably prevents a model provider from binding useful requests to a billing account while preserving the user’s ability to reclaim funds. It will disappoint anyone who expects a private conversation simply because the payment was proven in zero knowledge. The two claims should be judged separately.

What to watch

• Mode labeling: Check whether each client makes direct runtime-key or proxy routing visible before a user sends prompts.
• Mainnet activity: Look for dated counts of funded notes and usage, reported without compromising users’ anonymity.
• Security reviews: Read the scope of independent assessments covering contract exits, proof circuits, client storage and receipt settlement.
• Metadata controls: Test IP handling, telemetry, key lifetimes and provider retention in actual integrations.
• Billing disputes: Check how failed requests, cap release and contested receipts are handled without forcing identity disclosure.

FAQ

Disclaimer: This article is for information and educational purposes only and does not constitute financial or investment advice. Figures reflect regulatory filings and reporting available at the time of writing and change with each disclosure. Nothing here is a recommendation to buy, sell, or hold any security or asset. Always do your own research. Information is accurate as of October 2, 2026.