Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.stable.xyz/llms.txt

Use this file to discover all available pages before exploring further.

MPP (Machine Payments Protocol) is an open standard for paying for HTTP resources in the same request that asks for them. It extends x402 with new payment intents (charge, subscription, session), multi-rail support (stablecoins, cards, Lightning), production features (idempotency, body-digest binding, expiration), and additional transports (MCP, WebSocket). The protocol is on the IETF standards track.

​
MPP and x402

MPP clients are backward compatible: an MPP client can call an existing x402 server without changes. Where the two protocols differ:
Aspectx402MPP
Payment intentsPer-request chargeCharge, subscription, session
RailsBlockchain onlyStablecoins, cards, Lightning, custom
Production featuresLimitedIdempotency, body-digest binding, expiration
TransportsHTTPHTTP, MCP/JSON-RPC, WebSocket
Headers (client ↔ server)PAYMENT-REQUIRED / PAYMENT-SIGNATURE / PAYMENT-RESPONSEWWW-Authenticate / Authorization / Payment-Receipt
GovernanceCommunity protocolIETF standards track
Method authorshipFoundation-controlledPermissionless

​
Challenge, credential, receipt

MPP wraps every paid request in a three-step exchange between the client and the resource server:
  1. Challenge. The server responds with 402 Payment Required and a WWW-Authenticate header that names the supported methods, the amount, and an expiration.
  2. Credential. The client picks a method, signs a proof of payment, and resubmits the request with an Authorization header carrying the serialized credential.
  3. Receipt. The server verifies the credential, settles the payment, and returns the response with a Payment-Receipt header containing the settlement reference.
A challenge can be cryptographically bound to the request body via a body digest, so a credential signed for one request cannot be reused on a different one.

​
Payment intents

Charge. A one-time payment for a single resource. The credential authorizes one transfer of an exact amount. Subscription. Recurring payments under a single scoped credential. The credential authorizes repeated charges across a billing period, with the rail enforcing renewal cadence. Session. Pay-as-you-go with off-chain vouchers. The client deposits funds into an escrow once, then signs cheap off-chain vouchers for each request. Only the net amount settles on-chain. See MPP sessions for details.

​
Transports

MPP defines the same challenge / credential / receipt exchange over multiple transports:
  • HTTP. The default. Headers as listed above.
  • MCP / JSON-RPC. Lets an MCP server monetize individual tool calls. An AI client signs a credential before invoking the tool.
  • WebSocket. Persistent connections with in-band voucher top-ups, designed for streaming sessions.

​
MPP on Stable

MPP does not ship a Stable payment method. The mppx SDK (wevm/mppx) includes methods for Tempo and Stripe, and mpp.dev lists Tempo, Stripe, Lightning, Solana, Stellar, Monad, and RedotPay. Stable is not on either list today. The standard is permissionless, so you can author your own method. For USDT0 on Stable, the verify() hook is signature validation against ERC-3009, and settlement is delegated to an existing settlement service: an x402 facilitator like Semantic Pay or Heurist, or Stable’s own Gas Waiver. See Build an MPP endpoint on Stable for the full walkthrough.

Build an MPP endpoint on Stable

Write the three MPP custom-method hooks for USDT0 and settle a real payment.

MPP sessions

Stream micropayments with off-chain vouchers and one net settlement.

x402

Read the original HTTP-402 protocol that MPP generalizes.
Last modified on June 2, 2026