Skip to main content

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 actually pay in depends on your client: see Currencies and client support.

Single payment (one charge per call)​

Each call settles on its own:

  1. Your client calls a OneSource endpoint without any Authorization header.
  2. OneSource returns HTTP 402 with one or more WWW-Authenticate: Payment headers; each carries the price, payTo, network, and currency.
  3. Your client picks a challenge and constructs an MPP credential: a signed payload covering the price + recipient + nonce.
  4. Your client retries the call with Authorization: Payment <credential>.
  5. OneSource verifies the credential, settles on Tempo, and returns the response plus a Payment-Receipt header.

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):

CurrencyContractNotes
USDC.e0x20c000000000000000000000b9537d11c60e8b50The default everywhere. Standard ERC20 stablecoin on Tempo.
pathUSD0x20c0000000000000000000000000000000000000Native Tempo stablecoin. Reachable today only via the mpp-go SDK (see below).

The catch: whether you can use pathUSD depends on the client you pay with. OneSource offers both, but most clients only speak USDC.e today.

ClientUSDC.epathUSD
AgentCash✓-
Tempo CLI✓-
Custom client (mpp-go)✓✓

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 OneSource MCP Server does not speak MPP

The @one-source/mcp runtime server pays only with x402 on Base (via X402_PRIVATE_KEY); it has no MPP/Tempo code path and no MPP key. To pay with MPP, point one of the direct-HTTP clients below at a OneSource endpoint. (AgentCash ships its own MCP server that speaks MPP, a separate process from the OneSource MCP Server, which doesn't.)

AgentCash​

AgentCash speaks MPP alongside x402: point it at a OneSource endpoint and it picks the right protocol from the 402 challenge. It pays in USDC.e: it takes the first challenge offered without iterating (which is exactly why OneSource lists USDC.e first), and rejects pathUSD with unsupported_token. Nothing to configure.

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 pays in USDC.e only at this stage: its default wallet's access keys are scoped to USDC.e spending, so a pathUSD challenge fails. If you need 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 is the only client that can pay 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 runs Phase 2 session settlement in production: a KMS-signed close handler, a durable Redis voucher store, and a 5-minute on-chain settler backstop so an un-closed session still settles.

Sessions are USDC.e only. Unlike single payments, OneSource emits just one session challenge, for USDC.e. The Tempo CLI's tempo wallet sessions close selects a challenge differently from its per-call path, so offering a second (pathUSD) session challenge risks the close building a settle transaction in the wrong currency; and the default Tempo wallet access keys are scoped to USDC.e spending anyway. 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.

Both are first-class options at the gateway; pick whichever fits your wallet and integrations.

Next​