zkAPI Explained: Private API Payments and Their Limits

zkAPI is an experimental zero-knowledge billing layer for metered APIs. It lets a user fund a balance, prove that a capped API session is paid for, and reduce the link between an on-chain deposit and later requests. It does not hide prompts from the provider, erase IP or timing metadata, or guarantee anonymity. As of 2 October 2026, there is also a version caveat: the Ethereum Foundation’s launch post and the current public repository docs describe different billing assets.

What zkAPI is designed to separate

Conventional API billing often ties a customer account, payment method or long-lived key to repeated usage. That creates a billing trail that can help a provider connect sessions. zkAPI’s stated goal is narrower: let a client prove that a metered request or session is funded without exposing which on-chain deposit backs it.

In the design described by the Ethereum Foundation’s 1 October introduction, a local client obtains a short-lived, capped API key after presenting a zero-knowledge proof. In the direct-provider mode, prompts travel from the client to the inference provider; the payment server handles authorization and settlement, not the prompt text. The post also describes a simpler proxy mode, where the relay does see the traffic. These are project-described privacy properties, not an independent guarantee that every deployment or log configuration prevents correlation.

How a metered request works

The current project repository describes a client, a billing server and an Ethereum vault. At a high level, the flow is:

Fund a balance. The user deposits into a vault. The public chain records the transaction and its address; zkAPI aims to keep subsequent usage from pointing back to that deposit.
Prove spendable credit. The client holds private note data and creates a zero-knowledge proof that the balance covers a bounded spend. A nullifier helps prevent the same credit from being spent twice. The current repository identifies its v2 circuit as Groth16 over BN254, with Poseidon and note-bound commitments.
Request a capped lease. The server checks the proof and authorizes API access for a limit or session. In the design announced by the Foundation, the provider receives a short-lived key rather than the user’s deposit address.
Settle actual usage. The provider measures service usage and the system charges the corresponding balance. The user can close the note and withdraw what remains, subject to the deployed contract and its rules.

The proof concerns payment authorization; it does not certify that an API response is correct, that the provider will retain no logs, or that an AI agent is permitted to make the purchase. If agents are involved, spending authority and payment privacy are separate controls. See our guide to AI agent identity and least privilege for the authorization layer.

Who can see what

The following table summarizes the project’s intended separation, not a third-party security audit.

Party	Can see in the described flow	Not automatically revealed by the payment proof
zkAPI billing server	A valid authorization, lease limits and settlement or usage totals	The prompt in direct-provider mode and the specific deposit behind a private note
API or AI provider	The request content it processes, its response and service-side usage	The on-chain deposit that funded the lease, if the separation works as described
Ethereum network	Public deposits, contract activity and withdrawals	The prompt or which API call used the balance

There are important qualifications. A server can observe network metadata such as a client IP address and request timing. A proxy mode can see prompts. An inference provider necessarily sees the content it processes and may infer identity from names, documents, distinctive facts or repeated conversation context. Public deposit and withdrawal activity can also be linked to a person if the address or surrounding activity identifies them.

That is why unlinkable billing is not the same as anonymous browsing or confidential inference. zkAPI targets one relationship—the link between funding and API usage. It does not, by itself, hide network origin or encrypt prompts from the provider.

zkAPI and x402 solve different problems

x402 is an open standard for internet-native payments over HTTP. It focuses on how a client and a service negotiate and settle a payment. zkAPI focuses on whether metered API use can be authorized without revealing which private balance funded it. The two ideas address different layers; their privacy properties depend on the actual payment rail, wallet, client and server configuration.

For a concrete example of a stablecoin payment stack, see our Circle Arc and x402 guide. A payment protocol and an unlinkable-billing design should not be treated as interchangeable just because both can support pay-per-use services.

A material version caveat: ETH versus USDC

The public materials did not describe one consistent asset configuration on 2 October 2026. The Ethereum Foundation’s 1 October post says users can deposit “ETH, USDC, etc.” and links a mainnet vault described as holding USDC credits. The current ethereum/zkapi repository, however, describes the active v2 protocol as using native ETH. Its native billing documentation specifies gwei ledger units and says this is not a stable-dollar deposit or a swap into USDC.

The repository’s deployment documentation describes a native-ETH vault and calls the selected Groth16 setup experimental and single-party. The note-bound commitment documentation also says that publishing code does not establish an independent audit or setup ceremony; it notes that Groth16/BN254 and Baby-JubJub are not post-quantum.

Treat the launch post as a description of the announced system, not proof that every announced asset or contract matches the repository’s current v2. Before integrating, verify the chain, vault address, billing asset, circuit identifier, verifier and proof-artifact hashes against the exact deployment you intend to use. The repository itself labels the protocol experimental; a live address or passing local tests is not the same as production assurance.

A practical checklist for builders

Pin the deployment. Confirm chain ID, vault address, asset denomination, circuit ID, verifier and matching proof keys from current first-party configuration.
Review setup provenance. Understand who generated the proving setup, what trust assumptions remain and whether an independent audit covers the exact deployed version.
Test failure and recovery paths. Exercise spend caps, expired leases, duplicate requests, provider errors, settlement retries, challenges and withdrawals on a test deployment before risking funds.
Map the data path. Identify which component receives prompts, IP addresses, timestamps, usage receipts and API credentials; set retention and access controls accordingly.
Limit sensitive context. Do not send personal or confidential material to a remote model on the assumption that private billing also hides prompt content.

FAQ

Does zkAPI make AI prompts private from the model provider?

No. The provider processes the prompt and can see its content. zkAPI aims to separate usage from the on-chain funding source; it does not make remote inference confidential.

Does the current zkAPI implementation support USDC?

The Ethereum Foundation’s 1 October launch post describes deposits in ETH, USDC and other assets. The repository’s current v2 documentation, checked on 2 October 2026, specifies native ETH billing in gwei. Confirm the exact deployment configuration instead of assuming the announcement’s asset list applies to the current branch.

Is zkAPI ready for production use?

The public repository describes the protocol as experimental and its selected setup as single-party. Those disclosures are reasons to verify the deployed version, setup provenance, audits and recovery operations before production use; open source alone is not a security certification.

Sources

If you’re evaluating private metered API access for a product, talk to SignorCrypto about a proof of concept that tests the privacy boundary, deployment configuration and recovery path before real funds are involved.