The Open Anonymity Project, in collaboration with the Ethereum Foundation, has launched zkAPI, a groundbreaking system designed to enable metered API access without revealing user identities. This innovative solution utilizes zero-knowledge proofs to decouple payment from personal identification, allowing users to leverage powerful APIs, including AI services, with unprecedented privacy. zkAPI is now live on the Ethereum Mainnet, marking a significant step towards a more privacy-preserving digital ecosystem.
The Problem: Identity in the Age of Pervasive APIs
In the current digital landscape, almost every interaction with an API is tethered to an identity. Whether it’s an API key linked to an account or a payment method associated with a user, the provider of a service can meticulously track and profile every request made. This inherent traceability raises substantial privacy concerns, particularly when engaging with services that handle sensitive personal information. Users often interact with AI models for deeply personal matters, seeking advice on health, finances, or personal dilemmas. Under existing models, such interactions result in a detailed, ongoing transcript of their thoughts being accessible to the service provider.
The existing alternatives offer little respite. On-chain payments per request, while transparent, are notoriously slow, costly, and publicly visible on the blockchain, exposing the transaction trail to anyone. The alternative is to trust a third party not to abuse their access to user data, a trust that is often misplaced in today’s data-driven world. This leaves users in a precarious position, forced to trade their privacy for access to essential digital services.
The zkAPI Solution: Decoupling Payment from Identity
zkAPI fundamentally rethinks API access by separating the act of payment from the user’s identity. The system operates on a simple yet powerful principle: users deposit credits, such as ETH or USDC, into a dedicated Ethereum vault contract. This initial deposit is a standard, on-chain transaction. Following this deposit, the user’s balance transforms into a private, digital asset – akin to digital cash – that only they can spend and which cannot be traced back to the original deposit.
To authorize an API request, the user’s software generates a compact zero-knowledge proof. This proof cryptographically attests to the validity of the user’s funded balance without revealing any identifying information. It asserts that a pre-funded note covers the current expenditure and that this specific note has not been spent previously. This proof can encompass a single API call or an entire session of interactions, streamlining the process and reducing the computational overhead.
The magic of zero-knowledge proofs lies in their ability to allow one party to prove the truth of a statement to another party without revealing any information beyond the truth of the statement itself. In the context of zkAPI, the API provider receives a proof that confirms a valid payment is associated with the request, but crucially, they do not learn which specific note was used, from which deposit the funds originated, or the identity of the user. The payment layer, where the transaction is settled, sees the expenditure but remains unaware of the specific API requests or the content of those requests. This separation ensures that neither the API provider nor the payment processor can link a user’s requests to their identity or to each other.
Underpinning zkAPI’s security and privacy are two key cryptographic mechanisms. User deposits are represented as commitments within a Merkle tree, a data structure that allows for efficient and secure verification. A proof can confirm that a user’s note is part of a valid set of commitments without revealing the specific note’s position in the tree. Every expenditure is associated with a "nullifier," a unique, one-way identifier derived from the secret components of the user’s note. This nullifier serves as a serial number for the spent funds. If a user attempts to spend the same balance twice, a duplicate nullifier will be generated, which is immediately detectable by the system, flagging the fraudulent attempt without revealing any other sensitive information about the user.
How zkAPI Operates: A Two-Pronged Approach
The zkAPI system is engineered for efficiency and privacy, operating through a combination of on-chain smart contracts and off-chain computation. The process can be broadly understood through its payment and conversation paths, which intersect at a short-lived key and its corresponding usage receipt.
The initial step involves the user depositing funds into the zkAPI vault contract on the Ethereum blockchain. This action establishes a verifiable balance that is secured by the immutable nature of the blockchain. Subsequently, when a user wishes to interact with an API, their client software generates a short-lived key. This key serves as a temporary authorization token.
The user’s client then sends the API request, along with the generated zero-knowledge proof and the short-lived key, to the zkAPI server. The zkAPI server, acting as an intermediary, verifies the zero-knowledge proof. This verification confirms that the user has sufficient funds and has not previously spent these funds. Upon successful verification, the zkAPI server forwards the request to the actual API provider. Crucially, the zkAPI server never sees the content of the API requests themselves; it only verifies the payment authorization.
The AI provider, responsible for processing the API request (e.g., generating text, images, or code), receives the request and returns the output. Simultaneously, the zkAPI server records the total usage associated with the short-lived key. This usage data is then used to generate a signed receipt.
The final step involves the zkAPI server deducting the recorded usage from the user’s balance held in the Ethereum vault. This deduction is performed by publishing the signed usage receipt and the corresponding nullifier to the blockchain. The short-lived key, having served its purpose for the session, expires. This model ensures that the API provider sees the content of the prompts and responses but remains unaware of the payer’s identity. Conversely, the zkAPI server, which handles the payment layer, knows that a valid payment exists and can track total expenditure per session, but it does not learn the user’s identity, the specific content of their requests, or the origin of their deposited funds.
The system employs a "spending cap" mechanism, functioning as a reservation of funds. Once the short-lived key expires, the API provider submits a signed receipt detailing the total usage during that session. The zkAPI server then deducts this amount from the user’s note. Neither the provider nor the zkAPI server can retroactively alter this bill, and a single authorization covers an entire session, eliminating the need for a proof per individual call.
zkAPI also offers a simpler "proxy mode." In this configuration, the zkAPI server directly relays requests to the API provider. While this mode is easier to implement and manage, it means the zkAPI server itself can observe the traffic. The "runtime-key mode," as described above, is designed to ensure that no payment intermediary ever has visibility into the actual API request content.
Technically, zkAPI leverages Groth16 for proving spends on the BN254 elliptic curve, the Poseidon hash function for commitments and nullifiers, and a 32-level Merkle tree to manage user notes. The zkAPI server verifies spend proofs off-chain for speed. The vault contract, however, verifies these proofs on-chain for critical operations such as deposits, closures, and withdrawals, ensuring that users can always exit their funds without relying on the honesty of the zkAPI server.
A Glimpse into Practical Implementation and Use Cases
The practical implications of zkAPI are far-reaching, offering a nuanced privacy model where different parties learn specific pieces of information while others remain concealed.
| Party | Learns | Never Learns |
|---|---|---|
| zkAPI Server | Valid payment exists, total dollars per session | Who you are, what you asked, which deposit paid |
| AI Provider | Prompts and responses (model processing) | Who is paying |
| Ethereum (Public) | Deposits, closes, withdrawals | What any balance paid for |
This architecture opens up a wide array of use cases beyond just AI inference, extending to any service that operates on a metered, pay-per-use model.
| Use Case | Metered Unit | What the Payment Layer Hides |
|---|---|---|
| AI chat and agents | Model calls | Which note paid, and any billing link between sessions |
| Blockchain RPC | Queries | Which funding source paid for the queries |
| Image and video generation | Jobs | Who paid for which jobs |
| VPNs and bandwidth | Time and data | Who paid for the connection |
| Machine-to-machine services | Per-task spend | Agents pay without an account |
For API providers, integrating with zkAPI involves a shift from managing API keys and user accounts to accepting zero-knowledge proofs and settling signed usage receipts. The core pricing structures, rate limits, and underlying infrastructure can remain largely unchanged, simplifying the adoption process.
Limitations and Future Considerations
Despite its revolutionary approach, zkAPI acknowledges certain limitations. The primary challenge lies in network anonymity. While zkAPI secures the payment trail, the gateway itself can potentially correlate user activity if requests are consistently sent from a static IP address. Users requiring a higher degree of privacy can mitigate this by routing their requests through privacy-enhancing networks like Tor, initiating a fresh circuit for each session.
Content privacy is another area where zkAPI offers a foundational layer, but further considerations are necessary. If a user consistently provides personal details, exhibits a distinct writing style, reuses conversational history, or submits identical project documents across sessions, the inference provider might be able to re-identify them based on the content itself. This presents a privacy-utility trade-off: highly private standalone queries are less useful due to the absence of context, while more context-rich interactions increase the risk of re-linking. Emerging technologies like local or Trusted Execution Environment (TEE) models that process requests using shared memory rather than manual input could offer future solutions to enhance content privacy. The Open Anonymity project has further elaborated on these challenges and potential solutions in their blog posts.
Background and Evolution
zkAPI represents the tangible implementation of the "ZK API usage credits" design, initially conceptualized and published on Ethereum Research by Davide Crapis and Vitalik Buterin. This foundational work laid the theoretical groundwork for creating a privacy-preserving API access model. The Open Anonymity team has been instrumental in translating this design into a functional system, developing the necessary client software, server infrastructure, and smart contracts that are deployable today.
The project’s launch on Ethereum Mainnet signifies a critical milestone, moving from a research concept to a live, usable service. The Open Anonymity Project encourages developers and users to explore zkAPI. They can try out the service directly or, for those interested in self-hosting, build the local gateway and configure OpenAI-compatible applications to use it, following the comprehensive documentation available. This open approach fosters wider adoption and encourages further innovation in the realm of private API interactions.
