x402 und MPP: Wie sie funktionieren, worin sie sich unterscheiden

Sahil

29. März 2026 – 10 Minuten Lesezeit

Teilen

Als bevorzugte Quelle hinzufügen

x402 ist der Name, der immer dann fällt, wenn jemand eine Dienstleistung oder API lieber mit einer Wallet als mit einem API-Schlüssel bezahlen möchte.

Vor kurzem hat Tempo das MPP (Machine Payments Protocol) veröffentlicht, und nun gibt es eine zweite Option mit einer anderen Designphilosophie. Die beiden werden häufig miteinander verglichen. Beide basieren auf HTTP 402 Zahlung erforderlich, aber sie lösen unterschiedliche Probleme auf verschiedenen Ebenen.

Im Folgenden erfahren Sie, wie die einzelnen Optionen funktionieren, wo die Tools von Quicknode zum Einsatz kommen und welche Kompromisse bei der Auswahl tatsächlich eine Rolle spielen.

Kurzfassung

• x402 Über Quicknode können Sie RPC-Endpunkte unter Quicknode bereits mit einer Wallet aufrufen. Kein Konto, kein API-Schlüssel, kein Abonnement. Bezahlen Sie mit USDC (Base, Polygon, Solana) oder USDG (X Layer) und beginnen Sie mit den Aufrufen.

• MPP von Tempo ist ein Protokoll für Machine-to-Machine-Zahlungen über beliebige APIs. Es verfügt über ein eigenes Challenge/Credential/Receipt- flow, unterstützt mehrere Zahlungsmethoden (Tempo Stablecoins, Stripe-Karten, Lightning) und umfasst ein Sitzungsmodell für hochfrequente, nach Verbrauch abgerechnete Zahlungen wie RPC.

• Quicknode bietet Werkzeuge für beides an: @Quicknode/x402 und @Quicknode/x402-solana für „ x402 “ sowie eine MPP-kompatible Version von „ endpoint “ unter https://mpp.quicknode.com/ zur Verwendung mit dem mpp SDKs.

Was ist „ x402 “?

x402 ist ein offener Standard, der ursprünglich von Coinbase stammt und HTTP 402 eine konkrete Spezifikation, nachdem sie jahrzehntelang „für zukünftige Zwecke reserviert“ war.

Die Idee ist einfach: Ein Server antwortet mit 402 Zahlung erforderlich, der Client sieht die Zahlungsbedingungen, unterzeichnet eine Stablecoin-Genehmigung, wiederholt die Anfrage, und der Server wickelt die Zahlung ab und gibt die Ressource zurück. All dies geschieht im Rahmen desselben HTTP-Austauschs.

Quicknode nutzt „ x402 “, um einen über die Wallet authentifizierten Zugriff auf seine RPC-Infrastruktur zu ermöglichen. Sie müssen kein Konto bei „ Quicknode “ erstellen. Sie verbinden einfach eine Wallet mit einem Guthaben in USDC, und die Client-Bibliothek kümmert sich um alles Weitere: Authentifizierung, Zahlungsabwicklung und Sitzungsverwaltung.

Wofür „ Quicknode “ eingesetzt wird x402

Zwei Open-Source-Pakete:

• @quicknode/x402 – Multi-Chain-Client für JSON-RPC, REST, gRPC-Web und WebSocket über den Proxy „ Quicknode “ (x402 )

• @quicknode/x402-solana – Ein speziell für „ Solana “ entwickelter Client, der sich in „ Solana “ Kit und „Kite“ integrieren lässt

Der Kunde unterstützt die folgenden Zahlungsmodelle:

• Bezahlung pro Anfrage – 0,001 $ pro Aufruf, keine Autorisierung, keine Sitzung. Der einfachste Weg.

• Kreditinanspruchnahme – Melden Sie sich einmalig bei SIWX (Sign-In with X) an, kaufen Sie ein Guthabenpaket mit USDC und nutzen Sie dieses Guthaben dann bei jeder Anfrage. Das ist wirtschaftlicher bei dauerhafter Nutzung.

Ein wichtiger Hinweis: Das Zahlungsnetzwerk ist vom RPC-Netzwerk entkoppelt. So können Sie beispielsweise mit USDC auf Base Sepolia bezahlen und Abfragen an Ethereum ,mainnet, Solana, Aptos, Flow oder eines der über 140 unterstützten Blockchain-Netzwerke senden. Gleiche Wallet, gleiche Authentifizierung: flow.

x402 Kreditinanspruchnahme flow

Ein Client, der @quicknode/x402 Fordert zunächst eine Ressource vom Proxy „ Quicknode “ (x402 ) an (z. B. RPC, REST, gRPC-Web oder WebSocket) und erhält eine 402 Zahlung erforderlich Antwort. Der Client führt daraufhin eine SIWX-Authentifizierung durch, erhält ein JWT-Sitzungstoken und übermittelt Zahlungsdaten. Der Proxy sendet diese Daten an den „ x402 “-Vermittler, um die Zahlung zu überprüfen und abzuwickeln, und schreibt nach der Bestätigung Guthaben gut. Der Client wiederholt die ursprüngliche Anfrage mit dem Sitzungstoken. Der Proxy leitet diese an die vorgelagerte „ Quicknode “-Infrastruktur weiter, empfängt die Antwort und sendet einen 200 OK-Status an den Client zurück, wobei 1 Guthabenpunkt verbraucht wird.

Was ist MPP von Tempo?

MPP (Machine Payments Protocol) verfolgt einen umfassenderen Ansatz. Während „ x402 “ ursprünglich als Möglichkeit zur Monetarisierung einzelner Endpunkte konzipiert wurde, zielt MPP darauf ab, die Art und Weise zu standardisieren, wie eine Maschine über HTTP Zahlungen an eine andere Maschine leistet.

Das Protokoll nutzt das HTTP-Authentifizierungs-Framework direkt:

• WWW-Authenticate: Zahlung Die Angabe in der 402-Antwort teilt dem Client mit, welche Zahlung erforderlich ist

• Genehmigung: Zahlung Bei der erneuten Zahlung liegt ein Zahlungsnachweis bei

• Zahlungsbeleg Der Status 200 bestätigt, dass der Server die Zahlung akzeptiert hat

Es handelt sich hierbei um einen IETF-Internet-Draft (verfasst von „ Tempo Labs“ und „Stripe“), was bedeutet, dass sie darauf hinarbeiten, daraus einen echten Standard zu machen, und nicht nur eine Konvention im Rahmen von „ SDK “.

Methoden und Absichten

MPP unterscheidet zwischen der Art und Weise , wie Sie bezahlen, und der Art der Zahlung:

• Eine „Methode“ ist der Zahlungsweg: tempo (Stablecoins auf der „ Tempo “-Blockchain), Streifen (Karten), Blitz (Bitcoin) oder nach Wunsch.

• Ein „Intent“ ist das Abrechnungsmuster: Gebühr (einmalig pro Anfrage) oder Sitzung (kanalbasiertes Pay-as-you-go-Modell).

Das ist wichtig, weil man die Optionen beliebig kombinieren kann. Ein einzelner API- endpoint kann sowohl „ Tempo “-Stablecoins als auch Stripe-Karten akzeptieren. Der Server gibt alle verfügbaren Optionen in der 402-Challenge an, und der Client wählt diejenige aus, die er unterstützt.

Speziell für „ Tempo “ gilt, dass die Sitzung Das Interessante daran ist der Ansatz. Anstatt für jede Anfrage eine On-Chain-Transaktion abzuwickeln, zahlt der Client Geld in einen Treuhandvertrag ein und unterzeichnet dann Off-Chain-Gutscheine, sobald er Ressourcen in Anspruch nimmt. Der Server überprüft jeden Gutschein mit einem einzigen ecrecover Aufruf; kein RPC, kein Datenbankabfrage, nur CPU. Die Abrechnung erfolgt stapelweise, sobald der Server beschließt, den Kanal zu schließen. Für Anwendungen wie die tokenbasierte Abrechnung von LLM ist dies wesentlich praktischer als die On-Chain-Zahlung für jeden einzelnen Datenblock.

MPP-Gebühr flow

Im MPP Gebühr flow, ein mppx Ein Client fordert eine Ressource von einem MPP-Dienst an und erhält eine 402 Antwort mit einem WWW-Authenticate: Zahlung Herausforderung. Der Kunde schließt die Zahlung anschließend über ein ausgewähltes Backend ab (beispielsweise durch Unterzeichnung einer Transaktion oder Begleichung einer Rechnung) und wiederholt dieselbe Anfrage mit Authorization: Payment <credential>, und der Dienst überprüft diese Anmeldedaten beim Backend. Nach erfolgreicher Überprüfung gibt der Dienst die Ressource mit 200 OK und umfasst eine Zahlungsbeleg.

MPP-Sitzung flow (Tempo -Kanäle)

Im MPP Sitzung flow Bei „ Tempo “-Kanälen eröffnet der Client zunächst einen Kanal, indem er Guthaben in den Treuhandvertrag „ Tempo “ einzahlt, und beantragt anschließend den Zugriff auf den Dienst. Der Dienst fordert einen Sitzungsbeleg an, woraufhin der Client mit einem signierten kumulativen Off-Chain-Beleg antwortet. Der Dienst überprüft den Beleg lokal mithilfe von ecrecover und überprüft den inkrementellen Betrag, bevor die Antwort gesendet wird. Dieser Zyklus der Gutscheinaktualisierung wiederholt sich während der Nutzung mit hoher Frequenz, und später schließt der Dienst den Kanal auf der Blockchain im Rahmen einer gebündelten Abrechnung, woraufhin etwaige nicht genutzte Einzahlungen an den Kunden zurückerstattet werden.

Ein Vergleich

Wissenswerte Details zur Produktion

x402 auf Quicknode

• In Bezahlung pro Anfrage mode, es gibt weder SIWX noch JWT, noch irgendeinen Sitzungsstatus. Jede Anfrage ist in sich abgeschlossen.

• Der Proxy wickelt die Zahlung erst ab, nachdem der übergeordnete Aufruf erfolgreich war. Wenn der RPC-Aufruf fehlschlägt, fallen keine Kosten an.

• Sie können Folgendes einstellen: preAuth: true Bei der Kreditinanspruchnahme mode erfolgt die Authentifizierung bereits bei der Kundenanlage und nicht erst beim ersten 402-Fehler. Das spart einen Roundtrip.

• gRPC- Sowohl Web als auch WebSocket funktionieren, erfordern jedoch das Credit-Drawdown-Modell, da sie auf der JWT-Sitzung basieren. Weitere Informationen finden Sie unter

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

MPP mit Tempo

• 402 gilt nur für Zahlungsbarrieren. Wenn die Authentifizierung des Clients fehlschlägt, gibt der Server Folgendes zurück: 401 . Wenn die Zahlung erfolgreich war, der Zugriff jedoch aufgrund einer Richtlinie gesperrt ist, dann ist das 403 . Diese Trennung ist in der Spezifikation ausdrücklich festgelegt.

• Ein Server kann mehrere Ergebnisse zurückgeben WWW-Authenticate: Zahlung Header mit unterschiedlichen Methoden. Ein einzelnes „ endpoint “ kann gleichzeitig „ Tempo “, „Stripe“ und „Lightning“ akzeptieren. Der Kunde wählt eine davon aus.

• In der Sitzung „ mode “ wurde die Zahlungsbeleg enthält die Kanal-ID, keinen Transaktions-Hash. Den On-Chain-Transaktions-Hash erhalten Sie später, wenn der Kanal geschlossen wird.

• MPP arbeitet bei Aufrufen von KI-Tools ebenfalls über MCP (Model Context Protocol). Bei diesem Transport entspricht der Code 402 dem JSON-RPC-Fehlercode 32042 , und die Nachweise/Quittungen kommen hinein _meta Felder anstelle von HTTP-Headern.

• Ausführliche Informationen zu „ endpoint “ – einschließlich Details zum MPP-Proxy von Quicknode, zu Preisen, Routen, Session- und Charge-Intents, unterstützten Netzwerken sowie zur Client-Einrichtung – finden Sie unter

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

Wann wofür

Quicknode Beides wird unterstützt. Für beides ist kein Konto erforderlich. Die Entscheidung hängt davon ab, mit welchen anderen Systemen Ihre Anwendung unter agent kommuniziert.

Wenn der Zugriff auf Blockchain-Daten Ihr Hauptanliegen ist, nutzen Sie x402. Die @quicknode/x402 Der Client bietet JSON-RPC-, „ gRPC “-Web- und WebSocket-Protokolle, die Abrechnung über Credit-Bundles sowie die Integration des „ Solana “-Kits über @quicknode/x402-solana. Dabei handelt es sich um Eigenentwicklungen von Quicknode, die speziell für den Proxy unter x402 entwickelt wurden.

Wenn Ihr „ agent “ mehrere Dienste abdeckt – „ Quicknode “ für RPC, einen LLM-Anbieter für die Inferenz und eine Such-API für den Abruf –, können Sie mit MPP ein einziges Protokoll und eine einzige Wallet für alle diese Dienste nutzen. Das MPP- endpoint von „ Quicknode “ finden Sie unter https://mpp.quicknode.com/ funktioniert genauso mppx Client, den Sie verwenden würden, um einen beliebigen anderen MPP-fähigen Dienst aufzurufen.

Es spricht nichts dagegen, beides zu nutzen. „ x402 “ für Ihre Infrastruktur-Ebene, MPP für die APIs, die Sie darauf aufbauen.

Code: Wie er tatsächlich aussieht

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 für „ 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 mit dem 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 auf der Client-Seite (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-Sitzung „ 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())

Zusammenfassung

x402 und MPP sind eng miteinander verbunden und lösen dasselbe Kernproblem: die Bereitstellung eines kostenpflichtigen API-Zugangs über HTTP.

Für das RPC-Proxying bei „ Quicknode “ können beide Verfahren verwendet werden. Der praktische Unterschied liegt im Implementierungsstil. „ x402 “ stützt sich auf ein Facilitator-Modell, während MPP diese Abhängigkeit beseitigt und das „ flow “ als formales HTTP-Authentifizierungsschema umsetzt.

Links

• @Quicknode/x402 auf GitHub

• @Quicknode/x402 –solana auf GitHub

• Quicknode x402 Leitfaden

• x402 Protokoll-Repo (Coinbase)

• MPP-Dokumente

• MPP- Tempo -Zahlungsmethode

• mppx-CLI-Referenz

• IETF-Entwurf: HTTP-Authentifizierungsschema „Payment“

• Quicknode MPP endpoint