The Open Anonymity Project, in collaboration with the Ethereum Foundation, has launched zkAPI, a groundbreaking system designed to decouple API usage from user identity. This innovative solution leverages zero-knowledge proofs to enable metered API access without revealing the user’s personal information to the service provider. The system, now live on the Ethereum Mainnet, represents a significant step forward in digital privacy, particularly for sensitive applications like AI interactions.
The core problem zkAPI addresses is the inherent linkage between API calls and user identity in today’s digital landscape. Every query sent to an AI model or other API service is typically tied to an API key, which in turn is linked to a user account and a payment method. This creates a comprehensive digital footprint, allowing providers to amass extensive usage histories that can be linked back to an individual. The implications are profound, especially when users engage with AI for personal matters such as health concerns, financial planning, or intimate doubts. In the current paradigm, such interactions effectively become a recorded transcript of a user’s thoughts, held by the entity managing the billing relationship. Existing alternatives have presented stark trade-offs: on-chain payments, while transparent, are often slow, costly, and publicly traceable; conversely, relying on third-party assurances of privacy introduces a dependency on trust, which can be fragile.
zkAPI proposes a radical departure from this model by separating the act of payment from the act of identification. Users can pre-load credits – such as Ether (ETH) or USD Coin (USDC) – into a secure vault contract deployed on the Ethereum blockchain. This initial deposit is a standard, one-time transaction. Following this, the user’s balance transforms into a private digital note, akin to digital cash, that is spendable only by the user and untraceable by external observers.
To authorize API usage, the user’s client software generates a compact zero-knowledge proof. This proof cryptographically attests that a funded note exists and is available for spending, without revealing the specific note, its origin, or the identity of the user. Crucially, a single proof can authorize a series of requests, effectively covering an entire session, rather than requiring a separate proof for each individual API call. The AI provider receives the request and can verify the proof of payment, while the payment layer confirms that the funds have been debited. Crucially, neither party gains insight into the connection between the request and the underlying identity or deposit.
The cryptographic underpinnings of zkAPI are designed to ensure both security and privacy. User deposits are recorded as commitments within a Merkle tree, a data structure that allows a proof to confirm membership in the set of valid deposits without revealing which specific deposit is being referenced. Every expenditure is accompanied by a "nullifier," a unique, one-way serial number derived from the secret components of the note. This mechanism ensures that a user who spends within their allocated balance remains anonymous. However, if a user attempts to spend the same balance twice, a duplicate nullifier will be generated, flagging the malicious attempt without exposing any further information about the user or their activities.
The technical architecture of zkAPI involves a clear separation of concerns between the payment layer and the service provider. The process can be visualized in two main paths: the payment path and the conversation path.
The Payment Path:
- Deposit: Users deposit funds into a vault contract on Ethereum. This action is recorded on the blockchain as a transaction, creating a commitment to the deposited funds.
- Note Generation: Upon successful deposit, the system generates a private "note" representing the user’s balance. This note is held by the user and is not publicly visible.
- Proof Generation: When a user wishes to access a service, their client generates a zero-knowledge proof. This proof attests to the validity of a note and authorizes a specific amount of spending.
The Conversation Path:
- Request and Verification: The user’s client sends the API request along with the zero-knowledge proof to the zkAPI server. The zkAPI server verifies the proof, confirming that valid funds are available without learning the user’s identity. If the proof is valid, the server forwards the request to the AI provider. The AI provider processes the request, and the zkAPI server records the usage.
This dual-path system ensures that the entity handling financial transactions (the zkAPI server) only sees evidence of a valid payment and the total amount spent per session, but never the user’s identity, the nature of their queries, or the origin of their funds. Conversely, the AI provider, which processes the actual prompts and generates responses, remains unaware of who is paying for the service.
The concept of a "spending cap" functions as a reservation system. Once a session is authorized, the provider can track the total usage. Upon the expiration of the session’s authorization key, the provider submits a signed receipt detailing the total usage. This amount is then deducted from the user’s note by the zkAPI server. This mechanism prevents retroactive alterations to the bill and allows a single authorization proof to cover an entire session, streamlining the user experience.
zkAPI also offers a simpler "proxy mode," where the zkAPI server acts as a direct relay for requests to the AI provider. While this mode is easier to implement, it does mean the zkAPI server itself has visibility into the traffic. The "runtime-key mode," described above, is designed to eliminate any single point of payment intermediation that could see both the content and the billing identity.
Technically, zkAPI employs advanced cryptographic primitives. It utilizes Groth16 proofs on the BN254 elliptic curve for proving expenditures. Commitments and nullifiers are hashed using the Poseidon hash function, and the notes are organized within a 32-level Merkle tree. The zkAPI server performs spend proof verification off-chain, ensuring efficiency. The vault contract on Ethereum, however, verifies proofs for deposit, closure, and withdrawal operations, guaranteeing that users can exit their funds securely without relying on the honesty of the zkAPI server.
The practical implications of zkAPI are far-reaching, impacting how users interact with services that require metered access. The table below illustrates the division of knowledge:
| Party | Learns | Never Learns |
|---|---|---|
| zkAPI server | A valid payment exists; total spend per session | Who you are; what you asked; which deposit paid |
| AI provider | Prompts and responses; IP address (network) | Who is paying |
| Ethereum (public) | Deposits, closures, withdrawals | What any balance paid for |
The system’s ability to hide payment links opens up a wide array of use cases beyond AI inference. Services that charge per unit of usage, such as blockchain RPC queries, image and video generation jobs, VPNs, bandwidth provision, and machine-to-machine communication, can all benefit from zkAPI’s privacy-preserving payment model. For providers, integration involves accepting cryptographic proofs instead of traditional API keys and settling usage receipts, while existing pricing structures and infrastructure can remain largely unchanged.
Emerging Use Cases and Applications:
- AI Chatbots and Agents: Model calls are metered, and zkAPI conceals which specific note paid for the interaction, as well as any link between consecutive sessions. This is particularly critical for AI assistants handling sensitive personal data.
- Blockchain RPC Services: Queries to blockchain nodes can be metered. zkAPI ensures that the funding source for these queries remains private, shielding users and applications from revealing their on-chain financial activities.
- Image and Video Generation: The generation of digital media, often a computationally intensive process, can be metered by job. zkAPI obscures the identity of the user who paid for these jobs, protecting creators and businesses.
- Virtual Private Networks (VPNs) and Bandwidth: Usage based on time and data consumption can be privatized. zkAPI hides who paid for the connection, enhancing user anonymity for online activities.
- Machine-to-Machine Services: In scenarios where automated agents or services require metered access, zkAPI allows them to pay without requiring traditional accounts or identities, facilitating seamless integration and automation.
While zkAPI offers robust privacy features, it’s important to acknowledge its limitations. The system does not provide network-level anonymity. If a user accesses zkAPI from a stable IP address, the gateway could potentially correlate request patterns, especially if sessions are initiated close in time. For users requiring a higher degree of network privacy, routing requests through anonymizing networks like Tor and using fresh circuits for each session is recommended.
Furthermore, privacy leakage can occur through the content of the prompts themselves. If a user consistently includes personal details, distinctive writing styles, or reuses conversational history or project documents, the AI provider might be able to re-link individual sessions. This presents a trade-off between privacy and utility; highly private, standalone queries are less useful than those that can leverage prior context. The Open Anonymity project has explored mitigations, including the potential use of local or Trusted Execution Environment (TEE) models to generate requests based on shared memory rather than manual user input, thereby preserving session context without direct content disclosure.
The genesis of zkAPI lies in the "ZK API usage credits" design published on Ethereum Research by Davide Crapis and Vitalik Buterin. This foundational paper laid out the theoretical framework for private, metered API access. The Open Anonymity team has since been instrumental in translating this design into a tangible, deployable system, developing the client software, server infrastructure, and smart contracts that form the current zkAPI implementation.
The launch of zkAPI on Ethereum mainnet marks a significant milestone. It provides developers and users with a concrete tool to implement privacy-preserving API access. For those interested in exploring or integrating zkAPI, the project offers resources such as documentation for building a local gateway, allowing any OpenAI-compatible application to be pointed at it. This accessibility is crucial for fostering wider adoption and innovation in the realm of private digital services.
The development and deployment of zkAPI come at a time when concerns about data privacy and digital identity are at an all-time high. As AI technologies become more sophisticated and integrated into daily life, the ability to interact with them without surrendering a detailed personal usage history is increasingly valuable. zkAPI’s approach, grounded in cutting-edge cryptography and blockchain technology, offers a compelling solution to a pervasive problem, potentially setting a new standard for how metered services are accessed and paid for in the digital age. The project’s ongoing development and the exploration of its limitations and further enhancements will be critical in shaping its long-term impact.
