zkAPI Breaks the Billing Link, Not the AI Privacy Problem

zkAPI is trying to remove one of the quietest identity systems on the internet: the API bill. Every ordinary model request arrives with a key. That key belongs to an account, the account belongs to a payment method, and the payment method usually belongs to a person or company. Even when a prompt contains no name, years of usage can accumulate behind one billing identity.

The Ethereum Foundation introduced zkAPI on October 1 as a working system for prepaid, private API usage credits. A user funds a note in an Ethereum vault, proves that the note can cover a bounded amount of usage, receives a short-lived provider key and pays only for the metered work. The payment service can verify solvency without learning which deposit belongs to the user. In the direct-key mode, the upstream model provider receives the prompt without learning the onchain funding identity.

That is meaningful, but narrower than “private AI.” The model provider still sees the request because it must process it. A stable IP address, repeated writing style, project documents and timing patterns can reconnect sessions that the payment protocol separated. The project’s own documentation calls the protocol experimental, and the current stack depends on a single-party Groth16 setup, an operator, an indexer, a challenger, an oracle and an upstream API provider.

Block2Learn’s assessment is that zkAPI should be evaluated as a new billing primitive, not as an anonymity switch. It can turn API access from an account credential into something closer to a privately funded bearer instrument. If that boundary survives real usage, the design could matter well beyond AI inference. If users or investors mistake payment unlinkability for complete content privacy, the same design could create more confidence than protection.

What launched on Ethereum

The Ethereum Foundation’s launch article describes zkAPI as live on Ethereum mainnet. Open Anonymity built the implementation with the Foundation, translating a February research proposal by Davide Crapis and Vitalik Buterin into a client, server and vault system. The implementation supports local OpenAI-compatible endpoints, a browser SDK and a direct integration with OpenRouter for model access.

The basic user flow starts with a deposit. The current documentation describes a private note funded with native ETH, while the Foundation article also discusses a USDC-credit deployment. The important concept is not the asset choice. It is the separation between the public funding event and later usage authorization. The deposit creates a commitment in a Merkle tree. The user keeps the secret needed to prove membership and ownership without pointing to the public leaf that funded the balance.

When the user wants API access, local software generates a zero-knowledge proof. The proof says that a valid note exists, that its balance supports a capped amount of spending and that the authorization state has not already been consumed. The server verifies the proof, reserves capacity and issues a fresh key. The provider measures actual usage. Settlement reduces the private balance and returns a newly signed state.

This is different from sending an onchain payment for every call. A transaction per prompt would expose a public spending graph, wait for block inclusion and impose fees that are disproportionate to many small requests. It is also different from buying conventional prepaid credits, because a conventional provider account still joins the funding identity, API key and usage history.

The original Ethereum Research proposal framed the problem as a three-way trade-off among privacy, security and efficiency. A provider needs payment assurance and abuse controls. A user wants thousands of metered requests without a permanent account profile. The working implementation changes several details from the early proposal, but preserves the core objective: prove the right to spend without revealing which funded identity is spending.

The privacy boundary has four actors

The cleanest way to understand zkAPI is to separate the parties rather than repeat the word “private.” Each participant learns something. The value comes from preventing any one participant from automatically learning everything.

Party	What it can observe	What zkAPI is designed to hide
Ethereum	Deposits, withdrawals, contract activity and timing	The prompts and the specific API sessions paid by a note
zkAPI operator	A valid proof, a spending cap, settlement state and total metered usage	The user’s legal identity, the source deposit and, in direct-key mode, prompt content
API provider	The request, response, model choice, key and network connection	The onchain note and the person who funded it
User application	Local wallet state, prompts, keys and responses	Nothing automatically; endpoint security remains the user’s responsibility

The architecture therefore protects a link, not every datum. Ethereum can see that value entered a vault, but not whether the note later paid for a medical question, a coding request or an RPC query. The zkAPI server can verify authorization and account for spending, but the direct-key path is designed to keep the actual prompt away from that payment intermediary. OpenRouter or another upstream provider still receives content, because the provider runs the model.

This is more useful than it may sound. Billing identity is a durable correlation anchor. A model provider can normally connect a harmless query today, a sensitive query next month and an enterprise project a year later through one account. Fresh, spending-limited keys can reduce that automatic lifetime profile. The upstream service may still infer connections from content or network signals, but it no longer receives the strongest possible join key by default: the stable payer account.

The distinction echoes Block2Learn’s recent analysis of the zk.money privacy wallet. That product hides activity inside a private payment environment while deposits, withdrawals and service metadata remain observable at the edges. zkAPI applies a related principle to digital services. Privacy begins by splitting roles, then depends on whether the edges recreate the link.

How a private balance becomes a short-lived key

The current zkAPI repository identifies the active circuit as zkapi-v2-note-bound-v1. The protocol uses Groth16 over BN254, Poseidon hashes, Baby-JubJub commitments and Schnorr signatures, with a 32-level Merkle tree. Those names matter less than the jobs they perform.

The Merkle tree lets a wallet prove that its note belongs to the funded set without identifying the leaf. A commitment hides the balance and note-specific data while binding the signed state to the same private note used in the membership proof. A nullifier prevents the same authorization state from being accepted twice. The server signature lets the wallet verify that a settlement state is genuine before it replaces the earlier balance.

“Note-bound” is an important improvement over a generic hidden balance. The repository’s technical review explains that both request and withdrawal circuits derive a binding value from the same secret, note identifier, deposit and expiry used in the membership proof. The signed balance commitment includes that value. An attacker should not be able to take a valid signed balance from one note and attach it to a different funded leaf merely because the amounts match.

For direct OpenRouter usage, the server creates a short-lived key with a dollar cap. The key is returned to the client and used from the user’s device. The server later retires the key, captures measured usage and deducts the charge from the private balance. The official OpenRouter management-key documentation confirms that keys can be created programmatically with spending limits and expiry timestamps.

This reservation model solves a practical accounting problem. A provider cannot know the final cost of a variable-length model response before generation. It can know a maximum exposure. zkAPI authorizes a cap, allows the provider to meter the session and then settles the actual amount. The user avoids an onchain action for every token, while the operator avoids extending unsecured credit.

The local daemon exposes familiar interfaces. Existing tools can point an OpenAI-compatible or Ollama-style client at localhost. That compatibility is strategically important. A privacy protocol with a completely new application interface would need to win both cryptographic trust and developer distribution. An adapter that fits existing software can be tested without rewriting the user’s workflow.

The key is temporary, but the provider still has a view

A fresh key limits one form of continuity. It does not erase the request. The official zkAPI documentation states that short-lived OpenRouter keys keep prompts and responses between the user’s application and OpenRouter. “Between” does not mean invisible to OpenRouter. It means the zkAPI payment server need not relay the content in the direct-key path.

That boundary makes upstream data policy part of the product. OpenRouter’s privacy policy says that requests are transmitted to the selected model provider and that providers have different retention and training practices. Users who do not want content used for training must select an endpoint with the appropriate commitment. OpenRouter also offers zero-data-retention and data-collection controls, but those settings are separate from zkAPI’s payment proof.

A user can therefore achieve payment unlinkability while choosing a provider that retains content. Another user can combine a private payment note with a zero-retention route. A third can send requests through the proxy mode, allowing the zkAPI relay to see traffic. These are different privacy products even if they share the same vault.

Content can identify its author without any billing record. A prompt may contain a name, account number, code repository, employer detail or rare personal event. Reused conversation history can connect sessions. Writing style can act as a fingerprint. An uploaded document can include metadata. A model provider that sees these features may infer continuity across fresh keys.

Network metadata creates another layer. The upstream service or gateway can see an IP address unless the connection uses an additional anonymity network. Stable timing and request sizes can narrow possible matches between a public deposit, proof request and inference session. The Ethereum Foundation’s announcement explicitly warns that zkAPI does not provide network anonymity and points privacy-sensitive users toward tools such as Tor.

This is not an argument that the protocol fails. It is a reason to describe the protection precisely. HTTPS protects content in transit even though a website can fingerprint a browser. A zero-knowledge billing proof can protect the payer link even though a provider sees the prompt. Each layer removes a specific correlation surface. The useful question is whether the remaining surfaces are acceptable for the user’s threat model.

Privacy improves when sessions are small, but economics pushes the other way

Proof generation and key management create fixed work. A user can authorize one request at a time for stronger separation, or cover a larger session with one spending cap for better efficiency. Batching reduces the number of proofs and key-management events. It also gives the provider a larger bundle of related activity.

This creates an unavoidable trade-off. The most private unit is often the least economical. A separate key for every short request maximizes fragmentation but increases operational cost, latency and failure surfaces. A long-lived session feels like an ordinary account again, even if it has no public billing identity. Product defaults will determine which side most users choose.

The same issue appears in prompt caching. Providers route related calls together to reuse context and reduce cost. Sticky routing and cached prefixes improve performance, but they also preserve continuity. OpenRouter documents provider-sticky behavior for prompt caching. A privacy client that aggressively fragments sessions may give up some of the very cost and latency advantages that make hosted inference attractive.

Providers also need reliable settlement evidence. The zkAPI review notes that OpenRouter’s aggregate usage interface is not an authoritative final receipt. The implementation therefore uses retirement stages, a grace period, usage capture and revocation before signing a new state. If a key is deleted too early, in-flight calls may be missed. If the grace period is too long, the user waits for balance finality and correlation lasts longer.

The protocol can make these trade-offs explicit. A wallet might offer a “single query,” “short session” and “project session” setting, with clear explanations of proof cost, latency and linkability. Hiding the choice behind an automatic optimization would be easier, but it would make the privacy guarantee difficult to reason about.

Funds can exit without trusting the server, but not without operating machinery

A major design goal is that the operator should not be able to trap balances simply by disappearing. The Ethereum vault supports closing or escaping a note. The wallet can present a proof onchain and begin a withdrawal path. If the user tries to exit with stale state after spending, a challenger can submit newer evidence before the deadline.

The repository’s local acceptance test exercises this lifecycle. It deploys the vault and verifier, makes a real deposit, obtains a lease, sends a request to a mocked provider, settles usage, attempts a stale escape, allows the challenger to contest it and then completes a valid withdrawal. It also tests a failed key-issuance case so that a reserved request cannot later be replayed after the note enters or completes escape.

That test is valuable evidence of design discipline, but it has a clear boundary. The provider and price oracle are local mocks. The chain is Anvil, not public Ethereum. The test does not establish real provider behavior, production host persistence, public-network reorganization handling, browser correctness or the security of an AWS signer. The project’s acceptance documentation states those limits directly.

In production, the challenger must remain available, funded and fast enough to act inside the challenge window. The indexer needs correct Merkle paths. The operator must preserve durable settlement evidence. The oracle must provide a finalized price for converting an ETH balance into a dollar-denominated spending cap. A cryptographic exit is only as operationally useful as the software that monitors and constructs it.

This is familiar from privacy systems such as Zcash. Block2Learn’s analysis of the Ironwood pool migration showed how confidential ownership depends on precise supply accounting, migration logic and wallet support. The privacy proof is central, but user safety also lives in indexers, recovery paths, parameter files and release processes.

The experimental trust assumptions deserve more attention than the headline

The repository calls the protocol experimental. Its deployment guide says the selected Groth16 setup is a single-party setup and that publishing source code does not establish an independent audit or a trusted-setup ceremony. This is not a footnote. Groth16 proving and verifying keys are created from secret setup material. If destructive secrets were retained, the integrity assumptions can be weaker than users expect.

The project pins circuit identifiers, verifier artifacts, vault addresses and key hashes so that incompatible components fail rather than silently mix. Those controls help prevent an application from using the wrong prover with the wrong contract. A hash can identify the artifact that was shipped. It cannot prove that the setup secret was destroyed or that no vulnerability exists in the circuit.

The note-binding construction also depends on several cryptographic assumptions. The repository states that Groth16 on BN254 and Baby-JubJub are not post-quantum. That is not unusual for an experimental Ethereum application in 2026, but it matters for the lifetime of sensitive information. A future break could affect historical privacy or integrity depending on what data and proofs were recorded.

Users should distinguish code availability, testing, audit and production maturity. Open source lets researchers inspect the implementation. Unit and lifecycle tests show that specified cases behave as expected. An independent audit may find design or implementation defects. A multi-party setup ceremony can reduce trust in any one participant. Production evidence reveals failures that neither tests nor audits anticipated. None substitutes for the others.

The correct adoption sequence is therefore cautious. Small balances, short-lived notes and nonsensitive prompts are reasonable for evaluation. Large deposits, regulated workloads or irreplaceable secrets require a higher evidence threshold. The fact that the system is live on mainnet means the contracts can hold real value. It does not make the experiment mature.

Compliance does not disappear when identity leaves the payment key

A provider may want to prevent abuse, enforce sanctions, apply geographic restrictions or respond to lawful requests. Conventional accounts make those controls straightforward because the provider knows the customer. A private usage proof changes the information available at authorization, but does not eliminate the provider’s obligations or terms.

The original research proposal explored policy stakes and public accountability for enforcement. The current implementation emphasizes short-lived keys, caps and ordinary upstream policies. The provider can still reject a prompt, restrict a model or revoke a key. The difference is that the rejection need not reveal the public deposit behind the request.

This can be beneficial for legitimate users. A company may need to prove it can pay without giving the API vendor a permanent map of every team and project. A developer may want to test several models without merging personal and professional usage. An autonomous agent may need a bounded budget without possessing a human’s master billing credential.

It can also complicate dispute resolution. If a provider claims that a session violated policy, the anonymous payer may have difficulty contesting the decision without revealing more information. If an operator under-reports a refund or overstates usage, the user needs verifiable receipts and an exit path. Privacy removes easy identity joins, but it also removes some conventional customer-service hooks.

The most likely commercial design will combine private payment credentials with optional attestations. A business could prove jurisdiction, age, corporate membership or policy eligibility without revealing a full billing identity to every service. That would turn zkAPI from a single privacy tool into a component of selective-disclosure commerce. It would also add credential issuers and revocation systems to the trust model.

Why the investment thesis is infrastructure, not an instant ETH catalyst

zkAPI expands the kinds of services that Ethereum can coordinate. A public chain can hold deposits and enforce exits while zero-knowledge proofs keep individual usage private. This is a credible example of Ethereum acting as a neutral settlement and authorization layer for internet services rather than only for token trading.

The immediate value capture is less obvious. A user funds a note and later withdraws, creating onchain activity. Most proofs are verified offchain during API usage. If the system grows, it could increase demand for Ethereum settlement, oracle access and private-credential infrastructure. The direct fee contribution per request may remain small because the architecture deliberately avoids a transaction for each call.

ETH can benefit as the funding and gas asset in the native deployment, but adoption does not create a mechanical price relationship. Analysts need to measure retained vault balances, deposit and withdrawal frequency, proof demand, operator economics and whether users choose ETH or stablecoin credit versions. A protocol can be strategically important to Ethereum while contributing modest revenue to validators or ETH holders.

The larger option is machine-to-machine commerce. An agent with a private, bounded note can buy model inference, data, RPC access, storage or network capacity without carrying a reusable corporate API key. The spending cap limits loss if the agent is compromised. The private note prevents every task from becoming part of a vendor’s permanent billing profile.

That opportunity depends on standardization. Providers would need to accept proofs or delegate short-lived key issuance. Operators would need common receipt formats. Wallets would need recovery and budget controls. Enterprises would need policy attestations and auditable aggregate spending. The Glamsterdam tooling lesson applies: protocol capability becomes economic infrastructure only when the surrounding software adopts it.

Three scenarios for zkAPI

1. Private billing becomes a standard API option

The project completes independent audits and improves setup trust. More providers support short-lived, spending-limited keys or native proof verification. Wallets offer clear session controls, stronger network-privacy integrations and selective-disclosure credentials. Developers can choose ordinary account billing or private prepaid access as easily as choosing a payment method. zkAPI becomes less visible as a product because its architecture becomes normal.

2. A useful niche for privacy-sensitive developers and agents

The protocol works, but proof friction, operator complexity and provider integration slow broad adoption. OpenRouter remains the main route. Users who understand the threat model value the separation between funding and prompts, while enterprises prefer existing contracts and data-processing agreements. The system supports a sustainable niche in AI, RPC and autonomous agents without changing mainstream API commerce.

3. The remaining metadata defeats the billing split

Providers reliably reconnect sessions through IP addresses, content fingerprints, timing and caching behavior. Users keep long-lived keys for convenience. A setup, circuit or operator failure damages confidence. Compliance pressure concentrates access in a small number of gateways. The vault remains technically interesting, but users discover that hiding the payment source does not materially change the privacy outcome they experience.

The middle scenario is the most defensible starting point. The technology solves a real and bounded problem. Whether that problem is large enough to support a new standard will be determined by provider adoption and user behavior, not by proof construction alone.

What to monitor after the mainnet launch

Signal	What it tests	Why it matters
Independent audits and setup changes	Whether experimental trust assumptions are being reduced	Mainnet availability is not the same as production assurance
Vault deposits and retained balances	Whether users fund real sessions rather than only demos	Retention is stronger evidence than wallet creation
Provider count	Whether zkAPI becomes a standard or remains tied to one routing layer	More providers reduce commercial dependency and expand use cases
Key duration and cap distribution	How users trade privacy against proof and settlement cost	Long sessions may recreate account-like correlation
Failed issuance and settlement rates	Operational reliability across server, provider and chain	A privacy layer that fails unpredictably will be bypassed
Challenge and escape events	Whether stale-state and operator-failure protections work in public conditions	The exit path is central to noncustodial credibility
ZDR and provider-policy defaults	Whether content privacy is paired with payment privacy	Billing unlinkability alone does not protect prompts
Enterprise or agent integrations	Whether bounded anonymous credentials solve a commercial problem	Repeat integration is more meaningful than launch attention

Aggregate metrics should be interpreted carefully. A privacy system should not expose a dashboard that reconstructs individual behavior. Useful reporting can still show total deposits, active notes, settlement volume, proof failures and exit events without publishing which user called which service.

Investors should also separate protocol activity from token narrative. A growing vault balance can indicate demand for private credits. It does not reveal whether users prefer ETH or a stablecoin, whether operators earn attractive margins, or whether the upstream provider captures most of the economics. Each layer has a different revenue model and risk.

Block2Learn evaluation: the honest product is a smaller promise

zkAPI is compelling because it does not require the payment server to know what the user asked and does not require the model provider to know who funded the request. That split removes a powerful correlation key from ordinary API commerce. It also gives software agents a way to hold a bounded spending instrument instead of a reusable identity credential.

The system should not be sold as private AI. Prompts remain visible to the inference provider. Network metadata remains observable. Content can identify the user. Long sessions can become linkable. The current cryptography and operations are experimental, the setup is single-party, and production behavior is not established by a local test with mocked providers.

Those limitations do not erase the contribution. Privacy improves when systems stop collecting links they do not need. A provider needs evidence that usage will be paid. It does not necessarily need the payer’s permanent identity for every request. A settlement layer needs proof that a balance is valid. It does not need the prompt. zkAPI turns that principle into working software.

The most important adoption signal will be precision. If the project, operators and integrators describe exactly which link is hidden, which party sees content and which configuration controls retention, users can build a realistic threat model. If marketing compresses all of that into “anonymous AI,” the product will inherit expectations it cannot meet.

Ethereum’s strategic role is also clearer under the smaller promise. The chain is not making model inference confidential. It is holding value, anchoring note membership and enforcing an exit from a private credit relationship. That is enough to demonstrate a broader function for blockchains: credible settlement among parties that do not need to share the same customer database.

zkAPI therefore deserves attention as billing infrastructure. It is early, technically demanding and dependent on several operators. It is also a concrete attempt to redesign an internet primitive that most users never notice. API keys have become identity keys because payment and access were bundled. zkAPI asks whether they can be separated.

If the answer is yes, the result will not make every prompt secret. It will make one less institution capable of connecting every payment, request and session into a single profile. Privacy rarely arrives as invisibility. It arrives as the deliberate removal of unnecessary joins.

Information is abundant. Structure is rare.

Learning Path

Continue with the Block2Learn Learning Path to build a structured framework for evaluating Ethereum infrastructure, zero-knowledge proofs, private payments, AI service economics and the difference between protocol adoption and token value capture.