MPP on Tempo
MPP (Multi-Party Payments) is an IETF-aligned HTTP payment protocol that uses standard WWW-Authenticate / Authorization headers (RFC 7235) instead of x402's custom Payment-Required flow. The headers survive proxies, work with curl, and don't conflict with regular HTTP auth schemes.
OneSource supports MPP on the Tempo network, and accepts both USDC.e and pathUSD as settlement currencies. It offers two payment modes:
- Single payment: one charge settled per call. The default; simplest to integrate.
- Sessions: open a channel once, pay many calls under it, close to settle in a single transaction. Materially cheaper for high call volumes.
Which currency you can pay in depends on your client: see Currencies and client support.
Single payment (one charge per call)
Each call settles on its own:
- Your client calls a OneSource endpoint without any
Authorizationheader. - OneSource returns
HTTP 402with one or moreWWW-Authenticate: Paymentheaders; each carries the price,payTo, network, and currency. - Your client picks a challenge and constructs an MPP credential: a signed payload covering the price + recipient + nonce.
- Your client retries the call with
Authorization: Payment <credential>. - OneSource verifies the credential, settles on Tempo, and returns the response plus a
Payment-Receiptheader.
Same wallet model as x402; different network and protocol header format.
Currencies and client support
OneSource accepts two currencies on mainnet, and emits a challenge for both on every single-payment 402 (USDC.e first, then pathUSD):
| Currency | Contract | Notes |
|---|---|---|
| USDC.e | 0x20c000000000000000000000b9537d11c60e8b50 | The default everywhere. Standard ERC20 stablecoin on Tempo. |
| pathUSD | 0x20c0000000000000000000000000000000000000 | Native Tempo stablecoin. See client support below. |
OneSource emits both challenges; which one gets paid is client behavior:
- A client that takes the first challenge without iterating pays in USDC.e. This is why OneSource lists USDC.e first.
- Paying in pathUSD requires a client that iterates the challenge list and signs from an ECDSA-generated wallet keypair; the mpp-go SDK does both.
- Your client's own documentation is the authority on which currencies it speaks.
Sessions are USDC.e only regardless of client: see Sessions.
Using MPP-aware clients
MPP is a direct-HTTP protocol: you reach it by pointing an MPP-capable client at a OneSource REST endpoint, and it negotiates the 402 for you. Any of the clients below works.
The @one-source/mcp runtime server pays with MPP on Tempo when you give it an MPP_PRIVATE_KEY (USDC.e / pathUSD), alongside x402 on Base via X402_PRIVATE_KEY. It offers mpp-charge (per-call) and mpp-session (voucher channel) modes, switchable with 1s_payment_mode; see MCP → MPP settlement. The direct-HTTP clients below are the way to pay with MPP from anything other than the MCP server.
AgentCash
AgentCash speaks MPP alongside x402: point it at a OneSource endpoint and it picks the right protocol from the 402 challenge. Nothing to configure. It takes the first challenge offered, so against OneSource it pays in USDC.e; AgentCash's own docs are the authority on its currency support.
Tempo CLI
The official Tempo wallet CLI makes a paid request with tempo request:
tempo request https://api.onesource.io/api/chain/network-info
It handles the 402 → credential → retry cycle automatically and prints the response; there's no currency flag to set. The Tempo CLI's default wallet pays in USDC.e: its access keys are scoped to USDC.e spending, so a pathUSD challenge fails against them. To pay in pathUSD, use the mpp-go SDK below.
Sessions use the same tool: tempo wallet sessions list / tempo wallet sessions close <url> (a session opens automatically on the first request to a host).
Custom client (mpp-go)
The github.com/tempoxyz/mpp-go library exposes the credential primitives directly and pays in pathUSD as well as USDC.e against OneSource. It supports any of Tempo's stablecoins, but only when signing from an ECDSA-generated wallet keypair. See the mpp-go README: the charge-basic and session-client examples are the quickest way in.
Sessions
The second payment mode: open a session once, pay many calls under one signed envelope, then close to settle on-chain. For workloads above ~50 calls/min this is materially cheaper than settling every call.
How it works:
- The 402 advertises a session challenge alongside the per-call charge challenges. Your client opens a channel, then satisfies subsequent calls with vouchers against it instead of paying each one individually.
- Closing the session settles the net total in one on-chain transaction. OneSource settles sessions with a KMS-signed
closehandler, a durable Redis voucher store, and an on-chain settler backstop, so a session that is never closed settles anyway.
Sessions are USDC.e only. Unlike single payments, OneSource emits just one session challenge, for USDC.e. A client can select a session challenge differently from its per-call path, so offering a second (pathUSD) session challenge risks a close building a settle transaction in the wrong currency. Single-currency emission removes the ambiguity.
When MPP beats x402
- Lower per-call cost. Tempo gas is materially cheaper than Base; settlement fees can be an order of magnitude lower.
- Proxy / CDN friendly. RFC 7235 headers pass through Cloudflare, AWS API Gateway, and other middleboxes that strip nonstandard headers.
- Session model. If your agent makes hundreds of calls/minute, per-call settlement burns fees; sessions amortize.
When to stick with x402
- You already have a Base USDC balance and prefer not to bridge.
- Your existing tooling speaks x402 only.
- You want the on-chain settlement to land on a high-traffic L2.
The gateway accepts both; pick whichever fits your wallet and your existing integrations.
Next
- x402 on Base
- Wallet setup: if you haven't funded your wallet yet
- Tempo docs: MPP protocol reference, CLI, and wallet setup