March 29, 2026 — 10 min read
Vos USDC rapportent au taux d'hierQuicknode le transfère automatiquement vers le coffre-fort Morpho le plus performant du jour. Disponible sur 7 chaînes.
Élaborez votre stratégiex402 and MPP: how they work, how they’re different
Compare x402 and Tempo’s MPP for HTTP 402-based API payments, including protocol design, payment methods, charge vs session billing, settlement and receipts, and when to use each with Quicknode’s x402 SDKs or its MPP endpoint for machine-to-machine and RPC workflows.
Certifié SOC 2 Type II · ISO 27001
March 29, 2026 — 10 min read
x402 has been the name that comes up whenever anyone wants to pay for a service or API with a wallet rather than an API key.
Recently, Tempo released MPP (Machine Payments Protocol), and now there's a second option with a different design philosophy. The two are compared a lot. They both build on HTTP 402 Payment Required, but they solve different problems at different layers.
Here's how each works, where Quicknode's tooling fits, and the tradeoffs that actually matter when you're choosing.
x402 on Quicknode lets you hit Quicknode RPC endpoints with just a wallet. No account, no API key, no subscription. Pay with USDC (Base, Polygon, Solana) or USDG (X Layer) and start making calls.
MPP by Tempo is a protocol for machine-to-machine payments across any API. It has its own challenge/credential/receipt flow, supports multiple payment methods (Tempo stablecoins, Stripe cards, Lightning), and includes a session model for high-frequency metered billing like RPC.
Quicknode offers tooling for both: @Quicknode/x402 et @Quicknode/x402-solana for x402, and an MPP-compatible endpoint at https://mpp.quicknode.com/ for use with the mpp SDKs.
x402 is an open standard, originally from Coinbase, that gives HTTP 402 an actual spec after decades of being “reserved for future use.”
The idea is simple: a server responds with 402 Payment Required, the client sees the payment requirements, signs a stablecoin authorization, retries the request, and the server settles the payment and returns the resource. All within the same HTTP exchange.
Quicknode uses x402 to provide wallet-authenticated access to its RPC infrastructure. You don’t create a Quicknode account. You connect a wallet with some USDC, and the client library handles everything else: authentication, payment settlement, and session management.
Two open-source packages:
@quicknode/x402 – multi-chain client for JSON-RPC, REST, gRPC-Web, and WebSocket through the Quicknode x402 proxy
@quicknode/x402-solana – Solana-specific client that plugs into Solana Kit and Kite
The client supports the following payment models:
pay-per-request – $0.001 per call, no auth, no session. The simplest path.
credit-drawdown – authenticate once with SIWX (Sign-In with X), buy a bundle of credits with USDC, then use credits on each request. Better economics for sustained usage.
One thing worth noting: the payment network is decoupled from the RPC network. For example, you can pay with USDC on Base Sepolia and query Ethereum mainnet, Solana, Aptos, Flow, or any of the 140+ supported blockchain networks. Same wallet, same auth flow.
A client using @quicknode/x402 first requests a resource from the Quicknode x402 proxy (such as RPC, REST, gRPC-Web, or WebSocket) and gets a 402 Payment Required response. The client then performs SIWX authentication, receives a JWT session token, and submits a payment credential. The proxy sends that credential to the x402 facilitator to verify and settle payment, then loads credits after confirmation. The client retries the original request with the session token. The proxy forwards it to upstream Quicknode infrastructure, receives the response, and returns 200 OK to the client, consuming 1 credit.
MPP (Machine Payments Protocol) takes a broader approach. Where x402 started as a way to monetize individual endpoints, MPP is trying to standardize how any machine pays any other machine over HTTP.
The protocol uses the HTTP authentication framework directly:
WWW-Authenticate: Payment in the 402 response tells the client what payment is needed
Authorization: Payment on the retry carries proof of payment
Payment-Receipt on the 200 response proves the server accepted payment
This is an IETF Internet-Draft (authored by Tempo Labs and Stripe), which means they’re pushing it toward a real standard, not just an SDK convention.
MPP separates how you pay from what kind of payment it is:
A “method” is the payment rail: tempo (stablecoins on the Tempo blockchain), stripe (cards), lightning (Bitcoin), or custom.
An “intent” is the billing pattern: charge (one-time per request) or session (channel-based pay-as-you-go).
This matters because you can mix and match. A single API endpoint can accept both Tempo stablecoins and Stripe cards. The server advertises all its options in the 402 challenge, and the client picks whichever it supports.
For Tempo specifically, the session intent is the interesting one. Instead of settling an on-chain transaction per request, the client deposits funds into an escrow contract and then signs off-chain vouchers as it consumes resources. The server verifies each voucher with a single ecrecover call; no RPC, no DB lookup, just CPU. Settlement happens in batches whenever the server decides to close the channel. For something like per-token LLM billing, this is a lot more practical than paying on-chain for every chunk.
In the MPP charge flow, an mppx client requests a resource from an MPP service and receives a 402 response with a WWW-Authenticate: Payment challenge. The client then completes payment through a chosen backend (for example, by signing a transaction or paying an invoice), retries the same request with Authorization: Payment <credential>, and the service verifies that credential with the backend. After verification succeeds, the service returns the resource with 200 OK and includes a Payment-Receipt.
In the MPP session flow with Tempo channels, the client first opens a channel by depositing funds into the Tempo escrow contract, then requests service access. The service challenges for a session voucher, and the client responds with a signed cumulative off-chain voucher. The service verifies the voucher locally using ecrecover and checks the incremental amount before serving the response. This voucher-update cycle repeats at high frequency during usage, and later the service closes the channel on-chain in a batched settlement, after which any unused deposit is refunded to the client.
x402 | MPP | |
|---|---|---|
Origine | Coinbase, open-source spec | Tempo Labs + Stripe, IETF Internet-Draft |
Wire format | Custom headers ( X-PAYMENT-*) | Standard HTTP auth scheme ( WWW-Authenticate: Payment, Authorization: Payment, Payment-Receipt ) |
Payment methods | Stablecoins | Multiple: Tempo stablecoins, Stripe cards, Lightning BTC, custom |
Multi-method per endpoint | No. One scheme per request. | Yes. Server can advertise multiple methods in a single 402 and the client picks one. |
Billing patterns | Per-request only at the protocol level | Per-request ( charge ) and metered ( session ) as distinct intents |
Session / channel support | None in the protocol. Implementations add their own (e.g. credit systems). | Native. session intent uses payment channels with off-chain vouchers and batched on-chain settlement. |
Settlement model | Facilitator verifies and settles each payment between client and server | charge : settled per request. session : server closes channel on its own schedule. |
Receipt / proof | Facilitator confirmation | Payment-Receipt header with receipt body containing reference , amount , asset , payer |
Status code semantics | 402 for payment required | Explicit separation: 402 = payment needed, 401 = auth failed, 403 = policy denial |
Transport | HTTP | HTTP, MCP (JSON-RPC error -32042 + _meta fields) |
Chain support | EVM, Solana | Tempo chain (for tempo method), plus non-blockchain rails (Stripe, Lightning) |
Standardization track | Open-source repo, no formal standards body | IETF Internet-Draft |
In pay-per-request mode, there’s no SIWX, no JWT, no session state at all. Each request is self-contained.
The proxy only settles payment after the upstream call succeeds. If the RPC call errors, you don’t pay.
You can set preAuth: true in credit-drawdown mode to authenticate during client creation instead of on the first 402. Saves a round trip.
gRPC-Web and WebSocket both work, but they need the credit-drawdown model since they rely on the JWT session. For more details, check
402 is only for payment barriers. If the client fails auth, the server returns 401 . If the payment went through but a policy blocks access, that’s 403 . This separation is explicit in the spec.
A server can return multiple WWW-Authenticate: Payment headers with different methods. A single endpoint can accept Tempo, Stripe, and Lightning simultaneously. The client picks one.
In session mode, the Payment-Receipt contains the channel ID, not a transaction hash. You get the on-chain tx hash later when the channel closes.
MPP also works over MCP (Model Context Protocol) for AI tool calls. On that transport, the 402 maps to JSON-RPC error code 32042 , and credentials/receipts go in _meta fields instead of HTTP headers.
For full endpoint details on Quicknode's MPP proxy, pricing, routes, session vs charge intents, supported networks, and client setup, see
Quicknode supports both. Neither requires an account. The choice comes down to what else your agent/application talks to.
If blockchain data access is your primary need, use x402. The @quicknode/x402 client provides JSON-RPC, gRPC-Web, and WebSocket transports, credit-bundle billing, and Solana Kit integration via @quicknode/x402-solana. These are Quicknode's first-party libraries built specifically for its x402 proxy.
If your agent pays for multiple services, Quicknode for RPC, an LLM provider for inference, and a search API for retrieval. MPP lets you use a single protocol and wallet for all of them. Quicknode's MPP endpoint at https://mpp.quicknode.com/ works with the same mppx client you'd use to call any other MPP-enabled service.
There’s no reason you can’t use both. x402 for your infra layer, MPP for the APIs you build on top.
import { createQuicknodeX402Client } from '@quicknode/x402'
// Initialize x402 client for Base Sepolia
// Wallet needs testnet USDC — get it via POST /auth (SIWE) then POST /drip
const client = await createQuicknodeX402Client({
baseUrl: 'https://x402.quicknode.com',
network: 'eip155:84532',
evmPrivateKey: process.env.PRIVATE_KEY as `0x${string}`,
preAuth: true,
})
// Make a paid RPC call — payment is handled automatically
const res = await client.fetch('https://x402.quicknode.com/base-sepolia', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
jsonrpc: '2.0',
id: 1,
method: 'eth_blockNumber',
params: [],
}),
})
// Print the result
console.log(await res.json())import { createSolanaX402Clients } from "@Quicknode/x402-solana"
import { address } from "@solana/kit"
import { homedir } from "node:os"
const { rpc } = await createSolanaX402Clients(
"mainnet",
`${homedir()}/.config/solana/id.json`,
)
const balance = await rpc
.getBalance(address("dDCQNnDmNbFVi8cQhKAgXhyhXeJ625tvwsunRyRc7c8"))
.send()
console.log("Balance:", balance.value)mppx CLI# create a wallet (stored in keychain)
npx mppx account create
# charge intent — $0.001/request, one on-chain tx per request
npx mppx -X POST -H 'Content-Type: application/json' \\
-d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' \\
<https://mpp.quicknode.com/base-sepolia>
# session intent — $0.00001/request, off-chain vouchers
npx mppx -X POST -H 'Content-Type: application/json' \\
-d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' \\
<https://mpp.quicknode.com/session/base-sepolia>import { Mppx, tempo } from 'mppx/client'
import { privateKeyToAccount } from 'viem/accounts'
const account = privateKeyToAccount(process.env.PRIVATE_KEY as `0x${string}`)
// Polyfills globalThis.fetch — handles 402 challenges automatically
Mppx.create({
methods: [tempo({ account })],
})
// Charge intent ($0.001/req) — payment is transparent
const res = await fetch('https://mpp.quicknode.com/base-sepolia', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
jsonrpc: '2.0',
id: 1,
method: 'eth_blockNumber',
params: [],
}),
})
const { result } = await res.json()
console.log('Block number:', BigInt(result))import { Mppx, tempo } from 'mppx/client'
import { privateKeyToAccount } from 'viem/accounts'
const account = privateKeyToAccount(process.env.PRIVATE_KEY as `0x${string}`)
// deposit 0.10 PathUSD into a payment channel
// first request opens the channel on-chain, subsequent ones use off-chain vouchers
Mppx.create({
methods: [tempo({ account, deposit: '0.10' })],
})
const res = await fetch('https://mpp.quicknode.com/session/base-sepolia', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
jsonrpc: '2.0',
id: 1,
method: 'eth_blockNumber',
params: [],
}),
})
console.log(await res.json())x402 and MPP are closely related and solve the same core problem: providing paid API access over HTTP.
For Quicknode RPC proxying, either can be used. The practical distinction is implementation style. x402 relies on a facilitator model, while MPP removes that dependency and frames the flow as a formal HTTP auth scheme.
Fondée en 2017, Quicknode une infrastructure blockchain de niveau institutionnel destinée aux développeurs et aux entreprises. Grâce à une disponibilité de 99,99 % et à la prise en charge de plus de 80 chaînes, les équipes peuvent développer et faire évoluer leurs applications sur la blockchain sans aucun compromis.
Les dernières actualités en matière d'ingénierie, les mises à jour sur les produits et les nouvelles du Web3, directement dans votre boîte mail.