Vouchers vs API keys

Every marketplace call is bought with a receipt the agent signs, not a key it holds. The old way was an account at every service, a card on file at each, a key generated, stored and guarded for each, and a monthly reckoning of who charged what. Vouchers, the contracts' name for those receipts, replace all of it with one wallet, one budget and one signature per call. That buys a lot, costs something real, and is not always the right model.

The two models in one paragraph each

API key: the provider issues you a random secret; you present it on every request; the provider's database maps it to your account, quota, and card on file. Authorization is database lookup; billing is trust in the provider's metering; recourse is their support desk and your card issuer.

AIOUM voucher: you escrow a deposit on-chain once (openSession); each request carries an EIP-712 signature over (sessionId, cumulativeAmount), a running total you authorize; the operator's node verifies the signature against the on-chain session and serves. Authorization is signature verification; billing is the voucher you yourself signed; recourse is a bonded dispute against the operator's slashable stake.

Where vouchers win

A provider's key database leaking and every customer's credential burned at once cannot happen here: the node keeps no client secrets, so there is nothing to breach.

A stolen credential is bounded. A leaked API key spends until someone notices, limited only by the provider's billing code. A stolen voucher authorizes at most cumulativeAmount ≤ deposit on one session with one operator, and replaying it is a no-op: the total is monotonic and settled on-chain. A stolen session key (ERC-4337) is capped by its budget and expiry, so you choose the blast radius in advance, not the thief.

The operator cannot overbill you. It can only settle a total you signed, so disputes about amount are cryptographically impossible and only disputes about delivery remain (see dispute-verifiability.md). The spend cap is enforced by the chain, not the counterparty: an API "budget alert" is the provider's code politely agreeing to stop charging you, while escrow cannot exceed the deposit by construction.

Strangers can transact. No signup, no KYC-by-credit-card, no account provisioning: machine-speed onboarding between parties with no prior relationship, the operator bonded by slashable stake rather than merely reputable. So an agent can find tools mid-run and pay whatever it finds at once, within your budget, and the rating it leaves afterwards, issued from what it was actually served, is worth something to the next agent.

Identity is portable and the record auditable: one keypair works across every AIOUM service, payment history is independently verifiable, and nobody can silently ban the identity. An operator can refuse service; the rails do not gatekeep.

Where API keys win

Simplicity, massively. A key is one string in a header: any language, any intern, zero infrastructure. Vouchers need EIP-712 signing, session lifecycle, cumulative-total bookkeeping, an RPC connection and, for the gasless path, a bundler and paymaster. The SDK and the app hide this, but "install an SDK and fund a wallet" is a taller first step than "copy a key from a dashboard", and a 402 handshake is harder to debug than a 401.

Cold-start latency is real. The first call needs an on-chain openSession and its confirmation, seconds on an L2 and worse elsewhere; an API key's first call is as fast as its thousandth. After the open, per-call overhead is one signature, matching keys; session reuse amortizes the cold start but cannot remove it.

Capital efficiency favours the key. Escrow is prepaid: an agent using 20 services in parallel has 20 deposits locked, while API billing is postpaid with net-30, strictly better working-capital terms for the buyer. Deposit sizing is a real tuning problem: too small means constant re-opens, too big means idle capital.

The client secret still exists. The client's signing key is a secret whose compromise spends real, unrecoverable money at once. Budget-scoped, expiring session keys via the AA stack bound this well below an API key's exposure, but they demand key-management discipline from exactly the audience that wanted less of it, and a lost seed phrase has no "reset password" path.

Privacy cuts both ways on a ledger. With API keys your usage is visible to the provider (and its subpoenas) and nobody else. On AIOUM, session opens, deposits, settled totals, timestamps, service IDs and dispute history are public forever, linkable by address. Request content stays off-chain (TLS to the node), but who uses which service, how much and when is world-readable; fresh addresses and session keys per relationship shrink linkage without erasing amounts and timing. For a business, competitors watching its agent's vendor spend in real time is a cost API keys do not have. Hygiene defaults and bonded privacy relays restore the private-to-one-party deal (see privacy.md), but transparency is the default and privacy is opt-in work.

Recourse ergonomics favour the card. A chargeback is free, familiar and handled by someone else; an AIOUM dispute costs a bond, takes a timeout window and pays out in slashed ZAI. Better than nothing, the realistic alternative between strangers; worse than consumer-payment rails where those exist.

And there is ops to learn. Nonce management, gas spikes, RPC flakiness, chain reorgs, congestion at open and settle time, treasury accounting for crypto: a surface API-key consumers never think about. The app and the SDK absorb most of it, but it exists.

The scorecard

Bottom line

The voucher model is not "API keys but better." It buys trustlessness between strangers, bounded blast radius, and unforgeable billing, and pays for them with integration complexity, prepaid capital, public metadata, and cold-start latency.

When two agents (or companies) with no prior relationship need machine-speed, per-call settlement with no billing department, vouchers are the only game in town: the alternative is not API keys, it is no transaction at all. When a stable bilateral B2B integration already has contracts, invoices and lawyers, API keys are simpler, cheaper and more private, and AIOUM does not pretend otherwise. AIOUM's bet is that the first category, the agent economy, is the one about to grow, and the one traditional rails cannot serve. Every contract and off-chain piece is wired so that the signed receipt is the only thing that ever moves money.

Next: Architecture — the map of the contracts and services that make a signed receipt worth trusting.