An automated system can call an API in milliseconds. Paying for that call still tends to require an account, a billing profile, a card, and a record of every request attached to the same identity. OpenZK explores a more direct arrangement: fund a balance once, then prove that an individual request can be paid for.
The balance lives in a private note held by the browser. A user deposits ETH into a vault on Ethereum, then spends from the note on metered inference. The browser produces a zero-knowledge proof as part of payment authorization. The service can check the payment conditions without receiving the note secret or the full private balance.
That is the working idea behind OpenZK: cash-like payment state for software that makes many small requests.
The four steps
- Fund. Connect an Ethereum wallet and deposit ETH. The deposit is a public transaction; the browser installs the corresponding private note after confirmation.
- Prove. For a paid request, the browser uses its note state and the proving worker to produce a proof that satisfies the protocol's payment conditions.
- Spend. The proof authorizes a limited inference lease. The browser sends its prompt to OpenRouter and streams the response.
- Settle or exit. Usage is settled against the note. The holder can close the note through a mutual withdrawal and receive the remaining ETH at an Ethereum address.
The result is a prepaid workflow. There is no recurring invoice to reconcile before each call, and a service does not need the payer's wider purchase history to verify this payment.
What is public, and what remains private
The public edges matter. Deposits and withdrawals appear on Ethereum. A withdrawal destination is public. Network observers may see when a browser contacts a service. The model provider receives the prompt and any system instructions that the application sends to it.
Inside the payment flow, the note secret stays in the browser SDK. A proof demonstrates the required relation without disclosing the full note state. That is a specific payment privacy property; it does not make every part of the application anonymous.
Keeping this boundary clear is useful for product design. A developer should still decide what user data appears in prompts, what an operator logs, and how a browser protects its local state. We discuss those boundaries in The boundaries of payment privacy.
Why software needs this
Per-request payments are useful when a workload is unpredictable. A research agent might make a few model calls one day and hundreds the next. A developer tool might pay for one expensive inference only when a user asks for it. A browser application may want to fund a limited balance without asking its users to create another provider account.
OpenZK currently focuses on browser-held notes and metered OpenRouter inference. The same payment concept can inform other API markets, but the present toolkit should be evaluated against its actual integration surface. Read the use cases or start with the developer guide.