What is MPP Router? One Stellar wallet for every MPP and x402 API

MPP Router is a payment proxy for AI agents on Stellar. It is not Cisco's Management Plane Protection, which shares the acronym; this one is about the Machine Payments Protocol (MPP) and x402. An agent pays the router once in USDC on Stellar, and the router pays the merchant behind the API in USDC on Tempo (or Base, for x402 merchants). One Stellar wallet, one hostname, and the merchant never has to know Stellar exists.

The problem it solves

MPP and x402 both work the same way at the HTTP level: call a paid endpoint, get 402 Payment Required, pay, retry. The catch is where the merchant wants to be paid. The MPP services listed on mpp.dev (88 services, around 489 paid POST endpoints as of 2026-04-12, per our llms.txt) settle on Base and Tempo. An agent whose only wallet is a Stellar USDC account cannot pay them. Its options are to bridge USDC out of Stellar, run a second wallet with gas on another chain, or skip the service.

Stellar has its own MPP and x402 implementations (see MPP on Stellar and x402 on Stellar), so a Stellar agent can already pay a Stellar merchant. What was missing was a way for that agent to reach the merchants that are not on Stellar. That is the gap the router fills.

How MPP Router works

The flow is three HTTP calls, and none of them are router-specific.

1. The agent POSTs to https://apiserver.mpprouter.dev/v1/services/{service}/{operation} with its request body and no payment header. The router forwards the body upstream to get a live quote and returns a dual-format 402: a WWW-Authenticate header (mppx dialect) and a Payment-Required header (x402 v2 dialect) in the same response, carrying the same amount, asset and recipient.
2. The agent signs a Stellar USDC payment for exactly that amount to the router's Stellar address. With mppx it retries with Authorization: Payment <base64>; with x402 v2 it retries with Payment-Signature: <base64>. Fees are sponsored, so the agent does not need XLM.
3. The router verifies the credential, pays the merchant from its own Tempo pool, and returns the merchant's response plus a receipt header (Payment-Receipt on the mppx path; X-Payment-Tx, X-Payment-Method: stellar.x402 and X-Payment-Settle-Status on the x402 path).

The x402 v2 path is the one we recommend for new clients. It uses the stock @x402/core/client plus @x402/stellar/exact/client, the same client that works against Coinbase's x402 demo paywall. We verified it end to end on Stellar mainnet on 2026-04-12.

Discovery is open and unauthenticated:

• GET /v1/services/catalog — the full catalog with public path, method, price, status and accepted payment methods per entry
• GET /v1/services/search?q=&category=&status=&limit=&offset= — keyword and category search
• GET /x402/supported — a standard x402 SupportedResponse listing exact on stellar:pubnet
• GET /openapi.json — OpenAPI 3.1 for the public surface

Here is the probe step of the x402 v2 quick start from our llms.txt, as curl. Step 1 confirms the scheme; step 2 fetches the quote. Signing the Payment-Required payload is done with the x402 client library, not by hand.

# 1. Confirm the router accepts x402 "exact" on stellar:pubnet
curl -s https://apiserver.mpprouter.dev/x402/supported

# 2. Probe a paid route with no payment header -> 402 with both dialects
curl -s -i -X POST \
  https://apiserver.mpprouter.dev/v1/services/fal/flux_schnell \
  -H 'Content-Type: application/json' \
  -d '{"prompt":"a lighthouse at dawn","image_size":"square","num_inference_steps":4}' \
  | grep -i -E '^(HTTP|www-authenticate|payment-required)'

# 3. Decode Payment-Required with x402HTTPClient.getPaymentRequiredResponse(),
#    sign with createPaymentPayload(), then retry the same POST with
#    Payment-Signature: <base64>

What it costs and how settlement works

The price is whatever the 402 challenge says. The amountfield is the merchant's quote expressed in Stellar USDC base units (7 decimals), and our llms.txt tells agents to treat that challenge as authoritative rather than cache earlier prices, because merchants can re-price per request. We do not publish a separate fee schedule in the integration docs, so we will not quote one here.

Settlement is per request. Each credential is single-use and HMAC-bound to the amount, asset and recipient of the challenge it answers, so a credential for a cheap route cannot be replayed on an expensive one. On the x402 path the router runs facilitator verification itself, pays the merchant, and only on a merchant 2xx submits the agent's signed Soroban invoke on chain.

When the merchant fails after intake, the router returns 502. Our llms.txt is blunt about it: the Stellar payment has already settled at that point. Our public verification log records what happens next. On 2026-08-18 two paid calls to a route that was later delisted came back 502 with the order marked refund_pending in GET /v1/ledger; the first reached refunded with the wallet credited, and a charge-route refund rehearsal the same day completed on chain in 25 seconds. That is a small sample and we say so in the log. Refund status is checked through the ledger endpoint, not through a header.

What MPP Router is not

• Not an AI gateway. We do not buy tokens in bulk and resell them. The router forwards your request body to the merchant unchanged and returns the merchant's response.
• Not a facilitator for third parties. There is no /x402/verify or /x402/settle for other servers to call. /x402/supported reports facilitator: "self": the router settles payments made to it, and nothing else.
• Not custody. The router does not hold agent balances or accept deposits. Each request is paid on chain before the merchant is paid.
• Not a bridge. Your USDC stays on Stellar. The merchant is paid from the router's Tempo pool; the two legs are settled separately.

If you already hold a Tempo or Base wallet, a Bearer token, or a Stripe credential, send it and the router acts as a transparent proxy: the header reaches the merchant untouched, the router spends nothing, and no receipt is attached. Only Stellar credentials issued against the router's own challenge cause it to pay a merchant.

Router, direct, or bridge it yourself?

Where it sits in the Stellar ecosystem

The router is listed on skills.stellar.org as MPP Discover, an agent skill for finding and paying MPP services from a Stellar wallet. It was also mentioned in the Stellar developer meeting of 2026-04-23, which described it as reaching over 400 MPP endpoints and noted it was "not yet on mainnet" at the time.

That note is out of date. The router has been live on Stellar mainnet since the 2026-04-12 verification above. As of 2026-08-18, our public verification registry records 20 distinct services verified payable with real mainnet USDC and 446 payable routes in the catalog, each verification backed by a Stellar transaction hash. Verified does not mean the rest is broken; it means we have paid for those ourselves and published the receipts. Routes we have tested and found failing are removed from Stellar discovery so agents do not pay for them.

Try it

Read the flow in more detail on how it works, browse the live catalog on services, and point your agent at apiserver.mpprouter.dev/llms.txt for the machine-readable version of this post. If your agent has a Stellar USDC wallet and a stock x402 v2 client, MPP Router is the shortest path to the MPP and x402 merchants that do not settle on Stellar.