x402 et les MPP : leur fonctionnement, leurs différences

Sahil

29 mars 2026 — 10 min de lecture

Partager

Ajouter comme source préférée

x402 C'est le nom qui revient systématiquement dès que quelqu'un souhaite payer un service ou une API à l'aide d'un portefeuille plutôt qu'avec une clé API.

Récemment, Tempo a lancé le MPP (Machine Payments Protocol), et il existe désormais une deuxième option reposant sur une philosophie de conception différente. Ces deux protocoles font souvent l'objet de comparaisons. Ils s'appuient tous deux sur le protocole HTTP 402 Paiement requis, mais elles résolvent des problèmes différents à différents niveaux.

Voici comment chacune d'entre elles fonctionne, où s'intègrent les outils d'Quicknode, ainsi que les compromis qui comptent vraiment au moment de faire votre choix.

Version abrégée

• x402 Sur Quicknode , vous pouvez accéder aux points de terminaison RPC de Quicknode à l'aide d'un simple portefeuille. Pas besoin de compte, de clé API ni d'abonnement. Payez en USDC (Base, Polygon, Solana) ou en USDG (X Layer) et commencez à effectuer des appels.

• MPP, développé par Tempo , est un protocole permettant d'effectuer des paiements de machine à machine via n'importe quelle API. Il dispose de son propre système de défi/identifiant/reçu flow, prend en charge plusieurs méthodes de paiement (Tempo , stablecoins, cartes Stripe, Lightning) et intègre un modèle de session adapté à la facturation au compteur à haute fréquence, comme le RPC.

• Quicknode propose des outils pour les deux : @Quicknode/x402 et @Quicknode/x402-solana pour x402, et une version compatible MPP de endpoint à l'adresse https://mpp.quicknode.com/ à utiliser avec le mpp SDK.

Qu'est-ce que « x402 » ?

x402 est une norme ouverte, initialement mise au point par Coinbase, qui permet d'utiliser HTTP 402 une spécification concrète après des décennies passées à être « réservée à un usage futur ».

Le principe est simple : un serveur répond avec 402 Paiement requis, le client consulte les conditions de paiement, signe une autorisation relative au stablecoin, relance la requête, puis le serveur finalise le paiement et renvoie la ressource. Le tout au cours du même échange HTTP.

Quicknode utilise x402 pour fournir un accès authentifié via un portefeuille à son infrastructure RPC. Vous n’avez pas besoin de créer un compte sur Quicknode . Il vous suffit de connecter un portefeuille contenant des USDC, et la bibliothèque cliente se charge du reste : authentification, règlement des paiements et gestion des sessions.

Ce que propose « Quicknode » x402

Deux bibliothèques open source :

• @quicknode/x402 – client multi-chaîne pour JSON-RPC, REST, gRPC-Web et WebSocket via le proxy Quicknode x402

• @quicknode/x402-solana – Un client dédié à « Solana » qui s’intègre aux kits « Solana » et « Kite »

Le client prend en charge les modes de paiement suivants :

• paiement à la demande – 0,001 $ par appel, sans autorisation ni session. La solution la plus simple.

• prélèvement sur la ligne de crédit – Connectez-vous une seule fois via SIWX (Sign-In with X), achetez un forfait de crédits avec des USDC, puis utilisez ces crédits à chaque requête. Une solution plus économique pour une utilisation à long terme.

Une chose à noter : le réseau de paiement est dissocié du réseau RPC. Par exemple, vous pouvez effectuer un paiement en USDC sur Base Sepolia et interroger Ethereum ,mainnet, Solana, Aptos, Flow ou n’importe lequel des plus de 140 réseaux blockchain pris en charge. Même portefeuille, même authentification : flow.

x402 prélèvement sur la ligne de crédit flow

Un client utilisant @quicknode/x402 demande d'abord une ressource au proxy Quicknode x402 (par exemple via RPC, REST, gRPC-Web ou WebSocket) et obtient un 402 Paiement requis réponse. Le client effectue ensuite une authentification SIWX, reçoit un jeton de session JWT et transmet ses identifiants de paiement. Le proxy envoie ces identifiants au facilitateur x402 afin de vérifier et de régler le paiement, puis crédite le compte après confirmation. Le client réitère la requête initiale à l'aide du jeton de session. Le proxy la transmet à l'infrastructure Quicknode en amont, reçoit la réponse et renvoie un code d'état 200 OK au client, ce qui consomme 1 crédit.

Qu'est-ce que le MPP d'Tempo?

Le MPP (Machine Payments Protocol) adopte une approche plus large. Alors que l'x402 , à l'origine, visait à monétiser des terminaux individuels, le MPP cherche à normaliser la manière dont n'importe quelle machine peut effectuer un paiement à une autre machine via HTTP.

Le protocole utilise directement le mécanisme d'authentification HTTP :

• WWW-Authenticate : Paiement L'information contenue dans la réponse 402 indique au client quel paiement est requis.

• Autorisation : paiement la nouvelle tentative est accompagnée d'un justificatif de paiement

• Reçu de paiement le code de réponse 200 prouve que le serveur a accepté le paiement

Il s'agit d'un projet de spécification Internet ( Internet-Draft) de l'IETF (rédigé par Tempo Labs et Stripe), ce qui signifie qu'ils s'efforcent d'en faire une véritable norme, et pas seulement une convention de l'SDK .

Méthodes et objectifs

Le MPP fait la distinction entre le mode de paiement et la nature du paiement:

• Une « méthode » correspond au canal de paiement : tempo (les stablecoins sur la blockchain d'Tempo ), rayure (cartes), foudre (Bitcoin), ou sur mesure.

• Une « intention » correspond au modèle de facturation : frais (une seule fois par demande) ou session (forfait à l'utilisation par chaîne).

C'est important, car cela permet de combiner les différentes options. Une seule API endpoint peut accepter à la fois les stablecoins « Tempo » et les cartes Stripe. Le serveur indique toutes ses options dans la réponse 402, et le client choisit celle qu'il prend en charge.

En ce qui concerne plus particulièrement Tempo , le session C'est le principe qui est intéressant. Au lieu d'effectuer une transaction sur la chaîne pour chaque requête, le client dépose des fonds dans un contrat d'entiercement, puis signe des bons hors chaîne au fur et à mesure qu'il utilise des ressources. Le serveur vérifie chaque bon à l'aide d'un seul ecrecover appel ; pas de RPC, pas de consultation de base de données, juste du CPU. Le règlement s'effectue par lots dès que le serveur décide de fermer le canal. Pour une facturation de type LLM par jeton, par exemple, cette méthode est bien plus pratique que de payer sur la chaîne pour chaque bloc.

Frais liés au MPP flow

Au sein du MPP frais flow, un mppx Le client demande une ressource à un service MPP et reçoit une 402 réponse avec un WWW-Authenticate : Paiement défi. Le client effectue ensuite le paiement via le backend de son choix (par exemple, en signant une transaction ou en réglant une facture), puis réitère la même requête avec Authorization: Payment <credential>, et le service vérifie ces identifiants auprès du serveur d'arrière-plan. Une fois la vérification réussie, le service renvoie la ressource avec 200 OK et comprend un Reçu de paiement.

Session de l'Assemblée législative de l'Ontario flow (chaînesTempo )

Au sein du MPP session flow Avec les canaux « Tempo », le client ouvre d’abord un canal en déposant des fonds dans le contrat de dépôt fiduciaire Tempo , puis demande l’accès au service. Le service demande un bon de session, et le client répond en fournissant un bon cumulatif hors chaîne signé. Le service vérifie le bon localement à l’aide de ecrecover et vérifie le montant incrémental avant de renvoyer la réponse. Ce cycle de mise à jour des bons se répète à une fréquence élevée pendant l'utilisation, puis le service ferme le canal sur la chaîne dans le cadre d'un règlement par lots, à l'issue duquel tout dépôt non utilisé est remboursé au client.

Comparaison entre les deux

Ce qu'il faut savoir sur la production

x402 sur Quicknode

• Dans paiement à la demande mode, il n'y a ni SIWX, ni JWT, ni aucun état de session. Chaque requête est autonome.

• Le proxy n'effectue le paiement qu'une fois que l'appel en amont a abouti. Si l'appel RPC échoue, vous ne payez rien.

• Vous pouvez configurer preAuth : true dans l'mode de prélèvement de crédit, effectuer l'authentification lors de la création du client plutôt qu'au premier code 402. Cela permet d'économiser un aller-retour.

• gRPC- Les protocoles Web et WebSocket fonctionnent tous les deux, mais ils nécessitent le modèle de prélèvement de crédits, car ils s'appuient sur la session JWT. Pour plus de détails, consultez

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

MPP avec Tempo

• 402 ne concerne que les obstacles liés au paiement. Si l'authentification du client échoue, le serveur renvoie 401 . Si le paiement a bien été effectué mais qu'une politique empêche l'accès, c'est 403 . Cette distinction est clairement indiquée dans la spécification.

• Un serveur peut renvoyer plusieurs WWW-Authenticate : Paiement des en-têtes avec différentes méthodes. Une seule adresse endpoint peut accepter simultanément Tempo, Stripe et Lightning. C'est le client qui choisit l'une d'entre elles.

• Dans la session mode, le Reçu de paiement contient l'identifiant du canal, et non le hachage de la transaction. Vous obtiendrez le hachage de la transaction sur la chaîne plus tard, lors de la fermeture du canal.

• MPP fonctionne également via le protocole MCP (Model Context Protocol) pour les appels aux outils d'IA. Sur ce protocole de transport, le code 402 correspond à un code d'erreur JSON-RPC. 32042 , et les justificatifs/reçus se déposent dans _meta champs au lieu d'en-têtes HTTP.

• Pour obtenir des informations complètes sur le proxy MPP d'endpoint , disponibles à l'adresse Quicknode, notamment concernant les tarifs, les routes, les intentions de session et de facturation, les réseaux pris en charge et la configuration client, consultez

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

Quand utiliser l'un ou l'autre

Quicknode Prend en charge les deux. Aucun des deux ne nécessite de compte. Le choix dépend des autres services avec lesquels votre agent/application communique.

Si votre besoin principal concerne l'accès aux données de la blockchain, utilisez x402. Le @quicknode/x402 Le client prend en charge les protocoles de transport JSON-RPC, gRPC-Web et WebSocket, la facturation par forfait de crédits, ainsi que l'intégration du kit d'Solana s via @quicknode/x402-solana. Il s'agit des bibliothèques propriétaires d'Quicknode, développées spécialement pour son proxy x402 .

Si votre agent prend en charge plusieurs services, Quicknode pour le RPC, un fournisseur LLM pour l'inférence et une API de recherche pour l'extraction. Le MPP vous permet d'utiliser un seul protocole et un seul portefeuille pour tous ces services. Le MPP de Quicknode endpoint est disponible à l'adresse https://mpp.quicknode.com/ fonctionne de la même manière mppx client que vous utiliseriez pour appeler n'importe quel autre service compatible MPP.

Il n'y a aucune raison de ne pas utiliser les deux. x402 pour votre couche d'infrastructure, MPP pour les API que vous développez par-dessus.

Le code : à quoi il ressemble réellement

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 pour « 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 avec le 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 côté client (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))

Session MPP « 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())

Pour conclure

x402 et MPP sont étroitement liés et répondent au même problème fondamental : fournir un accès payant à une API via HTTP.

Pour la gestion par proxy RPC d'Quicknode , les deux méthodes sont utilisables. La différence pratique réside dans le style d'implémentation. Le protocole « x402 » repose sur un modèle de facilitateur, tandis que le MPP supprime cette dépendance et définit l'flow comme un schéma d'authentification HTTP formel.

Liens

• @Quicknode/x402 sur GitHub

• @Quicknode/x402-solana sur GitHub

• Quicknode x402 guide

• x402 référentiel de protocole (Coinbase)

• Documents MPP

• Mode de paiement du programme MPP « Tempo »

• Référence de l'interface en ligne de commande (CLI) de mppx

• Projet de l'IETF : schéma d'authentification HTTP « Payment »

• Quicknode MPP endpoint