OpenZK started with private inference because it is the easiest place to see the problem: software needs to buy something small, right now, from a payment stack built for people. Accounts, cards, billing profiles, and permanent API keys all presume a human at one end of the wire. An agent that needs three cents of compute should not have to inherit that machinery.
Stripe's lasting achievement was making it dramatically simpler for a website to accept money from a person. The next payment layer has to do the same job for machines, and its primitives look different because its customer is different. An agent should not need a human identity, a credit card, a billing account, or a permanent API key to buy a fraction of a cent of work.
The primitive underneath
zkAPI rests on one shape of flow. Deposit value. Receive private spending power. Prove a valid payment with zero knowledge. Consume a service.
The provider verifies the only fact it needs: that this usage was paid for. Who funded it, how much remains in total, and what else that balance has bought can stay private. That is a different contract from an account. It is closer to cash.
More than tokens
Inference came first because the demand is visible today, but machines increasingly pay for much more than tokens: RPC calls, GPU compute, storage, databases, search, data feeds, image and video generation, proxies, bandwidth, and the long tail of specialized APIs. Over time, a growing share of this commerce becomes machine-to-machine, with agents buying services from other agents.
The familiar path is a chain of human artifacts:
USER → ACCOUNT → CARD → API KEY → SERVICE
A machine-native path can be shorter:
WALLET → PRIVATE CREDIT → PROOF → SERVICE
Payment becomes a protocol primitive instead of an onboarding process.
What each side needs
For this to work, three parties have to gain something at once. Developers need to accept private prepaid payments without becoming a billing business. Agents need to fund once and spend across services. Infrastructure needs to meter usage without maintaining customer accounts.
Stripe abstracted payment methods, checkout, billing, and authorization behind one integration. Machine commerce needs a similar layer of abstraction, assembled from wallets, micropayments, usage meters, zero-knowledge proofs, programmable budgets, machine identities, and service receipts. None of these map cleanly onto a card network.
A price without an account
A service should be able to charge $0.001 per query, $0.02 per image, $0.10 per gigabyte, or $1 per GPU minute without first requiring every caller to open an account. The agent holds value. The service publishes a price. A proof connects the two.
This matters most when the buyer is not a person. Picture an agent with a $100 budget. It discovers a service, checks the price, pays privately, uses it, receives a receipt, and moves on to the next one. Nothing in that loop requires a human to fill out a billing form between steps.
Where this points
Today the product covers one deliberate, concrete path: a funded note paying for metered OpenRouter inference, request by request. That narrowness is what makes the flow real rather than aspirational, and the same note lifecycle already carries the rest of the argument: a deposit, private spending power, a proof per payment, and a settled receipt.
The direction beyond it is a payment layer for APIs, compute, and machine-to-machine commerce. Not another AI wrapper, and not only private inference.
Private prepaid compute today. Programmable machine payments tomorrow.
Cash for the machine internet.