Key points

  • zkAPI lets users deposit credits such as ETH or USDC in an Ethereum vault and later prove authorization for bounded API usage without revealing the original deposit or identity.
  • A runtime-key mode keeps prompts flowing directly to the API provider, while a simpler proxy mode trades stronger traffic privacy for easier integration.
  • The system protects the link between billing and identity, but providers can still observe prompts and network metadata unless users add separate privacy protections.

The Ethereum Foundation and Open Anonymity Project have launched zkAPI on Ethereum mainnet, introducing a payment and authorization layer designed to let people use metered online services without linking every request to a named billing account. The October 1 release targets application programming interfaces, including artificial-intelligence services, where access is commonly tied to an account, payment card and long-lived API key.

Payments and requests follow separate paths

Under the system described by the Ethereum Foundation, a user first deposits credits such as ether or the USDC stablecoin into an Ethereum vault. Local software then creates a zero-knowledge proof showing that a valid credit note exists and authorizing a limited amount of spending. The service can verify that proof and account for usage without learning which deposit created the note or who controls it.

Related reporting: Shielded Bitcoin design targets private transfers without a fork

The design uses a Merkle tree to hold commitments representing deposited notes. When a note is spent, a nullifier prevents the same value from being used again, while the proof avoids exposing the note itself. The Foundation said the initial implementation uses Groth16 proofs over the BN254 curve, Poseidon hashing and a 32-level Merkle tree. Those technical choices make the launch an operating mainnet system rather than only a proposal, though adoption will depend on service providers integrating it.

Two access modes offer different privacy trade-offs

The preferred runtime-key mode generates a short-lived, spending-capped key on the user's device after the zero-knowledge proof is accepted. Requests then travel directly from the user to the service provider, so the payment layer does not see the content. This approach is intended to limit the damage from a leaked key because its value and lifetime are constrained.

A simpler proxy mode is also available for services that do not issue temporary credentials. In that arrangement, a relay forwards requests and charges the private credit balance. Integration is easier, but the relay can see the traffic passing through it. The distinction matters because zkAPI's privacy claim concerns the connection between a payment and a user's identity; it does not make every part of an API interaction anonymous.

Independent coverage from ETH Daily noted that the underlying provider may still receive prompts and network information such as an IP address. Users seeking stronger confidentiality would need separate measures for their connection and request content. The project also allows unused deposited value to be withdrawn, while actual charges are based on measured consumption rather than a fixed subscription.

A test for privacy-preserving service markets

The launch extends zero-knowledge proofs beyond asset transfers into everyday digital-service billing. For developers, the immediate question is whether API vendors will accept the additional verification and credential flow. For users, the appeal is narrower account exposure: a service can know that usage is funded without receiving the payment history or identity information normally attached to an account.

The system does not remove all trust or compliance questions. Providers still operate their services, define prices and decide what data they collect from requests. Smart-contract risk, wallet security and the cost of Ethereum transactions also remain relevant. zkAPI nevertheless provides a concrete model for separating authorization from identity, with the mainnet release giving developers a live environment in which to test whether private, usage-based access can work at practical scale.

Sources

AI-generated editorial image; not a photograph of the reported event. Prepared with AI assistance and source verification.