In a significant advancement for digital privacy, a new protocol dubbed zkAPI has gone live on the Ethereum Mainnet, offering an unprecedented level of anonymity for users interacting with metered Application Programming Interfaces (APIs). Developed by the Open Anonymity Project with support from the Ethereum Foundation, zkAPI leverages cutting-knowledge zero-knowledge proofs (ZKPs) to decouple payment information from user identity and service usage. This innovation promises to reshape how individuals and organizations access AI models and other pay-per-use digital services, addressing a critical privacy deficit in the current digital economy.
The core promise of zkAPI is elegantly simple yet technically profound: users can deposit credits into an Ethereum-based vault in a single, traceable transaction. From that point onward, all subsequent payments for API usage are authorized through cryptographic proofs, ensuring that the service provider sees only valid requests and the payment layer observes only legitimate spending, with no discernible link between the two. This means neither party can connect individual API calls back to the original deposit, nor can they build a comprehensive profile of a user’s activity over time.
The Pervasive Problem of Identity-Linked AI Usage
The launch of zkAPI comes at a crucial juncture, as artificial intelligence (AI) models become increasingly integrated into daily life and professional workflows. The current paradigm for accessing most AI APIs, from large language models (LLMs) to image generation services, invariably ties every interaction to a user’s identity. Typically, an API key is linked to a user account, which in turn is connected to a payment method—be it a credit card, bank account, or other identifiable financial instrument. This architecture means that every prompt, every query, and every generated response becomes part of a persistent record, allowing service providers to compile extensive, longitudinal profiles of user behavior, preferences, and even deeply personal information.
The implications of this data collection are far-reaching. Users frequently engage AI models with inquiries about their health, financial planning, personal challenges, creative endeavors, and sensitive professional tasks. Under the prevailing model, this translates into an ongoing, detailed transcript of an individual’s thoughts, questions, and intentions being handed over to the entity managing the billing relationship. The data, often aggregated across billions of user interactions monthly by major AI providers, represents an invaluable asset for targeted advertising, product development, and potentially even surveillance.
Prior to zkAPI, the alternatives for privacy-conscious users were largely inadequate. Attempting to pay per request directly on a public blockchain, for instance, would be slow, prohibitively expensive due to transaction fees, and paradoxically, entirely traceable by anyone with access to the public ledger. The other option—trusting a centralized middleman not to scrutinize or misuse personal data—has been eroded by numerous data breaches and privacy scandals, highlighting the inherent fragility of trust-based systems in the digital realm. The demand for robust, verifiable privacy solutions has never been higher, fueled by growing public awareness and increasingly stringent data protection regulations worldwide, such as GDPR and CCPA.
The Zero-Knowledge Solution: Separating Payment from Identity
The foundational idea behind zkAPI, first outlined in a research paper titled "ZK API usage credits: LLMs and beyond" by Davide Crapis and Vitalik Buterin, is to fundamentally separate payment from identity through the power of zero-knowledge cryptography.
Here’s how the system works in practice:
- Anonymous Deposit: A user initiates a single, ordinary transaction to deposit credits (e.g., ETH, USDC, or other supported cryptocurrencies) into a smart contract vault on the Ethereum blockchain. This transaction is public and traceable to the user’s initial wallet, but it is the only link.
- Private Note Creation: Once deposited, these credits are transformed into a "private note"—a cryptographic representation of digital cash that only the user can spend. Crucially, this note is unlinkable to the original deposit by external observers.
- Zero-Knowledge Proof Generation: When a user wishes to make an API call, software running on their local machine generates a small zero-knowledge proof. This proof cryptographically attests that:
- The user possesses a funded private note covering the requested spend.
- This specific note has not been spent before (preventing double-spending).
The critical aspect is that the proof reveals nothing else. It doesn’t disclose which specific note is being used, which original deposit it came from, or the identity of the user.
- Verification and Unlinkable Spending: The API service provider receives this proof and can verify its validity instantly without ever learning the user’s identity or the details of their payment source. At the payment layer, individual requests appear as isolated, unlinkable transactions.
Two key cryptographic components underpin zkAPI’s safety and privacy guarantees:
- Merkle Tree Commitments: Deposits are recorded as commitments within a Merkle tree. This structure allows a user to prove that their private note is among a set of valid, unspent notes without revealing which specific note it is. It’s like proving you have a valid ticket without showing the ticket’s serial number.
- Nullifiers: Each time a private note is spent, a unique, one-way serial number called a "nullifier" is published. This nullifier is derived from the note’s secret. If a user attempts to double-spend the same balance, a duplicate nullifier will be published, immediately flagging the fraudulent attempt. However, the nullifier only exposes the attempt; it does not reveal the user’s identity or link back to the original deposit, preserving the user’s anonymity even in cases of malicious behavior. This robust mechanism ensures accountability without compromising privacy for honest users.
Operational Mechanics: A Dual-Path System
The zkAPI architecture meticulously separates the payment flow from the actual API interaction, ensuring a strict compartmentalization of information. This is achieved through a dual-path system involving a short-lived key and its associated usage receipt.
The core operational flow unfolds as follows:
- User Client Generates Proof & Requests Key: The user’s client software generates a zero-knowledge proof confirming they have sufficient balance in a private note. This proof is sent to the zkAPI server.
- zkAPI Server Issues Runtime Key: Upon verifying the proof (off-chain, for speed and efficiency), the zkAPI server issues a temporary, short-lived "runtime key" to the user. This key is associated with a specific spending cap and expiration time. The server also records the nullifier to prevent double-spending.
- User Interacts with AI Provider: The user then uses this runtime key to make requests directly to the AI service provider. The AI provider sees the key, validates it against the zkAPI system (potentially via an API endpoint provided by zkAPI), and processes the user’s prompts and generates responses. The provider has no knowledge of the user’s identity or payment source; it only sees the runtime key as a valid authorization.
- Usage Receipt and Settlement: When the runtime key expires or the session ends, the AI provider generates a signed "usage receipt" detailing the total amount of API resources consumed during that session. This receipt is cryptographically signed by the provider, making it tamper-proof. The user’s client then presents this receipt to the zkAPI server.
- Balance Deduction: The zkAPI server deducts the amount specified in the signed usage receipt from the user’s private note balance. This deduction is verifiable and ensures that neither the user nor the provider can unilaterally alter the bill after the fact.
Crucially, this "runtime-key mode" ensures that the server handling payments never sees the content of the API requests, and the AI provider seeing the content never learns the billing identity behind the key. This separation is a cornerstone of zkAPI’s privacy design.
For simpler deployments, zkAPI also offers a "proxy mode." In this mode, the zkAPI server directly relays requests from the user to the AI provider. While easier to set up and operate, this mode means the relay server does see the traffic, thus introducing a potential point of correlation. The runtime-key mode was specifically engineered to eliminate this intermediary visibility for maximum privacy.

The underlying cryptographic infrastructure of zkAPI is robust. It utilizes Groth16 for proving spends on the BN254 curve, employs the Poseidon hash function for commitments and nullifiers, and maintains notes within a Merkle tree 32 levels deep. While the zkAPI server verifies spend proofs off-chain for performance, the vault contract on Ethereum mainnet verifies similar proofs during deposit, close, and escape operations. This on-chain verification ensures that users’ funds are always secure and that their ability to withdraw or close their accounts is never dependent on the honesty or availability of the zkAPI server.
Practical Implications and Broader Use Cases
The practical benefits of zkAPI are evident across the ecosystem:
| Party | Learns | Never Learns |
|---|---|---|
| zkAPI Server | A valid payment exists; total dollars/session | Who you are; what you asked; which deposit paid |
| AI Provider | Prompts and responses | Who is paying; any link to other sessions or deposits |
| Ethereum (public) | Deposits, closes, withdrawals | What any balance paid for; specific user activities |
This clear delineation of information provides verifiable privacy that transcends mere trust. For users, it means the freedom to explore AI capabilities without the looming concern of creating a permanent, identifiable data trail. This can foster greater creativity, encourage more candid inquiries, and enable the use of AI in highly sensitive domains where identity leakage is unacceptable.
While AI inference is the immediate and most prominent application due to the highly personal nature of prompts, zkAPI’s architecture is versatile enough to support any service that charges on a per-use basis. The same client and smart contracts can be adapted to front a wide array of metered digital utilities:
| 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 needing an account or identifiable wallet |
For service providers, integrating zkAPI offers a streamlined payment acceptance model. Instead of managing complex user accounts, payment methods, and API keys, providers simply accept a zero-knowledge proof as authorization and settle signed usage receipts. This simplifies billing infrastructure, potentially reduces compliance burdens related to personal data handling, and opens their services to a new segment of privacy-conscious users. Pricing, rate limits, and existing infrastructure can remain largely unchanged, making adoption relatively straightforward.
Limitations and Future Considerations
Despite its significant privacy enhancements, zkAPI, like any technology, has inherent limitations that users should be aware of. Its protections primarily focus on payment unlinkability and identity obfuscation at the billing layer. Two key areas remain outside its direct scope: network anonymity and content privacy.
On the network side, the zkAPI gateway or the AI provider might still observe network metadata, such as a user’s IP address. If a user consistently sends requests from the same stable IP address, it could theoretically allow for correlation of request patterns over time, even if the payment itself is anonymous. For users seeking the highest level of network anonymity, routing requests through privacy-enhancing networks like Tor, potentially using a fresh circuit for each session, is a recommended mitigation strategy.
On the content side, while zkAPI hides who is paying, the AI inference provider still receives and processes the actual prompts and responses. Individual sessions could potentially be re-linked by the provider if the prompts contain consistent personal details, a distinctive writing style, reused conversation history, or specific project documents. Shared content can act as a "fingerprint." This highlights a fundamental privacy-utility tradeoff: highly granular, standalone queries offer greater privacy but may lack the conversational context that makes AI models most useful. Future mitigations could involve leveraging local AI models or Trusted Execution Environments (TEEs) to generate requests on top of shared memory, thus avoiding the direct transmission of sensitive context to the provider. The Open Anonymity project’s blog post on "unlinkable inference" delves deeper into these challenges and potential solutions.
Background, Development, and Mainnet Deployment
The journey of zkAPI from a theoretical concept to a live mainnet implementation underscores the rapid innovation within the Web3 and privacy-enhancing technology sectors. The initial design, "ZK API usage credits," published on Ethereum Research by prominent figures Davide Crapis and Vitalik Buterin, laid the theoretical groundwork for this novel approach to anonymous digital payments. Their paper outlined the cryptographic primitives and architectural considerations necessary to achieve verifiable unlinkability for metered services.
Recognizing the immense potential of this design, the Open Anonymity team took on the ambitious task of transforming the theoretical framework into a robust, production-ready system. With crucial support from the Ethereum Foundation, which champions foundational research and development for the Ethereum ecosystem, Open Anonymity developed the necessary client software, server infrastructure, and smart contracts. This collaborative effort culminated in the successful deployment of zkAPI on the Ethereum Mainnet, a significant milestone that makes this advanced privacy technology accessible to a global audience today.
Users interested in exploring zkAPI can now engage with the live system. Comprehensive documentation and resources are available for those wishing to build and run the local gateway, allowing any OpenAI-compatible application to utilize zkAPI’s privacy-preserving features.
Industry Impact and Future Outlook
The launch of zkAPI represents more than just a new payment mechanism; it signals a maturing landscape for privacy-enhancing technologies within the decentralized web. By providing a concrete, deployable solution to the pervasive problem of identity-linked API usage, zkAPI stands to significantly impact user trust in AI services, potentially accelerating broader adoption, particularly in sensitive enterprise and personal contexts.
As digital interactions become increasingly commoditized and data privacy regulations tighten globally, solutions like zkAPI will likely become essential infrastructure. It empowers users with greater control over their digital footprints and forces service providers to compete not just on features and price, but also on verifiable privacy guarantees. This shift could foster a more ethical and user-centric digital economy, where individuals can engage with powerful AI tools without inadvertently sacrificing their fundamental right to privacy. The Open Anonymity Project and the Ethereum Foundation have thus delivered a critical piece of the puzzle for building a more private, secure, and decentralized internet.






