How one agent pays another.
A caller asks a provider for a job. The provider answers with a price for that exact request, the caller signs a one-time authorization to pay it, and a single escrow contract settles the payment and returns the answer in one step, leaving one receipt that covers both. No accounts, no API keys, no subscription. This page walks through the wire, the settlement contract, and the choices behind them.
How one paid call works.
A caller posts the work it wants done. Instead of charging a flat rate, the provider answers with HTTP 402, Payment Required, and a price quoted against that exact request. That 402 carries a typed-data payment requirement: an EIP-712 domain anchored to the chain and the escrow account, the price, and the asset to pay in. The caller signs one payment authorization that names who pays, who is paid, the amount, and a hash of the exact request it covers (its requestHash), so it cannot be reused on another job or altered. It retries with that signature in an X-Payment header.
Before doing any work the provider checks four things. The signature recovers to the declared buyer, through ECDSA or an ERC-1271 smart account. The keccak hash of the canonicalized body matches requestHash, so a leaked signature cannot be replayed against a different request. The nonce, a one-time number, has not settled before. The deadline has not passed. Only then does settlement run.
Delivery is gated on payment. The provider confirms the settlement transaction on-chain first, streams the result over server-sent events second, and closes once the work is done. A buyer who cannot pay never receives the answer.
Where the money actually moves.
One contract both moves the value and proves it moved. Every provider settles through the same escrow. It takes the signed authorization, the signature and the buyer's EIP-2612 permit values, recovers the signer, calls permit on USDS with the values the buyer pre-signed, and transfers from buyer to provider in the same transaction. No prior approval, no intermediary. Settlement is a single contract call, so the on-chain cost per payment stays low enough to make charging per call practical.
Replay protection is a per-buyer nonce map, so a caller can have many requests in flight without serializing. The contract emits a settlement event keyed by requestHash with a deterministic receipt hash. A caller who later needs to prove it paid for a specific answer cites that receipt.
Any handler becomes a paid endpoint.
A provider writes its work as one function and sets a price per request. It never touches the payment exchange between caller and provider: the SDK answers the 402 price quote, checks the signed authorization against the exact request, settles through the shared escrow in one transaction, and streams the result back over the same connection. Risk, Synthesis, Compliance, and Routing are all built this way, two of them live and two still in preview:
Synthesis
livePay it a question and it researches the live web with Claude, then returns a short answer with the sources it used, tied to the exact request you paid for.
Risk
liveSend it the list of assets your treasury holds and it runs thousands of what-if market days, then reports how much you could lose on a bad one.
Compliance
previewSend it the wallet you are about to trade with and it checks whether that wallet is on a blocklist, then hands back a tamper-proof yes or no you can keep as proof you checked.
Routing
previewSend it a trade and it works out how much price would move against you while it fills, plus a step-by-step plan to make the trade happen.
Three arguments to pay any provider.
Paying is simpler than charging. The client SDK hides the handshake. Your code provides three things: which provider to call, what to send it, and a spending cap. It signs with a pluggable signer, an ordinary wallet today and a session-key smart account tomorrow, and refuses to sign when the quoted price exceeds the cap or when the amount and domain do not match the rail it expects.
The same surface is exposed as a Model Context Protocol server, so any MCP-speaking agent gets a paid tool per provider with no bespoke integration. That is the test of whether this is a framework or a single seller: a generic agent, dropped in cold, can pay for risk or synthesis and walk away with the answer and a receipt.
The dollar whose issuer can change the rules behind it.
USDS is a digital dollar issued by Sky, a community-governed organization. USDC clears these payments today and will keep clearing them. Our claim is narrower: the asset that wins agent finance is the one whose issuer can move the parameters the rail actually needs, and that is not a neutral issuer. Sky governance is a coordination layer with discretion over surplus, savings rates and debt ceilings. Four actions are visible from here, none of them live for this rail yet.
- Sky can rebate providers' gas costs from the surplus buffer, so a provider stays net-positive across volume even below a per-call threshold.
- It can subsidize callers during bootstrap, a finite incentive line that retires once organic volume crosses a threshold.
- The savings rate can accrue on the USDS agents hold between runs, so working capital parked in sUSDS earns yield. The settlement asset is also the float.
- And the surplus can back a dispute escrow, so callers can transact against providers they have no reputation with yet.
Each is one governance action away. The savings-rate lever and the agent-rail-volume lever are the same shape: a basis-point parameter Sky already sets. A neutral issuer does not have that lever.
See it run.
The autonomous treasury manager reads a real Compound treasury, pays four agents per call for its analysis, and settles every payment on-chain before a human approves the trade.