Introducing zkAPI: private usage credits for any API

What it claims

zkAPI is a payment layer for metered APIs, live on Ethereum Mainnet. It lets a client pay a provider without the provider or the payment server being able to link usage to a depositor. Its central claim is a split of knowledge. The server that handles money never sees prompts. The provider that sees prompts never learns the billing identity behind a key. Your exit from the system never depends on the server being honest. It implements the "ZK API usage credits" design that Davide Crapis and Vitalik Buterin published on Ethereum Research.

How it works

sequenceDiagram
    participant App as Your app
    participant C as Local client
    participant S as zkAPI server (sees money)
    participant P as AI provider (sees content)
    App->>C: OpenAI/Ollama call on localhost
    C->>S: spend proof (no prompt, no identity)
    S-->>C: short-lived, dollar-capped key
    C->>P: prompts + key (direct)
    P-->>S: signed usage receipt at expiry
    S->>S: deduct metered amount from note

• Deposit. You fund the vault in ETH, USDC or similar, in one ordinary transaction. The deposit becomes a commitment in the Merkle tree.
• Spend proof. The proof shows that some valid note covers the spend, without saying which note.
• Nullifier. Each spend publishes a one-way serial number. Spending the same balance twice produces a duplicate nullifier. That reveals the double-spend attempt and nothing else.
• Billing is a reservation, not per-call.
• One proof covers a single request or a whole session.
• The dollar cap on the key is reserved up front, but the charge at expiry is the actual metered usage from the provider's signed receipt.
• The page says neither side can rewrite the bill afterward.
• Key handling. The API key exists only in the device's memory.
• Where proofs are checked. The server verifies spend proofs off-chain. The vault contract verifies the same kind of proof at deposit, close and escape. This is why you can withdraw on-chain even if every zkAPI server disappears.
• Proxy mode (alternative). The zkAPI server relays requests to the provider itself. It is simpler to operate, but the relay sees traffic. That breaks the content/payment separation that runtime-key mode exists to provide.

How to use it

• Clients. Point existing apps, editors or chat clients at the local client on localhost. It exposes the standard OpenAI and Ollama APIs, so no code changes are needed.
• Providers. Integration means two changes: accept a proof instead of an API key, and settle signed usage receipts instead of maintaining accounts. Pricing, rate limits and infrastructure stay unchanged.
• Beyond AI. AI inference is the first target, but the same client and contracts can front any per-use service.
• What the page omits. It gives no install commands, repository links, licence, fees or proof-generation timings.

Limits

• Network metadata. The provider still sees your IP address and can correlate sessions by timing. The gateway can also link your request patterns if you use a stable IP. The stated mitigation is Tor with a fresh circuit per session.
• Prompt content. Reused personal details, writing style, conversation history or project documents act as fingerprints that can re-link sessions. The page frames this as a privacy-utility tradeoff: standalone queries are more private but lose context. Its suggested mitigation is to have local or TEE models generate requests from shared memory instead of writing them by hand. Confidential GPU computing is mentioned only as "emerging".
• Proxy mode. Choosing proxy mode gives up content privacy from the payment intermediary.