zkAPI Is Turning Payment Into a Privacy Layer for AI

Every ordinary API key does two jobs at once. It proves that you are allowed to use a service, and it tells the service which account should pay.

That combination is convenient. It is also a surprisingly powerful identity system.

A developer might make thousands of AI inference calls, blockchain RPC queries or machine-to-machine requests over months. Even when individual requests contain no explicit name, the API key ties them to one account, one billing relationship and potentially one persistent behavioral profile.

On October 1, the Ethereum Foundation introduced zkAPI, an experimental system built with the Open Anonymity Project that separates those two functions. Instead of presenting a persistent identity to prove that a request can be paid for, a user can present a zero-knowledge proof.

The service learns that valid funds exist. It does not need to learn which deposit funded the request.

And unlike the February research proposal that preceded it, zkAPI is now implemented: the client, server and contracts are public, and the system is running on Ethereum mainnet.

The API Key Is an Identity Layer

Think about a typical paid AI API.

You create an account. The account gets connected to a payment method. You receive an API key. Every request carrying that key can then be associated with the same customer.

The provider needs some of this infrastructure for a legitimate reason: metered services need to know whether customers can pay.

But authentication and billing become intertwined.

That means an API provider can potentially accumulate a long history behind the same billing identity. For AI, that history can be unusually sensitive because prompts may contain personal, professional, financial or otherwise private information.

The original ZK API Usage Credits proposal, published by Davide Crapis and Vitalik Buterin in February, framed the problem as a trade-off between two imperfect models.

Web2 billing requires identity and creates persistent links between requests. Paying for every request directly onchain removes the traditional account but creates another problem: individual payments are public, potentially linkable, slower and unnecessarily expensive for high-frequency services.

zkAPI introduces a third model.

The user deposits funds into an Ethereum vault. From there, the spending balance can be represented privately. When access is needed, software on the user’s device generates a zero-knowledge proof demonstrating that a valid funded note can cover a bounded amount of usage.

The verifier can check the proof without learning which funded note produced it.

The Clever Part Is the Temporary Key

There is an important practical problem with private payment systems: existing APIs are not designed around zero-knowledge proofs.

Most providers already understand API keys.

zkAPI therefore does not require every application to abandon that interface. In the runtime-key design described by the Ethereum Foundation, the user’s local client first sends a payment proof to the zkAPI server without sending the prompt itself.

After verifying the proof, the server creates a fresh, short-lived API key with a bounded spending allowance. That key exists locally on the user’s device.

The actual prompt can then travel directly to the inference provider using the temporary key. The payment intermediary does not need to receive the prompt.

When the key expires, usage is recorded in a signed receipt and the actual metered amount is deducted from the user’s private balance. One authorization can therefore cover a session rather than requiring an Ethereum transaction for every model call.

The result is not fully anonymous AI. It is something narrower and arguably more concrete: billing unlinkability.

Why Now

The timing is more interesting than the mechanism alone.

The research design appeared in February 2026. Eight months later, the idea has moved from an Ethereum Research post into an open-source implementation with a mainnet deployment, a local client, browser tooling, server infrastructure and contracts.

That transition matters because AI is creating a new class of machine-scale economic activity.

Software increasingly calls models, data providers, RPC endpoints and other services programmatically. An autonomous agent may eventually maintain relationships with dozens of paid services and generate far more transactions than a human user would manually authorize.

The default Web2 answer is to give that software credentials tied to an account.

Crypto has another possible answer: give software funds and let it prove spending authority cryptographically.

zkAPI is an early implementation of that second model.

This Is More About Access Than Payments

Calling zkAPI a crypto payment system undersells the idea.

The more interesting primitive is private access control backed by money.

Normally, a service decides whether to accept a request by checking identity or credentials. A zero-knowledge payment layer creates another possibility: the service accepts a request because a cryptographic proof establishes that the caller satisfies an economic condition.

The provider does not necessarily need a long-lived customer identity to reach that conclusion.

That distinction becomes particularly interesting for machine-to-machine services.

An agent could need $5 of inference capacity, a few thousand RPC calls, access to a specialized dataset and several image-generation jobs. Creating persistent accounts and managing API keys across every service is workable today, but it reproduces the same identity and credential architecture designed for humans.

Private usage credits point toward something else: temporary, bounded economic permissions.

The AI Use Case Makes the Privacy Problem Obvious

AI inference is a useful starting point because the separation between payment privacy and content privacy is easy to see.

zkAPI does not prevent an AI provider from seeing a prompt that the provider must process.

Instead, it tries to prevent the billing relationship from automatically identifying who paid for that prompt.

In the direct runtime-key architecture, the provider sees the request and the temporary credential. The payment system sees the spending authorization. Neither side alone is supposed to receive both the user’s funding identity and the request content.

This is a different privacy strategy from confidential computing or encrypted inference.

Those technologies try to hide or protect computation and content. zkAPI focuses on metadata generated by economic access.

That makes it complementary rather than necessarily competitive.

It Can Front More Than AI

The Ethereum Foundation’s launch post explicitly describes the architecture as applicable to other metered services.

Blockchain RPC is an obvious example. A developer making private or sensitive onchain transactions may still leak information through the infrastructure used to query the chain. If every RPC request belongs to one persistent paid account, the infrastructure provider gains another correlation point.

Image and video generation, VPN bandwidth and other usage-priced services fit the same structure.

Machine-to-machine payments may be the more speculative but strategically interesting case. Software agents could acquire bounded service capacity without maintaining conventional billing accounts for every interaction.

That does not mean those markets are using zkAPI today. They are proposed use cases, not evidence of adoption. But they show why the project is better understood as a general API primitive rather than an AI-specific wallet feature.

What Is Actually Running

The distinction between research and production status matters here.

As of October 5, the Ethereum Foundation describes zkAPI as live on Ethereum mainnet. The public repository contains the client, browser SDK, protocol code and contracts, while Open Anonymity exposes documentation and a live chat interface using the system.

The current protocol uses Groth16 zero-knowledge proofs over BN254, Poseidon-based components and a Merkle-tree structure for private notes. Nullifiers prevent the same private spending state from being reused without revealing the note itself.

But “live” should not be confused with “mature.”

The project’s own GitHub repository explicitly describes the protocol as experimental.

That is an important qualifier. The discovery here is that a new primitive has crossed from research into something people can inspect and run — not that private API payments have already achieved meaningful adoption.

There Is a Useful Tension With Agent Identity

Crypto’s emerging AI infrastructure is developing two ideas that initially appear contradictory.

One direction is giving autonomous agents persistent identity, reputation and verifiable histories so other systems know which agent they are dealing with.

The other is giving agents ways to interact without unnecessarily exposing persistent identity.

Both can be useful.

An agent negotiating a loan or building reputation may need a durable identity. The same agent buying a small amount of generic compute or inference may not need to expose that identity to every provider it touches.

This suggests that machine identity could become contextual rather than universal.

Sometimes software proves who it is. Sometimes it proves what reputation it has. And sometimes it may only need to prove that it can pay.

zkAPI is interesting because it gives that third case a concrete implementation.

Who Should Pay Attention

AI infrastructure builders should watch whether temporary payment-backed credentials can become practical alternatives to permanent API accounts.

Privacy developers should watch because zkAPI moves zero-knowledge technology into an ordinary internet workflow rather than keeping it inside explicitly crypto-native transactions.

Agent developers should watch the separation between identity and spending authority. Autonomous software may need far more granular permissions than giving every service a permanent credential linked to the same organization or wallet.

API businesses should watch whether proof-based prepaid access can offer a viable model for users who want to minimize account creation without turning every API call into an onchain payment.

And crypto infrastructure builders should notice where Ethereum sits in the architecture. The blockchain is not executing the AI model. It is acting as a settlement and exit layer underneath an offchain service relationship.

That may be a more realistic crypto–AI intersection than trying to put inference itself onchain.

The Interesting Part Is What Disappears

Crypto products often attract attention by adding something: a token, a chain, a wallet, a market or a new financial instrument.

zkAPI is interesting because its ambition is subtractive.

It asks whether a persistent billing identity needs to exist at all for certain internet services.

That is a small architectural change with potentially broad implications. An API still gets paid. A provider can still meter usage. A user can still recover unused funds. But the economic relationship does not automatically need to become a permanent identity relationship.

For humans, that could reduce one source of behavioral profiling.

For autonomous software, it could be even more important. Machines may eventually purchase thousands of tiny services from counterparties they have no reason to know — and no reason to be known by.