Ethereum ZkAPI Hides AI Payments, Not Your Prompts

I kept rereading the launch note until one sentence stopped me cold. A person can fund an AI session without handing the payment desk a name, and without handing the model operator a funding address. Then the next line lands harder: the provider still receives the prompt. If you have ever paid for a model call and wondered who ends up holding the receipt, that split is the whole story. It is useful. It is also narrower than the phrase private AI tends to sound in a headline.

On October 1, a mainnet vault and supporting client and server went live for a system called zkAPI. A user deposits credits. Later, software on the user’s machine produces a proof that a funded note can cover a capped, short-lived session. The payment server checks that proof offchain. The chain itself is not asked to settle every single prompt. I have found that this kind of design is easy to oversell and easy to dismiss. Both reactions miss the point. The interesting question is which record each party is supposed to keep, and which records still leak even when the proof is sound.

What a Hidden Payer Actually Buys You

Most commercial model APIs still work the old way. You create an account, attach a card or a balance, and receive a key. Every request can be joined to that billing identity even if you never type your name into the prompt. The new construction tries to break that join. Deposit supported assets such as dollar stablecoins into a contract. A private note represents the credit. A later proof says a valid note can pay for bounded usage without revealing which note it is.

That is payment privacy, not conversation privacy. I would rather say that plainly than dress it up. A journalist testing a public document, a researcher poking at an awkward hypothesis, or an agent burning through metered calls may want the operator to see the current request and still not build a permanent dossier tied to a card. That narrower need is real. Expecting the proof to cloak the text is where people get burned.

A zero-knowledge proof is a statement about a defined fact. It does not become an invisibility cloak for every byte that travels beside it.

The technical announcement is unusually direct about the boundary. The proof hides which note pays. The provider operates the model and sees the request. Network metadata and prompt content remain sources of correlation. Perhaps the most interesting aspect is that honesty. A product that names its own leaks is easier to use well than one that borrows the word private and hopes nobody asks follow-up questions.

One Deposit Instead of a Trail of Invoices

Here is the flow in plain clothes. You fund a vault. Your machine holds a note secret. When you want access, it builds a proof that the note is among the valid funded notes and still has authority to spend. The payment server verifies the proof and issues a short-lived, dollar-capped key. In the direct runtime-key mode, prompts go from your device to the model provider with that key. After the session, a signed receipt records metered usage. The private balance is charged for what was used, not simply for the reserved cap.

One proof can cover several requests. That matters. Putting every model call on a public chain would be slow, expensive, and oddly public in a different way. The chain sees deposits, closures, and withdrawals. The server verifies spend proofs offchain. The provider sees text and API traffic. In direct mode, the payment server is meant to see that the session is funded and what the total charge was, without receiving the prompt.

Those are claims about the described architecture. They are not a certificate that a particular deployment’s logs can never correlate users. Live code and a mainnet contract prove that something exists to inspect. They do not prove adoption, the scope of any review, or anonymity in every client configuration.

• The chain records vault deposits, closures, and withdrawals.
• The payment server checks a spend proof and a session total.
• The model provider receives prompts, responses, and a temporary key.
• Your device keeps the note secret and, in direct mode, sends content straight to the provider.

There is a simpler proxy mode. In that path the zkAPI server relays the request. It can see traffic. If you are choosing, ask which party you trust with content and which party only needs to validate a payment proof. A local screen that looks identical can route requests differently under the hood. I would not assume the prettier interface is the more private one.

The Note Proves Value Without Naming the Depositor

Under the hood, commitments sit in a Merkle tree. A proof says your note is a member of the valid set without pointing at its leaf. A nullifier, derived from a note secret, stops the same balance from being spent twice. The published construction uses Groth16 proofs on BN254 and Poseidon hashes, with a 32-level tree. Implementers care about those choices. For everyone else, the financial idea is simpler: verify membership and remaining spend authority without publishing the account that supplied the credit.

You do 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 ten-dollar cap is reserved and three dollars of service is consumed, the system is meant to charge three dollars, not ten. That example is about reservation logic, not a published price.

The nullifier answers one failure: double spending a note. It does not prove the model answered accurately. It does not keep the prompt confidential. It does not stop the provider from recording requests. A proof is only as wide as its circuit. Guarantees do not spill outward onto other data just because they share a session.

Three Layers, and Only One Is the Product

I keep coming back to a three-layer test, because the marketing blur tends to smash them together.

1. Payment privacy: can a bill be tied to a funding note or a person?
2. Network privacy: can the service identify a connection by address, timing, or device traits?
3. Content privacy: can anyone operating the model read the prompt?

zkAPI is built chiefly for the first layer. It can reduce an account-level link between a usage log and a payment source. It does not deliver the other two by itself. A stable network address and correlated timing can weaken privacy. Tools that hide a network path can change the route. Neither removes a name you typed into the box.

This is not a defect tucked into fine print. The project’s own description says the provider sees the requests. That honesty is stronger than an expansive anonymity slogan, because it tells you where to add extra care. Generic questions may gain real payment unlinkability. A pasted contract with a full name discloses identity in the content no matter how clever the payment route is.

Why the Provider Can Still Recognize You

The payment proof can conceal a funding source while the request body contains an employer, a medical history, or proprietary code. A provider that reads the prompt can link it to earlier sessions through repeated phrases, uploaded files, conversation history, or a highly specific fact. No wallet link is required. Ask about an unpublished product and reuse the same internal project name across three sessions, and you have written your own identifier.

In runtime-key mode, the provider may see the address your device connects from. In proxy mode, the intermediary can see traffic and possibly its originating network information. A network anonymity tool changes the path. It does not rewrite the paragraph you just sent. I have watched people treat a VPN as a personality cloak. It is not. It is a route change.

Hiding the bill does not force the reader to forget the letter.

A practical way to remember the split

There is a second set at the provider: the group of requests that share one short-lived key. The key links those requests inside a capped session even if it cannot name the deposit. That grouping is inherent in metering. Send the same documents again under a later key and the provider may link them across credentials too. Billing unlinkability is valuable. It does not order the provider to develop amnesia.

A Small Crowd Can Undo a Perfect Proof

Zero knowledge can hide which of several notes paid. The practical crowd still matters. If only one user funds a vault in a narrow window with an unusual 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. Inference from outside information is a separate attack.

A 32-level tree is a capacity parameter, not evidence that billions of distinct users are mixing credits today. A service that just went live may have a small set of funded notes. To judge anonymity in practice you would want dated counts of deposits, distinct active notes, and withdrawal patterns, aggregated in a privacy-conscious way. A repository or a theoretical tree size does not hand you those numbers.

Suppose ten notes are eligible and public facts rule out nine. The math can still hide its witness perfectly while the surrounding facts point at the tenth. That toy case is why the size and diversity of the plausible set matter more than the raw count of vault transactions. Standardized amounts, delayed activity, and ordinary usage may help. User behavior and service design decide what is actually available to correlate.

Anonymity in practice:
  sound proof
  + large, diverse note set
  + ordinary amounts and timing
  - distinctive deposits
  - immediate matching withdrawals

Draw the Ledgers Before You Trust the Slogan

Try this exercise for a single session, and do not assume anyone is cheating. The public chain records the deposit and its funding address. Your device keeps the note secret and sends a proof to the payment server. The server records validity, a nullifier, and an issuance event for a capped key. The model provider records that key, the requests, and the usage it billed. A signed receipt ties the key to a metered total. At close, the contract can record an exit. Each party holds a partial ledger.

The intended property is that no single honest party’s ledger directly joins the funding address to the provider’s prompts. A coalition, a leak, or an outside observer with timestamps can hold more. Deposit an odd amount and immediately send one odd request, and correlating events gets easier. Hand the provider a document that names you, and it can know who asked without ever seeing the vault address. That is a composition problem, not a broken proof.

Key lifetime sits in the middle of this. A session credential deliberately groups the requests it authorizes so usage can be metered. A larger cap may allow many prompts under one key. Lower caps and shorter sessions can reduce how much content is linked inside one credential, but they demand more frequent proofs and may add latency or cost. There is no universally private setting. You and the provider are choosing among convenience, cost, and linkability.

A public threat model should name which records are kept and for how long. Does the server log source addresses during proof submission? Are nullifiers stored indefinitely? Can the provider associate receipt identifiers with request content after settlement? Deleting a billing name is helpful. It is not enough if a persistent device identifier quietly rebuilds the same profile.

The Receipt Moves Trust into Metering

Someone still has to charge for the work actually done. The design uses a signed receipt tied to the short-lived key and its usage. That shifts a commercial question onto the accuracy of metering. If a provider overcounts tokens, requests, or time, a valid payment proof cannot fix the bill. The signature makes an asserted total hard to rewrite later. It does not prove the asserted usage was fair under the rate card.

Ask what unit is charged, who signs the receipt, how unused reservation is released, and what happens when a request fails halfway. Those are ordinary billing questions in unusual cryptographic clothing. A cap limits the surprise inside one session. Many small sessions can still add up. Rate limits and invoices may need a dispute path that does not force you to reveal who you are.

The tradeoff is operational, and I think people underestimate it. Traditional accounts make support, refunds, and abuse checks easier because the provider can identify the buyer. Removing a persistent billing identity from the intended payment path does not remove the need for abuse controls, screening where the law requires it, or usage enforcement. Pricing and rate limits can remain. Real integrations will show how services balance accountless payments with fraud controls and legal duties.

• What unit is metered, and who signs the receipt?
• How is an unused reservation released?
• What does a failed or half-delivered request cost?
• Can you audit the metered total without sending the prompt to the payment server?
• If the server vanishes, can unused balance still leave through the contract?

A practical test is a deliberately interrupted session. Take a capped key, make several requests, drop the network, and reconnect later. Does the receipt reflect only delivered usage? If the server disappears, can you retrieve unused balance through the contract as advertised? Those tests move past whether a proof verifies and into whether the product keeps its promised separation when things break.

The Contract Is an Escape Hatch, Not a Cloak

The vault can verify proofs for deposit, close, and escape operations. An onchain exit matters because a shutdown should not strand funds inside 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 even if the privacy idea is sound. A live address is evidence of deployment, not an audit certificate.

Public deposits and withdrawals have a privacy cost of their own. Someone who knows your funding address can see that it touched the vault. They may not see which session it paid for, but they can see participation and amounts. Withdraw an unusual sum quickly to an address already tied to you, and some of the surrounding anonymity shrinks. The private note breaks a deterministic billing link. It does not erase the public funding transaction.

The idea has roots in an earlier research design for zero-knowledge API credits. A proposal and a production system answer different questions. The first sets out a construction. The second has to handle key storage, front-end behavior, outages, receipt disputes, upgrades, and real adversaries. A release that puts the idea on mainnet is a testable deployment. That is the fresh fact. It is not a finished privacy guarantee.

Wider privacy work on the same network is not the same product. A draft for native protocol privacy, or a wallet built for private transfers in another setting, should not be cited as proof that a prompt sent through this system is hidden from its model operator. Different products protect different data. Mixing them is how a careful reader gets talked into a claim the deployment never made.

Claims That Should Survive a Repeatable Test

An independent reviewer could create two funded notes from unrelated addresses, open short sessions with the same provider, and inspect every packet and log visible to the client, the payment server, and the provider. Direct and proxy modes should be tested 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 identifier, unlinkability has failed at the integration layer even if the circuit is sound.

The harder test is statistical. Run many sessions with varied amounts and timing, then ask whether a party holding only public chain data and server logs can correlate funding and use better than chance. The benchmark depends on the real anonymity set and on whatever extra data the adversary has. A tidy lab demo does not establish privacy under a tiny production user base. It does create a method for measuring whether deployments improve.

The content test is straightforward and a little sobering. Submit the same distinctive document under two fresh session keys. If a provider can recognize it in both, payment unlinkability has not given you conversation unlinkability. Judge a payment claim by the first tests. A claim about anonymous model use has to survive the third. Publishing the mode, the threat model, and the results would let people pick the tool that matches the worry they actually have.

Payment claim: proof hides note, server sees cap and total.
Content claim: provider still reads the prompt.
Network claim: address and timing remain a separate problem.

Where the Narrow Case Is Actually Strong

There are plenty of legitimate reasons to ask a provider a sensitive question without building a permanent account-linked usage file. You may want the operator to see the current request while cutting the durable billing relationship. The design speaks to that need. It also lets a machine pay for metered services without a long-lived personal account for every call.

The case against overclaiming is just as strong. Providers still see prompts, and some prompts necessarily reveal identity. An organization with strict confidentiality rules may need contracts, local models, or confidential computing on top of payment unlinkability. Some people will prefer an ordinary account with support and refunds over a cryptographic payment layer whose dispute habits are still young. The right choice depends on the threat model, not on the mood of the announcement.

A broader privacy roadmap does not confer its future protections on this application today. You have to judge the live client and the provider path that actually handles the prompt. A proof reveals a defined fact without revealing a witness. It is not a general cloak. The useful question is which party sees which record at each step, not whether the project qualifies for the broad word private.

The best evidence against a skeptical reading would be measured use without a persistent identity link, clear mode labels, independent review, and a published threat model covering network addresses, browser telemetry, and receipts. The best evidence against an expansive marketing claim is already in the launch description: the provider sees the prompt. Both can be true at once. I prefer products that can survive that sentence.

Agents, Shared Pools, and the Fingerprint You Send Yourself

Machine-to-machine payments are listed as a possible use. An autonomous agent may send hundreds of calls from one funded note or from many short sessions. If those tasks carry customer records, the model operator can learn about those customers even while the agent’s payment source stays 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 that sit above the proof. A cap per key limits one session. A loop can request repeated keys until the note is drained unless the client enforces a wider spending policy. Define a daily or task-level limit, an alert, and a pause that is separate from the cryptographic check. The proof verifies authorized credit. It does not decide whether the call was necessary or cheap.

When several agents share one pool, internal accounting can become the hidden billing system. You may need to allocate charges to teams or customers without exporting their identities to the API provider. A local ledger can do that, and it creates another sensitive dataset to protect. Moving from account billing to note billing does not abolish reconciliation. It relocates it.

Behavior can reveal an agent even when the note stays hidden. Repeated calls on the same schedule, the same tool headers, and the same task-specific phrases can cluster separate short-lived keys. Hiding an onchain funding note is useful against payment surveillance. It is not a defense against a behavioral fingerprint the agent sends with every request. If you are building that kind of system, treat the fingerprint as part of the design, not as an afterthought.

What a Deployment Audit Should Still Ask

As of October 2, the code, server, client, and vault are described as live, with a mainnet contract and a repository linked from the announcement. That post does not publish a definitive user count, an audited total value, every third-party integration, or a guarantee that every client configuration uses direct runtime-key mode. None of this is a claim of breach or misbehavior by a named provider. It is a map of what each party is intended to receive, plus the extra leaks the authors already acknowledge.

An outside assessment should inspect client defaults and outbound connections. Does the browser demo 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 an interface accidentally gives away the identity it was meant to separate.

The same assessment should look at the provider’s view. It will see the content it processes and a session credential. It may collect device or network metadata depending on the path. Retention policy and contractual terms stay central. The payment layer can reduce one source of identifying information without constraining the others.

zkAPI is a real advance if it reliably stops a model provider from binding useful requests to a billing account while leaving you a way to reclaim funds. It will disappoint anyone who expected a private conversation simply because the payment was proven in zero knowledge. Judge the two claims separately. That is the whole discipline.

What to Watch Before You Fund a Note

• Mode labeling: can you see direct runtime-key or proxy routing before you send a prompt?
• Mainnet activity: are there dated counts of funded notes and usage that do not expose users?
• Reviews: what scope do independent assessments cover for exits, circuits, client storage, and receipts?
• Metadata: how are addresses, telemetry, key lifetimes, and provider retention handled in real integrations?
• Disputes: how are failed requests, cap release, and contested receipts handled without forcing identity disclosure?

If you only remember one distinction, make it this. The funded note is about who pays. The prompt is about what was said. A system that separates those records can be worth using. A system that pretends they are the same thing is selling a feeling. I would rather pay for the first and stay skeptical of the second.

Questions People Actually Ask

Is the vault live on mainnet? The October 1 description said the vault and supporting client and server are live, and linked a mainnet contract and code repository. Live means inspectable. It does not mean widely used or fully reviewed.

Does this hide my prompt from the model operator? No. The provider receives the prompt in order to run the model. The payment proof is designed to conceal the source of the usage credits.

What does the payment server learn? In the described direct mode, it learns that a valid payment exists and what the session’s metered total was, without receiving the prompt or identifying the specific deposit.

Is proxy mode as private as direct mode? No. The proxy relays requests and can see traffic. Direct runtime-key mode sends the prompt from the device to the provider.

Can a network address identify a user? It can help correlate sessions, especially next to timing and content. The system does not supply network anonymity by itself.

What if the server shuts down? The vault is described as offering an onchain exit so balances can be closed and withdrawn without that server. The implementation still deserves a careful read before you park serious value in it.

Are deposits and withdrawals invisible? No. Public transactions reveal vault interactions. The proof aims to sever the link between a funded note and later metered usage, not to hide the fact that a deposit happened.

Is this a private way to discuss confidential material with any model? Not by itself. The provider sees the content. You still need to weigh retention, network metadata, and how sensitive each prompt is. Nothing here is a recommendation to buy, sell, or hold any asset.

The launch is worth taking seriously because it draws a line most products smudge. Payment unlinkability can be a genuine upgrade for people who do not want a permanent account file attached to every metered call. Conversation privacy is a different job, and this deployment does not claim to have finished it. If you fund a note, read the mode, watch the amounts, and assume the model can read what you type. That assumption has aged better than most slogans.