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 method | Description on mpp.dev |
|---|---|
| Tempo | Web scale payments with TIP-20 stablecoins on Tempo with sub second settlement |
| EVM | Stablecoin payments on EVM chains with inline x402 exact compatibility |
| Stripe | Traditional payment methods through Stripe |
| Card | Card payments via encrypted network tokens |
| Lightning | Bitcoin payments over the Lightning Network |
| Solana | Native SOL and SPL token payments on Solana |
| Stellar | Smart contract payments on Stellar |
| Monad | ERC-20 token payments on Monad |
| NEAR Intents | Cross-chain payments settled by NEAR Intents |
| RedotPay | Payments with RedotPay balance and stablecoin rails |
| Custom | Build 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-00on 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 (
feePayerwith anenvelopeSignerand an optionalfeeBumpSigner), 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.