Solana Now Supports MPP for AI Agent Payments

Solana officially integrates the Machine Payments Protocol by Stripe and Tempo, letting any HTTP API accept stablecoin payments from AI agents on Solana.

Solana has officially added support for the Machine Payments Protocol. The announcement came directly from the official Solana account on X, confirming that the @solana/mpp SDK now handles any stablecoin on Solana, including SPL tokens and Token2022 assets. Anyone already building with MPP can now plug Solana in as a supported payment rail.

MPP is an open protocol built around the HTTP 402 Payment Required flow. It lets any API accept payments without a human in the loop. Stripe and Tempo jointly proposed it. And Solana is now the first major high-throughput chain added as a native rail.

APIs That Want Money Just Got What They Needed

The @solana/mpp SDK ships with a set of features that go well past basic token transfers. According to a follow-up post from the Solana account on X, the spec supports split payouts with richer settlement flows, native fee payer support so servers can cover network fees on behalf of clients, and delegated signer options including Ed25519 and passkey-friendly secp256r1 flows.

That last piece matters for developers building agent-side tooling. Agents don’t always manage their own keys the same way a human wallet does. The secp256r1 support opens the door to hardware-backed or passkey-derived signing, which fits cleanly into agentic architectures.

Fee sponsorship deserves more attention than it’s getting. Servers can now co-sign as fee payer before broadcasting a transaction. The client partially signs as transfer authority only. This removes a friction point for agents that may not hold SOL for gas, just stablecoins for payments.

The SDK Is Live and Under Active Development

Solana posted the GitHub link directly on X, pointing developers to github.com/solana-foundation/mpp-sdk. The repository is a TypeScript and Rust monorepo. The Rust SDK is listed as coming soon. TypeScript is live now.

The SDK already supports one-time charge flows and session-based payment channels. Charge flow works in two settlement modes. Pull mode, which is the default, uses a full signed transaction. Push mode uses a signature. Both options are in the current release.

Split payments are already in. One charge can go to multiple recipients in a single transaction. The server defines a primary recipient and one or more split targets with fixed amounts and optional memos. The math is handled on-chain.

The Solana account on X was clear that the spec is not yet finalized. Wire formats and APIs remain subject to change. Still, the SDK is functional, tested, and open for use.

What Stripe and Tempo Actually Built

MPP is part of a broader push from Stripe around what the company calls its Agentic Commerce Suite. As covered when Stripe introduced the Machine Payments Protocol, the protocol sits alongside the Agentic Commerce Protocol, MCP integrations, and x402 support. The framing from Stripe is direct. Agents are not a secondary use case. They are the primary users of the web. MPP is the infrastructure to match that.

Tempo is the Ethereum-compatible Layer 1 that co-developed the protocol. It targets high-throughput payment flows and real-world settlement requirements. Solana is now the first external chain to plug into this standard, separate from Tempo’s own stack.

Solana Was Already Built for This

Solana’s positioning as an agentic payment chain is not new. The network has been accumulating stablecoin infrastructure rapidly, with over $2 trillion in quarterly stablecoin volume reported by builders on the network. Sub-cent fees and high throughput make it a practical fit for the kind of per-API-call micropayment flows that MPP targets.

That throughput profile is precisely what makes Solana attractive here. MPP is built to charge per HTTP request. Agents can call paid endpoints at high frequency. A chain with congestion or variable fee spikes would break the model. Solana’s architecture, at current performance levels, handles that load.

The SDK ships with replay protection using consumed transaction signatures. Simulation runs before broadcast to cut down on wasted fees. The server pre-fetches recentBlockhash to save clients an RPC round-trip. Small details. But they add up in a system built for continuous agent-to-API transactions.

Developers can start building now. The full SDK is on GitHub and the docs are live on npm.