The Machine Payments Protocol (MPP) is an open standard for machine-to-machine payments — a specification that lets any software client pay for any service inline with an HTTP request, without accounts, API keys, or billing setup. Co-authored by Stripe and Tempo, MPP launched with the Tempo mainnet on March 18, 2026. Its sessions mechanism is the answer to a problem that simpler payment-over-HTTP designs leave unsolved: what happens when a machine needs to make thousands of small payments per hour?
The core idea: payment as authentication
Every API that charges for access currently requires some form of prior relationship: sign up, enter a credit card, receive an API key, and embed that key in every request. MPP replaces that with a payment-as-credential model borrowed from the HTTP specification itself.
When a client requests a resource from an MPP-enabled server, the server can respond with 402 Payment Required and a payment challenge: here is the price, here is the accepted stablecoin. The client pays — by signing a voucher or submitting a stablecoin transaction — and resends the request with payment credentials. The server verifies and delivers. No account. No prior relationship. No human in the loop.
This is how OAuth works for identity — you prove who you are by presenting a credential the server can verify — but applied to payments. MPP is, in this sense, OAuth for payments: a cryptographic proof that the client has already paid, attached inline to the request.
MPP Sessions: collapsing micropayments to two transactions
The straightforward version of payment-over-HTTP has a cost problem. If each API call triggers an on-chain transaction, a pipeline making 10,000 calls at $0.001 each also generates 10,000 blockchain transactions. On any chain with non-zero per-transaction fees, that overhead can exceed the value being transacted.
MPP Sessions solve this with a voucher architecture.
The two-transaction model
| Transaction | What it does |
|---|---|
| Open | Client deposits funds into an on-chain escrow contract on Tempo, opening the session |
| Settle (close) | Server submits the final voucher on-chain; unused funds return automatically to the client |
Those are the only two on-chain transactions, regardless of how many service calls the agent makes in between.
Vouchers: the off-chain layer
Between open and settle, every payment is an off-chain signed message called a voucher:
- For each unit of service consumed, the client signs a voucher with a cumulative amount — the running total of everything spent so far in the session.
- Each new voucher supersedes the previous one (the amount only increases).
- The server verifies the cryptographic signature in microseconds. No blockchain call required.
- The server holds the most recent voucher as its claim on the escrowed funds.
When the session ends — when the agent's task is complete, a time limit expires, or the client signals closure — the server submits its best voucher on-chain. The escrow contract pays out the cumulative amount, and any remainder returns to the client's wallet.
The Tempo blog, announcing MPP Sessions in April 2026, states this model allows the underlying payment rails to "scale to 1 million TPS and beyond." That figure describes the off-chain voucher layer, not the base chain's block throughput — the point being that off-chain voucher signing has no practical throughput ceiling, while the two mandatory on-chain transactions anchor the session to a verifiable settlement.
Why Tempo is the native chain for MPP
MPP's sessions model has specific requirements of its settlement chain:
- Fast finality: The open and settle transactions need to confirm quickly — if opening a session takes minutes, the protocol is unusable. Tempo's Simplex BFT consensus delivers deterministic sub-second finality (~500ms block time). Once a block confirms on Tempo, it cannot be re-organised.
- Predictable low cost: If the two required on-chain transactions cost dollars, sessions only make sense for large amounts. Tempo targets fees under $0.001, making the open/settle pair negligible even for small sessions.
- No gas token: Tempo has no native token. Gas is paid in the stablecoin itself (TIP-20 standard). An agent holding only USDC can open a session, make payments, and settle — without acquiring a separate volatile asset just to use the network.
- Payment Lanes: Tempo reserves protocol-level blockspace specifically for TIP-20 transfers, preventing session operations from being crowded out during congestion.
- Channel escrow precompile: The escrow mechanism for MPP Sessions is built directly into Tempo's protocol layer (added in the T4 network upgrade), not a third-party smart contract.
The Payments Directory
MPP launched with a Payments Directory at mpp.dev that listed over 100 services at mainnet launch, spanning categories including:
- AI model providers
- Developer infrastructure
- Compute platforms
- Data services
Named members in the directory include Alchemy and Dune Analytics.
SDK support
Three SDK implementations are published as of mid-2026:
| SDK | Repository | Language |
|---|---|---|
| mpp-rs | github.com/tempoxyz/mpp-rs | Rust |
| pympp | — | Python |
| wallet | github.com/tempoxyz/wallet | Rust (CLI + HTTP client) |
Payment methods
MPP accepts:
- TIP-20 stablecoins on Tempo (primary — USDC, USDT, and other TIP-20 tokens)
- Cards via Stripe
- Bitcoin via Lightning Network
The Stripe integration means an MPP-enabled API can accept a conventional card payment from a human client via the same protocol interface an AI agent uses with stablecoins.
Adoption
RedotPay, a crypto payments platform with 7.5 million users across 100+ countries and over $10 billion in annualized volume, integrated MPP in May 2026 — the first major consumer-facing integration. Stripe, as co-author, uses MPP in its stablecoin settlement stack. Both integrations were confirmed at or after Tempo's mainnet launch.
The bottom line
MPP is the answer to a specific engineering problem: how do you make per-use micropayments economically rational when the service might be called thousands of times per hour? The sessions model — one open, unlimited off-chain vouchers, one settle — makes the on-chain cost a fixed cost per task rather than a variable cost per call. For a head-to-head comparison with Coinbase's x402, see x402 vs MPP. For the broader context of why machine payments are emerging now, see What are agentic payments.