how it flows

One search result, paid for, in under a second.

This is a single call from a research agent, followed from the moment it asks a service for something to the moment the payment is settled on Base. Nothing here requires a human, a card, or an API key.

Step by step.

twhowhat
0 msagentGET search.api/q?… through the pahz fetch wrapper.
38 msserviceReplies 402 Payment Required with an x402 header: price 0.002 USDC, pay-to address, nonce.
39 mspahzChecks the tab: service on allowlist? price under band? rate cap ok? budget left? All yes.
41 mspahzSigns a USDC transfer authorization for 0.002 from the tab and retries the request with the payment header.
84 msserviceVerifies the payment, returns 200 OK with the result.
85 mspahzWrites a meter line: service, call, price, latency, nonce.
~5 minpahzBatches this and other payments into one settlement on Base; one receipt hash covers them all.

When the answer is no.

Most of what pahz does is refuse politely. A refusal is not an error for the agent; it is a normal response that the wrapper turns into a structured failure the agent can handle.

+0.0020 search.api · search · 41 ms +0.0110 infer.llm · completion · 612 ms held newapi.io · not on allowlist → notify owner held infer.llm · 0.045 over band (max 0.02) → notify owner held search.api · rate cap 60/min reached → retry in 12 s +0.0010 prices.feed · quote · 18 ms

Held calls appear in the owner's inbox with one-tap actions: allow once, allow always, raise band, ignore.

Settlement.

Individual x402 payments are authorizations, cheap and instant. pahz aggregates them into settlements on Base every few minutes or every N payments, whichever comes first. Each settlement writes one receipt hash that covers every meter line inside it, so the full meter is reconcilable against the chain.

Services receive their USDC at settlement. The tab's on-chain balance only moves at settlement, which is why the meter and the chain agree to the cent.