Is MPP only on Tempo? No. Here is every chain the Machine Payments Protocol runs on

The launch-week takes said MPP was Tempo-only. The spec's own payment-methods list now includes Stellar, Solana, Monad, NEAR Intents and more. What changed, and what it means for agents that hold Stellar USDC.

6 min readMPP Router team

No. The short answer to "is MPP only on Tempo" is that the Machine Payments Protocol is a payment-method-agnostic HTTP protocol, and its own payment-methods page lists eleven methods, including Stellar, Solana, Lightning, Stripe and NEAR Intents. Tempo is one method among them. What is true is that most of the merchants who accept MPP today settle on Tempo or Base, which is a different (and more interesting) problem.

Where the "Tempo-only" idea came from

MPP was announced by Stripe and Tempo on 2026-03-18. Because the announcement, the reference implementation and the first merchants arrived together, several launch-week comparisons framed the choice as "MPP (Tempo) vs x402 (multi-chain)". That framing was repeated in threads for weeks, and comparison posts written since then have mostly kept the same table: x402 gets a list of chains, MPP gets the word Tempo.

We understand why. In launch week that table was roughly correct, and it is a tidy way to explain two protocols in one screen. It just stopped being accurate quickly, and nobody went back to edit the tables. This post is the edit.

What MPP actually is

MPP is an HTTP-level scheme, not a chain. The server answers a request with 402 Payment Required and a WWW-Authenticate: Payment ... challenge; the client comes back with an Authorization: Payment ... credential; the server verifies it, serves the response and attaches a receipt. Which rail carries the money is the method field in the challenge. The spec lives in the public tempoxyz/mpp-specs repository, and the HTTP Payment Authentication scheme drafts are published at paymentauth.org. Each payment method is its own draft that plugs into the same challenge / credential / receipt shape.

Here is the list from mpp.dev/payment-methods as we fetched it on 2026-09-02, in page order, with the page’s own one-line descriptions:

Payment methodDescription on mpp.dev
TempoWeb scale payments with TIP-20 stablecoins on Tempo with sub second settlement
EVMStablecoin payments on EVM chains with inline x402 exact compatibility
StripeTraditional payment methods through Stripe
CardCard payments via encrypted network tokens
LightningBitcoin payments over the Lightning Network
SolanaNative SOL and SPL token payments on Solana
StellarSmart contract payments on Stellar
MonadERC-20 token payments on Monad
NEAR IntentsCross-chain payments settled by NEAR Intents
RedotPayPayments with RedotPay balance and stablecoin rails
CustomBuild your own method or extend existing methods with the SDK.

Two things stand out. First, the list is not even crypto-only: Stripe and Card are in it. Second, the EVM entry is described as "inline x402 exact compatibility", which is a quiet admission that the "MPP vs x402" framing was always a bit forced. The two protocols overlap more than they compete.

MPP on Stellar specifically

The Stellar Development Foundation’s Q1 2026 update says the team "delivered a full MPP SDK within one week of Stripe and Tempo’s announcement". The repository that came out of that week is stellar/stellar-mpp-sdk, published on npm as @stellar/mpp, and documented on developers.stellar.org. The parts that matter if you are deciding whether to build on it:

  • Two intents. Chargeis a one-shot Soroban SAC transfer per request (the "turnstile"). Session is a unidirectional payment channel: the client deposits once and sends off-chain cumulative commitments, settled in a batch on close (the "bar tab"). The SDK exposes them as @stellar/mpp/charge/* and @stellar/mpp/channel/*.
  • A published draft. Charge implements draft-stellar-charge-00 on paymentauth.org, so a Stellar credential is a first-class MPP credential, not a vendor extension.
  • No facilitator. The Stellar docs are explicit that clients pay natively; there is no third-party verify / settle service in the loop, which is a real difference from the x402 model.
  • Sponsored fees. In charge mode the server can rebuild the transaction with its own account as source (feePayer with an envelopeSigner and an optional feeBumpSigner), so the client signs only the authorization and never holds XLM for gas. For an agent wallet that only has USDC, this is the feature.

One practical caveat as of 2026-09-02: the SDK’s exported mainnet asset constants are invalid StrKeys (issue #68). If you go to stellar:pubnet, pass the USDC SAC contract ID from the official Stellar docs yourself rather than importing the constant. Testnet constants are fine.

The nuance: the merchants are still mostly on Tempo

So the protocol is multi-chain. The catalog is not, or not yet. When we snapshotted the mpp.dev registry on 2026-04-12 it held 88 services and around 489 paid POST endpoints, and the payment methods those merchants advertise are overwhelmingly Tempo, with Base (via the EVM method) a distant second. OpenAI, Anthropic, OpenRouter, fal.ai, Perplexity, Exa, Firecrawl and the rest accept MPP, but they accept it on the rails they integrated, and almost none of them integrated Stellar.

That is the honest version of the myth. "MPP is Tempo-only" is false. "If you hold Stellar USDC you can pay almost nobody directly" is, for now, true. A Stellar-native agent that speaks perfect @stellar/mpp still gets a challenge with method="tempo" from the merchant it wants, and it cannot answer that challenge.

Where MPP Router fits

MPP Router is the piece between those two facts. It is a payment proxy at apiserver.mpprouter.dev that mirrors the mpp.dev catalog under one hostname. An agent sends its request with no credential and gets a 402 back with a Stellar challenge, either the MPP WWW-Authenticate form (method stellar, intent charge, fees sponsored) or the x402 v2 Payment-Required form on stellar:pubnet, in the same response. The agent pays the router’s pool address in Stellar USDC for exactly the merchant’s quoted price, and the router pays the merchant in USDC on Tempo (or Base, for x402 merchants) and returns the merchant’s response with a Payment-Receipt header that carries the Stellar transaction hash.

It is deliberately narrow. The router does not resell tokens or sit in front of an LLM as a gateway; it forwards your body to the merchant and the merchant’s body back to you. It does not hold a balance for you beyond the single per-request payment, and it does not act as an x402 facilitator for third parties. If you already have a Tempo or Base wallet, it just proxies your request through unchanged. As of 2026-08-18 we had paid real mainnet calls through 20 distinct services and the catalog advertised 446 payable routes to Stellar clients. For what the router is and is not in more detail, read What is MPP Router; for the two inbound flavours side by side, read MPP vs x402 on Stellar.

Try it

If someone asks you whether MPP is only on Tempo, point them at the payment-methods page and then at the catalog: the protocol is multi-chain, the merchants mostly are not, and a router closes the gap. To see it work, probe a route with no credential and read the challenge:

curl -i -X POST https://apiserver.mpprouter.dev/v1/services/exa/search \
  -H "Content-Type: application/json" \
  -d '{"query":"is MPP only on Tempo"}'
# -> 402 with WWW-Authenticate: Payment method="stellar" ...
#        and Payment-Required (x402 v2, stellar:pubnet)

The flow is written up step by step on How it works, the live catalog is on Services, and agents can read the machine-friendly version at apiserver.mpprouter.dev/llms.txt.