Sahil

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.

Quick version

• 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 그리고 @Quicknode/x402-solana for x402, and an MPP-compatible endpoint at https://mpp.quicknode.com/ for use with the mpp SDKs.

What is x402?

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.

What Quicknode ships for x402

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.

x402 credit-drawdown 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.

What is MPP by Tempo?

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: 결제 in the 402 response tells the client what payment is needed

• 승인: 결제 on the retry carries proof of payment

• 지급-수령 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.

Methods and intents

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.

MPP charge flow

In the MPP charge flow, an mppx client requests a resource from an MPP service and receives a 402 response with a WWW-Authenticate: 결제 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 지급-수령.

MPP session flow (Tempo channels)

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.

How they compare

Production details worth knowing

x402 on Quicknode

• 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

  https://x402.quicknode.com/llms.txt

MPP with Tempo

• 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: 결제 headers with different methods. A single endpoint can accept Tempo, Stripe, and Lightning simultaneously. The client picks one.

• In session mode, the 지급-수령 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

  https://mpp.quicknode.com/llms.txt.

When to use which

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.

Code: what it actually looks like

Quicknode x402 (TypeScript)

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())

Quicknode x402 for Solana (TypeScript)

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)

MPP with the 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>

MPP client-side (TypeScript)

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))

MPP session mode (TypeScript)

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())

Wrapping up

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.

Links

• @Quicknode/x402 on GitHub

• @Quicknode/x402-solana on GitHub

• Quicknode x402 guide

• x402 protocol repo (Coinbase)

• MPP docs

• MPP Tempo payment method

• mppx CLI reference

• IETF draft: “Payment” HTTP auth scheme

• Quicknode MPP endpoint